User needs and business requirements
This post came from an interesting Slack discussion about the first of the UK government design principles — ‘start with user needs’.
Some people felt that it’s not a helpful approach, because it appears to ignore very important considerations — like whether the thing is legal, or is consistent with the organisation’s obligation to be transparent.
Others felt, equally strongly, that it’s important to emphasise user needs.
Personally, this is the way I think about it.
What is a user need?
Where services are concerned, the point of the user needs approach (or dogma, depending on your point of view) isn’t that other things aren’t important.
The point is to be clear that user needs are a special category of thing. ‘What is the user need?’ is a first order problem, the thing you start with. Because if a service isn’t solving a genuine problem for users, it’s not worth moving on to second order questions.
On the other hand, not everything is a service. When you’re not talking about services, things that don’t have a user need can still be worthwhile. For example, sometimes it’s worth publishing things purely for transparency or accountability purposes.
Talking about user needs
I get the impression that when we talk about user needs, it’s often understood as “our dogma is user needs only, and nothing else is important”.
Obviously that’s not true. What we want to say is something more like “our approach to service design is user needs first, but we’ve made the effort to understand your objectives — and here’s how our approach will help you meet them”.
Another problem is that sometimes people think starting with user needs is an indication of well-meaning but flabby thinking. But the truth is that done right, it’s a highly rigorous approach.
And it’s very pragmatic: much more so than what’s sometimes called ‘requirements gathering’. There’s no bigger waste of time or money than solving the wrong problem. Starting with user needs can help prevent that.
Starting with user needs, then delivering
People sometimes talk about user needs and business needs — outcomes the organisation wants to achieve — as if they’re inevitably in conflict. I don’t think it has to be that way.
An approach that starts with user needs is actually more likely to deliver on business outcomes.
Firstly because it’s strongly associated with design approaches that favour building and testing prototypes of real things rather than theorising. A prototype isn’t the same thing as a mock up. If it doesn’t let you explore the constraints involved in building the real thing, it’s not really a prototype.
And secondly because it’s associated with iterative approaches to delivering things. That means you should be identifying your riskiest assumptions — whether they’re about user behaviour, technical constraints, business outcomes or something else — and testing them often.
So starting with user needs — and the approaches that go with it — mean you’ll learn about the constraints you’re working in very quickly.
And because you’re working in an iterative way, you can’t go very long without coming up against those constraints: and demonstrating that your solution can work within them.
Feel free to agree/disagree by leaving a comment below.
Image of stickers by #govdesign. Used under a creative commons licence.
