Skip to content
Gallery
Example user needs repository
Database of original and refined needs
Medium posts
Look up tables
More
Share
Explore
Medium posts

icon picker
User needs refinement — why and how to do it

⁠
https://medium.com/researchops-community/user-needs-refinement-why-and-how-to-do-it-2ca4d28ade0d?source=friends_link&sk=dc6816ec62357664e1906ac63d494d5f
⁠
⁠
I refined several hundred stories and discovered a host of new insights.
I did this as part of building a user research repository but as user needs are fundamental to user experience, both research and design, I split this section out from my 
main post on user research repositories
⁠
.
⁠
⁠
⁠
Photo by 
Daria Nepriakhina
⁠
 on 
Unsplash
⁠
⁠
Refining user needs was by far the most satisfying part of tidying up user research. The organisation I was contracted for had over 1,000 user stories. Some had been created to 
GDS principles
⁠
, while others were created years ago and can best be described as a wish list.
So I tidied them up and standardised them. It’s important to note that this is not the way but a way that has really helped me and teams with user needs.

User needs vs User stories — a note on terminology

I use both user need and user story because people use both.
I prefer user need as user stories are used beyond user research and it helps focus creation on what users need, not what they want.

Examples of tidying up user needs

It’s easier to see examples than just to talk through. As such I’ve taken the 
user needs on Hackney’s library project page
⁠
 and refined them in this 
AirTable document
⁠
 and this 
Coda.io document that you can play around with
⁠
.
I’ve created two tables in both AirTable and Coda.io — the original user needs and the revised version so you can see the differences I’ve made.
Note that I’ve not done any work on Hackney’s project, I’ve come in blind. My editing is not intended to criticise and my refinement only took less than an hour — hardly time to properly digest. My review is to give examples, not to critique.
I wanted some open needs as I did not want to use my client’s, Llibertat and the University of Southampton OneWeb project, which is making the University’s web content more user-centred. Hackney has a good selection and they worked well for this exercise.

What makes a user need

⁠
⁠
⁠
Photo by 
Stéphan Valentin
⁠
 on 
Unsplash
⁠
⁠
⁠
Traditionally a user need
⁠
 is (or is a variant of) As a/I need to/So that — however, I’ve made a slight change::
Split “As a” into both“As a” and “Who is” — this allows you to make your key user types (“As a”) consistent and easier to group, as “Who is” allows you to see cross-cutting secondary features (e.g. all users with accessibility needs, or those without a login)
I need to — ideally you should be focusing on “needs” here and not “I want to”
So that — this must be the goal or outcome. It’s easy to confuse this with “I need to”, but this is the higher goal, e.g. getting a passport. The “I need” is to get one because the ultimate goal (“So that”) is to be able to legally travel to another country.
⁠
⁠
⁠
Before refining the user stories
⁠
⁠
⁠
After: User type/As a/Who is/I need to/So that example
I feel that “So that” needs a little more of an explanation. Once you have “So that” focused on goals you will be able to standardise them as users typically have a limited range of needs within a system
Likewise making the “So that” outcomes more consistent made it easy to spot duplicates. It also made it easy to group by outcomes and assign categories and needs.
In the “Tidying up and finding insights” section of this post I list examples to help make things clearer.

Refinement process

Once you have your core needs you can start designing for your users.
But if you want to start making insights — such as finding groupings of needs or themes wherein the journey they occur, gaps in needs, or similar — you need to tag and categorise so that you can then uncover those insights and gaps.
My refinement was in 3 parts then:
Focus on standardising and reviewing the needs into As a/Who is/I need to/So that.
Tag, categorise, and group the needs.
Review to uncover insights and gaps.
I found by doing this that several columns in my database could be standardised as drop-down selectors (aka pick from a list) because:
The client had a limited range of user types.
Using a drop-down prevents the mess of similar but different user types we had created by forcing new needs to follow a pattern (although there is freedom to create new types as needed).
⁠
⁠
⁠
Dropdown selector, aka pick from a list

Refining and tagging use needs

