Know your users - what does it mean to you?


The tentative proposal (I’ll update that section in response to the discussion):

Know your users (e.g. customers, shareholders, regulators, staff)

The purpose of this is to think beyond your product and direct sales. Without having a broader picture it is difficult to differentiate between the product (a camera) with a need (share important moments), and therefore many opportunities for innovation and potential threats can go unnoticed for a very long time.

Desired practices and behaviours

  1. Know who are your users, f.e. customers, regulators, employees, etc.
    • Look at transactions over last x years. Pareto filter it and group into recognisable buckets of users
  2. Know what they are trying to achieve:
    • what is their “official” purpose (f.e. reduce unemployment, help their customers)?
    • what drives them (bonuses, return on investment, challenge, inertia)?
    • if they are driven by other users (f.e. the board put under pressure by investors), you have to understand both groups, and their options
  3. Monitor feature requests and bug reports - if they are difficult to understand, the customer situation may be different from what it appears.
  4. If you can, experiment to uncover needs that have not been yet verbalised.

Useful resources

Knowledgable people in the field


Hey everyone,

to give you a bit of a context - I have created a clickable version of Simon’s doctrine table at doctrine.wardleymaps.com. A screenshot below:

One of the first comments was to add some sort of tooltip explanation of what specific patterns mean, and how they can be assessed. I must admit - I tend to be opinionated about those, but I would love to hear your opinion first.

What is your ‘Know your users’ checklist?

How do you know whether you know enough?

Do you have any useful resources or specific people to follow?

Hopefully, together, we will create an entire doctrine handbook :-), but for a starter, I propose to discuss items one by one.

I always think about “who needs to know about users” (not in a restrictive manner) to discover blindsided teams.
Then I check if we have a simple split of users into relevant categories (by revenue stream/stakeholder/regulator impact etc.) so we can at least validate we know them as those big buckets (before we go into Persona’s eventually).
Then I’d say it’s important to demonstrate the existence of communication channels (bidirectional ideally) and prove they have adequate engagement.
The above are basic stuff… more can be said going to into the meaty “know your user”… but i see many orgs lacking even the above.

1 Like

Excellent idea. It might turn into a succinct summary of different fields.

I will reply to this topic in more detail later from a perspective of a user researcher.

But anyway this is a nice article https://medium.com/@joeblair/wardley-maps-1-true-user-needs-18b39c9fedb1 – user needs are crucial part of our doctrine and have enourmous impact on our landscape and how we think about it…

@my1, you have no idea how excited I am to hear a true user researcher opinion on this :-). I will keep you accountable to your promise :D.

Muhehe. Just returned from vacation. OK, lets do this.

One of the things I think that can be improved in mapping in general is a treatment of user needs. Most of the maps are about capabilities the company have to fulfill these needs but there is very little about the needs themselves.

Simon says that you need to talk to users but then – when you go through the examples of maps – the user needs are most of the time just in form of node CUSTOMER that uses some visible capabilities. And no needs are stated in the map itself.

Every map has anchor in user needs and still user needs are not in most maps you can find on the internet. For example they are here https://opensecsummit.org/tracks/wardley-maps/user-sessions/using-wardley-maps-on-soc/ but not in the famous teashop example here https://twitter.com/swardley/status/1066455099675983876

I think we need to do at least two things to improve mapping in general not just the doctrine:

  • add more detailed user research practice to general mapping process – if you want to map, you should have done THIS to create THIS
  • add more user context to the map itself

The thing is – what kind of information about users is really valuable for mapping? Is it just a short statement in form “user needs this” or “survive” is it more about defining a segment with needs, motivations & pains that evolve during user/customer journey and they might be different in different parts of process?

What does user really need anyway? :slight_smile:

  • Cup of tea
  • Place to work without interruptions for a few hours
  • Island of peace during travels
  • Silent place to think
  • Crowded place for a meeting

The different need wording might create different maps and team discussions around the map.

