Picture the scene – you’ve just completed a user research piece, speaking to over 50 different participants. You’ve then collated the findings, pulled out key themes and insights, and now you need to round everything off by compiling a list of user needs. Simple, right?

User needs are one of – if not THE – most valuable asset in service design and development. They shape the service, telling you what will make it successful. After all, what’s the point in designing something that no one actually uses? Look at any common design standards and best practice – e.g. GDS, DSSS, Double Diamond – and you’ll find “understand user needs” at the very start of any guidance.

Identifying the Real User Needs

It’s easy to fall into the trap of thinking user needs are just writing out what the service needs to do from a user perspective. Whilst not technically wrong, it risks obscuring the core need to be addressed because firstly, you would be taking what the participants say they need at face value and/or secondly, you would jump straight to the solution.

The challenge lies in uncovering the real user needs from a tangle of “I think it should do this” and “why not make it do that”. As researchers we have to put on our detective hats to get to the root issue and express that as the user need.

Needs and Wants

Let’s take an example – 75% of the participants you engaged during research expressed frustration at not being able to view their submitted form after sending it off. Many stated this is because they wanted to remind themselves what they’d applied for so they could budget accordingly.

At first glance, one could assume that the user need is: “As a customer, I need to view my submitted form so that I can see how much money I can expect to get”.

Yes, some participants might have literally said “I need to see the submitted form”. If you break it down, what they actually want is to know how much money they’re going to get so they can budget accordingly. And that can be supported in a number of ways that aren’t necessarily showing them the submitted form.

Taking this into consideration, a more accurate expression of the user need is: “As a customer, I want to know how much money I will receive if my application is accepted so that I can budget accordingly”.

With this, a designer is able to verify how successful a proposed solution is by testing whether or not the customer can achieve the “so that”.

The Golden Rules of User Needs

At Informed, we cement best practice in user-centred design throughout our wider approach to service design and development. The InformedACADEMY™ Masterclass in Writing Good User Needs teaches the importance of accurate, evidenced user needs in developing an effective solution. This can be achieved by following our three golden rules:

1. User Wants, Not User Needs

No one has ever said “I need two factor authentication (2FA) when I log in”, but what they will want is reassurance that the service is secure. When turning findings from user research into user needs, it’s important to remember this distinction as it can be the key to both keeping users happy and making sure they get what they really need.

However, this is where the intersection between business requirements and user needs gets interesting. A business may require a user to have 2FA to use the service to comply with regulation, whereas the end user is likely to not care or, in some cases, be opposed to 2FA because of the extra effort involved. This requirement needs to be expressed from the perspectives of all the different people involved to accurately capture the complexity, as so:

  • “As the legal representative, I want users to have to login using 2FA, so that the service complies with regulation.”
  • “As the end user, I want to know the service is secure, so that I feel assured my data is protected.”
  • “As the end user, I want to log in as easily as possible, so that I can do what I want to do in the service.”

Rarely is a requirement as straightforward as only one person needing a very specific thing done in a very specific way. Good user needs and business requirements should be able to capture these intricacies and be used as a ruler to measure success against.

2. Back Up With Evidence

The reason user needs are such a valuable asset in designing and developing any service is because they are the single source of truth of what people actually need from the service. However, to confidently use them as such, they must be rooted in actual evidence. It’s therefore crucial to be able to point any captured needs to a real user research finding. If a user need can’t be backed up by something someone has actually said or be shown to do, then it is only an assumption.

Evidence-based user needs are the crucial link between user research and service design – they lay out exactly what the solution needs to do and why, and leave room for the designer to get creative in coming up with different ways to do that. Which brings us on to the final rule…

3. Always Be Agnostic of the Solution

When speaking to users during research, a common pitfall that many fall into is assuming a solution. It’s important to keep in mind that what users say they want is often reflective of what they know and have experienced. This might be based on their previous encounters with similar services or systems, but it doesn’t necessarily reflect what the best solution could be for meeting their underlying needs.

Let’s consider the earlier example where users expressed a need to view their submitted form. If we jump to the conclusion that the solution is simply giving them access to the form, we miss out on opportunities to create more innovative and potentially more effective solutions.

Instead of being confined by the solution users propose, take their input as an insight into their underlying needs and use that to inform the design process. You’ll find that there are countless ways to fulfil a user’s need, and by not being tied to a specific solution, your service design can become a lot more creative and effective.

Writing good user needs is an often-overlooked step in the development process. When given the consideration it deserves, informed by accurate and evidence-based user needs research, it can be the difference between a good-enough solution and a great one.