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!