2 Likes

Evolution suggest the following thing:

  • Genesis - no point in talking to customers as they do not exist yet, just experiment
  • Product->Utility transition - just design, because your customers will not tell you what you need to do, they will request cheaper products but they will unwilling to transition to something with very different characteristics
  • Incremental updates (from custom-built to product, but also often in utility after industrialisation) - listen to customers

Just a note - there are two very close doctrine positions - Know your users and Focus on user needs. I am not sure where to draw a line between them.

And I am inclined to say you need to understand motivation of every big player in your industry. A common case is an investor that diversifies risk on a portfolio level, and is rather interested in sweating existing assets than transformation of the company, as he already invested in another company operating in potential target environment.

About the cup of tea example, I see it the same way - lots of Users and their needs should be fleshed out more.

One of the excellent quick explanations that I’ve come across was from a 28 minute video from Chris Matt, where he teases out Users Needs, then builds on that to work who the users are., having begun with the question when someone asked for a tea bag.

In those minutes, he covers a lot of ground, such as:

  • building up Segments defined by User Needs, which are then documented as Personas.
  • From Needs for different groups, he touches on Business Value (in terms of different measures other than Money: activity, Net Value Score).
  • Then where hypothesis/assumptions come that need to be (in)validated.
  • By combining a particular need for a particular segment, and specific value comes the “design roof” in which we design something to meet this need (MVP).
  • For another combination of need, segment, and value, the design roof changes - what gets designed is totally different based on this combination.
  • From this, we’re able to slice this chunk of work (the cup of tea, aka product) into smaller deliverable slices.
  • At 13:42 - the roles are discussed. Even though whole team is involved, the one that leads depends on what’s being covered/worked on:
    • the analyst (would cover the tea bags, how to source them, etc),
    • the User Researcher (looks into user needs & segments),
    • the product owner (understands the business value+risk and their relation to user needs+segments) in order to know how to order the backlog
    • the designer (takes care of the design with the design roof)
  • At from 15:57 - how that designs get turned into User Stories and Epics and where Acceptance Criteria (given-when-then format)
  • At 23:22, as he’s working back from the design to the acceptance critera, we can see one of the steps being moved/thought of as a product/commodity because, on the one hand, it’s used by everyone, and on the other hand, it contributed nothing to the epic.
  • At 26:17 by using this pattern, working backwards from the outcome, we end up with decent value chain.

P.S. That’s one of the videos I’d like to create a map for :slight_smile:

Last week, with Tom Kervin and @john.grant, we had a nice chat about the identification of user needs. Tom brought an entire least of frameworks:

  • What user needs mean?
    • What people are trying to do (goals)
    • What they’re actually doing (tasks)
    • Where they are (contexts)
    • How they act (behaviours)
    • How they feel (emotions)
    • What their mental models are (beliefs)
    • Where their pain points are (problems)
    • What capacities they have (capabilities)
  • What are all the ways [for user research]?
    • Mental models
    • Task analysis
    • JTBD
    • Market Research
    • Neuromarketing
    • Interviews
    • Observation
    • Implicit Bias Studies
    • Zaltman Metaphor Elicitation Technique??
    • Contextual Interview
    • Lean Customer Development
    • Lean Startup
    • Sales Safari
    • SenseMaker from Cognitive Edge
    • Usability Testing
    • Usability / Feasibility / Desirability /
    • Growth Hacking
    • Pretotyping
    • Future Insight
    • Market-first / Product-first
    • Positioning
    • Product-Market Fit
    • Go To Market

Each of those is almost a domain in its own, and as we were going down the rabbit hole, I have realised quite surprising (to me, because it was obvious to others) dependency - none of those will work if you don’t have a proper target group or you have a wrong one.

To give a complete picture to anyone interested in the subject, we have created two not-exactly-in-line perspectives. Let us know, whether this is useful.

John’s write up

