“Start with user needs” is a phrase we hear a lot. It’s the first GDS design principle. It’s also the first principle in Parliament’s Digital Strategy. I’ve blogged previously about what I feel ‘start with user needs’ means and everyone agrees that starting with user needs sounds like the sort of thing we should be doing.
Starting with user needs however isn’t the end of a researcher’s responsibility for users. In this post I want to share my thoughts about what happens after ‘starting with user needs’.
Prioritising user needs
On American lawyer TV shows, there’s a phrase they mention that’s stuck with me. It’s that the “duty of a lawyer, both to his client and to the legal system, is to represent his client zealously within the bounds of the law.” This reminds me of a user researcher’s role in product development.
During the discovery phase a team will put a lot of work into understanding the technical requirements, business goals and user needs for a service. They then come up with a pitch for a good idea.
As the project continues into alpha and beta, there are hundreds of other small decisions to make. When a product manager makes decisions about their product or service, their role is a balancing act. They need to carefully consider what users are trying to achieve, what ‘the business’ wants to happen and what’s technically reasonable to build. This lets them make decisions about what the product should be and how it should work. This is the difficult bit.
The product manager is often under extreme pressure from many sides. The business goals are often represented by senior people who push for what ‘the business’ wants. The technical people are experts in what’s possible and ultimately are the ones building it so have a lot of influence over what happens with the product as it develops. They advocate for what’s technically ‘reasonable’ to achieve. Under this pressure, over time, the product can start to drift.
So it’s the researcher’s job to fix this imbalance.
What we can do about it
Using the American lawyer example:
The duty of a user researcher, both to the users and to the product, is to represent the users zealously within the bounds of their research.
This is achieved by making sure that product team members are:
- regularly exposed to users
- understand what users are trying to achieve with their product and whether they are able to achieve those goals
- identifying where assumptions are being made in their product decisions and validating those assumptions
- able to access relevant, timely and trusted research
By making sure all these things happen, user researchers will advocate for the user’s needs throughout the delivery of the product.
The product manager’s decisions will therefore be a compromise between business, technical and user needs. And we’re okay with that (just). As researchers we want to be confident that we’ve done everything possible to make sure the product manager (and the wider team) has understood what users need from the product.
We also want to anticipate the impact failing to meet these user needs will have on the user’s experience and on making sensible and informed decisions.
This has some implications
Does it mean slower delivery? Perhaps. It means having hard conversations before making decisions. It means learning more when appropriate. It’ll take longer to have something to look at but after those conversations, the product team will have confidence that they’re building the right thing. It means less duplication and lowering risk by letting the team make informed decisions. This means the thing they build will actually be useful.
Does this mean the business doesn’t always get what they want? Definitely. But user centred design means building things people will actually use, not what we hope they’ll use. Representatives from ‘the business’ aren’t perfect and their assumptions about what’s needed need validation. This often reveals nuances and details that would be missed without research.
In summary, building user centred software means a researcher’s job goes far beyond ‘finding things out’. It includes a commitment to making sure the team listen to what’s been learned and apply it to their work. In Parliament, user researchers will be continuing to advocate for user needs throughout the development of our products.
Read more about the work of the user research team.