15 February 2016, 12:01
Below, we see the users of a product—e.g. a piece of software, an (internet) service, a device:
All users are different. Above we see the diversity of this user society depicted in two dimensions; no two are in the same spot. In reality this spread happens in dozens of dimensions. Even for very specialised user groups like ‘font designers for indochinese languages,’ there is plenty of diversity in many dimensions.
We all act like selfish punters; you, me, everyone. And when we are individually engaged in talk about a product, we will offer self‐centred opinions on what matters most and self-serving feature requests, i.e. our wants:
The dynamic we see illustrated above is very common in the software industry. You will find it in 99% of—
- custom software projects for companies, NGOs or the government, during requirements gathering;
- small and medium‐sized software companies where the boss, sales, support and/or consultants talk to customers and users;
- any kind of user forum, online or otherwise;
- take (a variant of) the second point above and combine it with the third, that’s F/LOSS, all of it;
- anywhere where market research is deployed.
write write, scribble scribble
It is also very common in the software industry to earnestly administrate user wants:
Common forms of this are—
- lists of use cases;
- use cases in sheep’s clothing: user stories;
- bug trackers; not necessarily as an enhancement or a feature request, it may be dressed up as a bug, or a usability problem;
- feature roadmaps;
- a lingering pressure, guilt, or fear in the minds of those in charge—boss, product manager, or maintainer;
- a consensus among (part of) the crew: ‘people keep asking for XYZ, we could hack something basic in a couple of days’ (yeah sure).
Now we can compare this administration of wants to the user society:
We see that at best, wants are good at describing the fringe of the society, but 80% of them are downright far‑out and esoteric.
Since wants are so overwhelmingly used in the industry to drive products and projects, there is overwhelming evidence that this leads to awful results. It is completely normal that a majority of time and talent is spent on adding far‑out and esoteric features that are instant bloat.
And thus everybody loses: makers, users and financial backers.
doing it right
Now we are going to stop flirting with disaster.
User research avoids all what has been described up to now in this post. The focus is on—
- finding out what users need;
- quality and depth of these findings;
- understanding the mechanisms at play.
Instead of listening to everbody and their dog, researchers accompany a selection of representative participants on a ‘journey‘ through the pertaining activity, while constantly picking their brain:
Above, we see depicted that when users still insist on pushing their wants (i.e. go far out), researchers reel them in by questioning; peeling away layers of rationalisation in order to understand the underlying needs.
These needs are not exotic, they are basic human needs (e.g. control, overview, feedback, organisation, a stable environment, a simple rule book) that form the center of the picture—and are central to making it work for users.
Researchers and designers collaborate on constructing a model—an understanding—of the user society. The centre of the picture is where one finds the commonalities in the (analysed) research material:
This is the heart of the matter. It is surrounded by the diversity in needs as found by the research. Note that there is a hard edge to this model: what is outside is certainly out of scope.
The qualitative aspect of research (e.g. taking into account the tone of voice or facial expression when something is stated) makes a world of difference. It is this richness of information that makes user research so effective. We see above that some outliers have been ignored in the user model. This is done with full confidence, based on the research.
Now we can compare the needs‐based user model to the user society:
The coverage of the model works out so well, that it is difficult to see the actual users. This is especially true for the heart of the matter. Note that some users at the very fringe of society may feel left out; they are covered a little bit or not at all.
In a design‐driven approach, the needs‐based user model is used to decide which features to add (cover the diversity, but nothing beyond the edge) and where to focus design and development effort (on the heart of the matter).
Zooming out, we now can compare the two approaches:
When compared to the results of user research, the bog standard, wildly popular method of listening to users and their wants—
- fails to record the heart of the matter;
- fails to record the diversity of user needs;
- is a list of disparate wishes, instead of a coherent, nuanced insight;
- highlights the fringe, the far‑out, the esoteric;
- gets you completely the wrong picture.
This past semester I discussed all this with my students at the BTK design school. To get the point across about the dangers of talking to users, I asked them ‘do you remember these creatures in mythology that always give you the wrong answer, so that you get lost?’
‘Yeah’, they said, ‘they are called trolls.’
If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.
What is Peter up to? See his /now page.