As machine intelligence becomes more pervasive, I suspect user-centred design will more likely occur in the context of nonlinear emergent processes. The Two Loops Model by Wheatley and Frieze (Berkana Institute) illustrates the lifecycle overlap of the old and the new. User needs will evolve in both contexts.

Awareness of user needs in systems in decline are as important as aligning needs with emergent systems. I would like to see if it’s possible to map the two loops as an organisation attempts a radical redesign or migration, and in particular how needs can be met in terms of ongoing maintenance.


Diagram: The Berkana Institute’s Two Loop model

Tom’s write up

We were mapping for as-yet unknown user needs. When you have an existing business with — crucially — people paying you money for products or services, you can triangulate user needs from transactions of value: what do people pay you for. These are important user needs to understand, and that’s why Know The User is in the first tranche of Doctrine.

But what about when you’re trying to learn about a user need you don’t yet serve? What about when you’re trying to learn about the user needs in an audience you don’t yet have?

What if we map, using the business’ need to know the user need as the anchor.

This is the realm of customer research, customer development, and market research. How do these map out? What does that mean for people like me who work in this area?

Within these fields there are more and less established techniques and approaches – and more and less effective techniques and approaches. It also becomes clear that approaches have evolved over time under competition. Understanding user needs more deeply and completely than your competition is a winning advantage.

Questions:

  • how does context play in?
    I suppose you could argue that there are bigger building blocks we can look at. We can clump the approaches together and see what they’re built on top of.
  • Where does market research come from?
    I remember seeing a discussion of the difference between market and customer research being their backgrounds: market research from sociology vs customer research being from ethnography (and user research from ergonomics). Some say the split is between what people say vs what they do, but there are an increasing number of marketers who recognise people can’t usually tell you the answers.

Another way you could break down user needs is by how established the need is. Copywriters talk about understanding a prospect’s awareness:

  • problem unaware: not aware that they have a need at all
  • problem aware: a niggling need, but they either don’t know the need can be met or it’s not a big enough need to bother
  • solution aware: the need is clear enough that they’re actively looking into how to meet it, considering options
  • product aware: they are implicitly clear about their need and know that your specific product could meet the need

There’s an evolution here, like on any map. A user need can move from unrecognised to vague awareness, through increasing levels of frustration, up to the point where the person does something to meet their need.
Some of the popular models of buying cycles go something like this:

Unawareness –> Problem recognition –> Interest –> Consideration –> Justification –> Purchase –> Follow up

But this is an overly rationalistic view of the purchase cycle. And it doesn’t take into account the fact that a person may well start doing something to meet a need poorly before they’re consciously aware of the need, or able to express it.

It’s understood from Jobs To Be Done (which is basically old user ethnography in a C-suite tie and jacket) that an explicit JTBD may have between 5 and 25 hidden emotional and social JTBD along with it.
One of the critical insights to start with is that — in user research at least — “user needs” is a kind of shorthand for a bunch of information about the user. Explicit and implicit goals are the building blocks, and these are both affected by context.

Chris’ write up

Later, when I draw a map (we run out of time during the meeting), it become even more apparent to me that user needs exists have different levels of associated uncertainty. Some can be analysed with very analytical tools (JTBD), some require experimentation, and some rely on user manipulation.

What is extremely interesting is that Tom sees the situation to be a little bit different:

,
which is puzzling and worth further investigation of what Tom knows that I do not. But notice the main point - there is the ethnographic factor on the bottom of the map.

That ethnographic factors complicates the whole picture, as it is no longer about user need identification, but about finding the right group of people and matching their situation with a proper research tool. I am afraid this is not the clear answer I was hoping to find :smiley: and certainly not the one I wanted to see.

Bonus

Tom attempted to paint a picture of what do you need to apply a particular tool. It forms another interesting cycle - given what is your hypothesis about the user need, you pick a different method of testing it, and apply different approaches to potential target group selection.

TL;DR

One size does not fit all. Be creative.
2 Likes