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¬†
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¬†
, 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¬†
¬†way that has really helped me and teams with user needs.
User needs vs User stories ‚Äî a note on terminology
I use both¬†
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¬†
¬†and refined them in this¬†
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
¬†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.
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
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¬†
¬†is doing to take a user-centred approach to its web content.
Don‚Äôt forget to read the¬†
¬†of this 2-part post on creating a user research repository. You can also¬†