5 Ways to Represent User Needs on a Wardley Map

Jan Rezac asks: “How should I represent user needs when mapping? Because quite a lot of maps do NOT have user needs clearly stated (even Simon’s original teashop map & Canonical map).”

Short answer? It depends!

Wardley Mapping highlights areas of ignorance — things people ought to know but don’t. Dealing with ignorance involves creating knowledge of the situation — situational awareness — which helps us be better informed and make better decisions.

The first area of ignorance most first-time mappers run into is their users and user needs. While we often see users at the top of a Wardley Map, it’s a little less clear how to best represent their needs.

I think that’s because there are a few different ways to do it, and they all seem to work just fine. I’ll expand on five of them in this post.

Option 1: Implied Needs

In some cases, I think it’s fine to imply that the needs are there but leave them off the map. In this style, the users have a direct relationship with the capabilities, and the needs themselves are absent.

In the example below, while “virtual fitting” is not the Customer’s direct need, we can probably guess generally what kind of needs it might be fulfilling (e.g., “confidence in a purchase”).

This approach is just fine if a need is rather common. For example, we are unlikely to question the deeper need being met when someone says, “I need coffee.” Coffee is not itself a user need, but it definitely fulfills needs many tacitly understand.

Another situation where implied needs work well is when it’s the first draft of the map. Because mapping is not all-or-nothing, we don’t necessarily need to get extremely detailed right away. Rather, we always start from somewhere and increase the detail as we find important areas of ignorance to clear up. Implying needs at first (instead of exhaustively listing them out) is just fine in that case.

Option 2: Annotated Needs

A second approach, which builds on the first, is to annotate the relationships between users and capabilities on the map. The needs can be sketched along those relationships so it’s clear they are what’s exchanged between users and capabilities.

This style can save a lot of space on your map while also packing in more detail.

Option 3: Needs as User Journeys

In Simon’s book, he suggests documenting all transactions that happen between the organization and the outside world, and then organizing those transactions in terms of the customer’s journey. While the user journey on its own can be helpful for identifying extra steps, missing steps, and other problems, it’s also a helpful way to represent user needs on your Wardley Map.

The problem is that a user journey breaks the x-axis by making left-right movement correspond to steps in a process rather than stages of evolution. With a small adjustment, you can solve that problem and keep the difference clear.

Just sketch out the user journey above the map and draw a separator to make the distinction clear.

This approach is useful when you need to understand how different capabilities affect the user experience. It’s also helpful if the folks doing the mapping are new to focusing on user needs and need practice.

Option 4: Needs as Knowledge

The degree to which we understand our users’ needs might also be worth accounting for. In this case we can use the regular evolutionary stages, horizontally positioning our model of each user need to correspond to Concept, Hypothesis, Theory, or Accepted.

This approach is especially useful if we must be mindful that we have different degrees of understanding regarding the users’ needs. We might decide to invest in improving our knowledge of a particular need in order to understand it better.

Option 5: Needs as Capability

Finally, we can represent user needs as capabilities that the user aims to possess. I like to use stages 1-4 to describe the capability in terms of Gambles, Decent Bets, User Demands, and Supplier Mandates, but the rest of the evolutionary characteristics cheat sheet can be used as well.

I often take this approach, since it means I can treat the needs exactly the same as capabilities. It’s also the approach embedded into the Wardley Mapping Workbook templates.

A Menu, not a Prescription 

Which of these ways is best? It depends! Your preferences and your situation determine the answer, so think of this post as a menu of options to try out until you find something that works.

How do you represent user needs in your Wardley Maps? Comment below, or join the discussion on Twitter!


  1. Hi Ben – great article (and naturally always interesting to see virtual fitting rooms in map given what my company (Metail) is in!).
    Could you go into a bit more detail about the 4 capability stages in the final diagram?

    Do you have examples of GAMBLES, DECENT BETS, USER DEMANDS, and SUPPLIER MANDATES from the capability perspective? Particularly USER DEMANDS and SUPPLIER MANDATES, which I was having trouble with.

    I’ve tried to have a go at writing out what it could mean with possible examples if an *online clothing retailer* is the user & anchor…

    1. GAMBLE: a capability the user is not sure whether they need but is will to take a gamble on trying to acquire…e.g., VR catalog of their clothes

    2. DECENT BET: a capability the user believes they are likely to need…e.g., presence on TikTok as their customers’ spend more time on this newer social channel getting increased publicity

    3. USER DEMAND: a capability which there is increasing user demand for and consolidating into accepted forms…e.g., SEO optimisation

    4. SUPPLIER MANDATE: a capability that is so commonly required by users that it is essentially a cost of doing business and has an accepted form mandated by suppliers of the capability…e.g., credit card payment processing

    Have I understood correctly? Are there more suitable examples?



    1. Hi Vikesh! The gambles –> supplier mandates progression is just a hand-selection of characteristics from the Evolution table. And you’re definitely testing it out more rigorously than I did! 😅I envisioned it being used not so much as an evaluation of what the user thinks, but as an evaluation of what _we_ think about how evolved that need is. Do we, the mapmakers, believe it’s a gamble? Or do we think it’s more of a decent bet? Or are the users demanding it? Or… is the need so well understood that we already know the right answer and in fact tell the user what they’re going to get?

      That last one is tough.. I think I’ve replaced “supplier mandate” with “cost of doing business” in further iterations.

      I think there’s an interesting progression there… Stages 1 and 2 are us sensing. Stage 3 is the users demanding. Stage 4 is us telling them what they get. Not sure if that’s truth, but it’s interesting to examine.

      All that to say, I think you’ve understood correctly, and your examples are great. Thanks Vikesh!

Leave a Reply