Some notes on how to avoid that feeling you get while working on a project — "wait... who actually wanted this spec in the first place?" (I'll be talking about this on the assumption that we're building a web service.)

What an unfillable Lean Canvas means

To quickly and easily shape a service, we sometimes use a Lean Canvas. It's convenient for getting an overview of a service, but if the target, needs, and market research aren't in place, it's a surprisingly hard thing to fill out.

For contracted projects, we do ask the client, but more often than not a clear "this is it!" answer doesn't come back easily. Lately I've started to feel that this might just be a tool for making people realize that it can't be filled in. A tool for visualizing what you don't know, or haven't thought about.

It's the most basic of basics, but I think there are two things that matter when designing a service:

• Who is the target?
• What value are we providing?

Who is the target?

The first step is defining the target. It sounds obvious, but features built without understanding the user come into being surprisingly easily. The awareness that "the user is the one who uses it, not the one who builds it" is something you can recall if someone points it out, but it won't actually take hold unless you keep thinking about it persistently.

For that, it really does start with getting to know the target.

We want to build a service that meets a need → Without defining the target, we can't tell if the need really exists 　　→ Without knowing if the need exists, we can't define the value 　　　　→ Nothing moves forward... a loop like this

To escape this kind of negative loop, we need a shared understanding that "we don't know the user, and we need to".

Defining the target is a hard problem, but in the end, I think the things we want to solve are scattered throughout everyday life. Doing something tedious for someone, doing it really fast, doing it before they even ask, remembering it forever... things like that.

If you think of it as "someone who's troubled by these ordinary things," it starts to feel like someone nearby, which might make it easier to think about.

What value are we providing?

My argument above was that to clarify the need, we should make the user concrete — but if you start feature development from the need, you tend to end up with something that doesn't quite make sense. Something like, "what is this even for?"

"Huh, that contradicts what you just said" — I know it feels that way, but what matters is clarifying the target persona and surfacing the single most important value or experience. It's not about creating a "committee-designed" product that tries to please everyone.

Why does starting feature development from the need tend to produce something murky?

The core concept, the value, tends to be missing → Among competitors, there's no standout point like "at least people with this need will use this service" → There's no perspective on how to get that value across (whether it's a simple value)

If you lose sight of whether it's a "value that comes across," you tend to end up with something like the above — a Swiss Army knife-style service that vaguely fulfills customer requests without anyone really knowing why.

If you're wondering what a "Swiss Army knife" service even means, here's a link. (I brought it up rather casually, but then thought that probably only UI designers even encounter the term "Swiss Army knife," so I went and found a reference.) Thoughts on smartphone UI (Bangai-hen): the story of buying a "who even wants this" 100-function knife | fladdict

Keeping these two things in mind (who is the target, what value are we providing), here's how I try to move service design forward.

Building value that comes across

Build value that comes across, not just value that "works"

I think what matters in a service isn't functional value on its own, but placing effective features within a story the user can understand and empathize with.

My own view is that the ideal state is one where the usage is clear, and the value is clear at a glance or in a single sentence.

This probably corresponds to what the Lean Canvas calls the "point where we can beat the competition (unique value proposition)" or "what the customer resonates with (concept)." I think building a shared understanding within the team is what matters here.

Build a "simple" scenario

To build a shared understanding, it seems to work better when there's more surrounding context. Set a simple, relatable scenario. Doing it simply is what matters. It should be light enough that redoing it from scratch is no big deal.

Fleshing out a simple scenario gradually evolves it into a customer journey map. (Probably.)

An approach like the one below seems easy to picture and easy to move forward on as a team.

A great intro to UX design! Easily visualize and share user experience with the "Irasutoya Scenario Method" | Bakko | note

Build a "simple" Lean Canvas

Rather than jumping straight to the whole thing, I think it's important to nail down the points that serve as your baseline. Service design involves all kinds of elements, and usually there's some confidence and grounding in some areas, and much less in others.

• Target
• What they're struggling with
• The solution
• What happens as a result
• +α

Taking this kind of loose information and making it concrete and detailed evolves it into a Lean Canvas. (Does it?)

• Target
  • Who is the customer? (customer segments)
  • Who are the early customers? (early adopters)
• What they're struggling with
  • Why would the customer be happy? (the problem being solved)
  • What is the customer doing right now? (existing alternatives)
• The solution
  • What are we providing the customer? (features, story)
• What happens as a result
  • How do we learn the customer's reaction? (key metrics)
  • What does the customer resonate with? (service concept)
• +α
  • The point where we can beat the competition (unique value proposition)
  • Why would the customer choose this service? (unfair advantage)

Costs and revenue aren't covered here. To keep improving the service sustainably, that's still a topic for the future.

That's it for now, though it's a bit unfinished.

I'd like to keep sharing this kind of perspective — "how do you pull a project together" — more and more within the company.