Following a similar sift, tag and group principle I used for organising documents I applied this to user needs and created categories. The columns I used in database (and you can see in the AirTable example or Coda.io example) were:
Unique ID — automatically generated, helpful to enable referring to specific needs consistently, especially if you edit them
User type — a drop-down of the high-level types of user (in the example this is user researcher/team member/member of the public)
As a — a drop-down with a fairly limited range because we’ve introduced…
Who is — another drop-down, using this means that “As a” could be more limited. Constricting “As a” made it easier to group and see common users while “Who is” groupings did the same (e.g. users with an accessibility need meant we could group all with this need regardless of their parent “As a”)
I need to — free text, as the need can be wide-ranging
So that — surprisingly after grouping, I realised that many outcomes were similar despite varying needs so we also made this a drop-down
Acceptance criteria — a free text list of the criteria
Joined user need — a formula that combines As a/Who is/I need to/So that to make the story easy to read and share
Theme — a drop-down used to categorise what the outcome was about (eg financial, motivational)
Category user need — a drop-down, and by grouping needs into overarching needs, or epics, it allowed us to see where the stories fell and it was better for summarising what needs a project was using when presenting to others. Typically we’d produce around 60–80 needs per project and so summarising with 8–12 epics helped others understand our findings
Journey stage — drop down, where we had mapped the user journey, to help us understand where the need came in the journey and help service designers
The Project that produced it — a drop-down and used to identify projects with missing needs and understand where the needs were targeted towards
⁠
⁠
⁠
Full range of columns
Some parts are to be completed by future project teams — having these columns lets them know there’s work to be done when they use these needs in their project:
Projects this apply to — when future researchers review the needs they may wish to mark the needs they plan to use
Failure impacts — free text summary of what happens if you don’t meet the need
Success impact — free text summary of benefits of meeting the need
Success measures — some, but not most, needs can have a success measurement

Tidying up and finding insights

Once the stories were made consistent I played around with the groupings. As each category that wasn’t free text could be grouped it made it easy to do so.
⁠
⁠
⁠
Grouped by outcome helps see similar needs
As the original needs only had As a/I need to/So that. This meant the first task was to split the “As a” into “As a/Who is” as appropriate. From there it was much simpler to assign user types and understand the fundamental range of user types.
After making the As a/Who is groupings consistent we could spot duplicates. We could also get rid of some obvious non-needs.
Once we have these tags we can group, review, refine, and then assign epics.
Insights that came from the example for creating a repository include:
a lot of the outcomes were around user-friendliness and user appropriateness — from 32 needs I only used 19 “so that” outcomes
⁠
⁠
⁠
most needs are at the start of the journey (9 needs for Creation) or Library Management (11), but only 3 for Editing and 1 for Reviewing. Does this mean we are missing needs at some stages of the journey?
most user needs (all but 3) are for user researchers — are we confident we’ve captured all users?
3 Category user needs only have one user need — we should review whether the category user need is appropriate, or that there should be more user needs to go with this category user need
we have 11 Category user needs for 39 user needs — this is easier for stakeholders to digest and to get a top-level view of what the key things the project is to fulfill
⁠
⁠
⁠

Refining user needs as a process

Refining user needs can happen at any stage, even if you only have 20 user needs. And the more needs you have, the more you should review them.
While the biggest task is creating the user needs repository it should be treated as a living document. As such reviewing user needs should be part of the start of any project, and updating and reviewing user needs (both new ones and existing ones) should be done at the end as we refine our view of users.
It’s essential that the team is involved in a review. But it works best if the user research takes responsibility for doing the bulk of initial refinement and the team inputs on their groupings, outcomes, and categorising of user needs.
Reviewing user needs as a team should already be a part of any agile team’s workflow, and reviewing how your user needs group and fit into wider user needs should be added to this.
This will take time, and if you uncover gaps it may require new research, so ideally this should not be left to the very end but towards the end of a project with enough time to conduct new research.
The outcome is that your team should be more confident in its understanding of your users, and users should benefit from having their needs better understood.
This repository and refined needs were produced to aid the work that my clients 
Llibertat
⁠
 and 
University of Southampton OneWeb project
⁠
 is doing to take a user-centred approach to its web content.
Don’t forget to read the 
companion part
⁠
 of this 2-part post on creating a user research repository. You can also 
connect with me on LinkedIn
⁠
.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.