At GDS we’ve spoken many times about the importance of user research in the design, build and provision of public services.
We’ve also strongly recommended that everyone in a product team should be involved in the research process. This will give them a thorough understanding of what needs to be done first and why.
For those of us who work on the technical aspects of services, going to user research sessions can feel like precious time away from our main focus. But in the GOV.UK Notify team we’ve been encouraging stronger developer engagement in the research process in an interesting way.
Learning from the NHS alpha
The team on the NHS alpha wrote a piece about getting developers involved in user research. Will Myddelton, a researcher on GOV.UK Notify, took that blog and applied it to our team.
Every developer signs up to at least one session on lab day, and they have to be lead note taker for that particular session. (We’re fortunate to have our own user research lab on the premises so there's no reason not to attend.)
Note taking is crucial. As a note taker, the developer now has a greater responsibility to go to sessions and play a valuable role.
Note taking do’s and don’ts
To make sure the notes are consistent and useful, Will set some note-taking rules:
- notes have to be on colour-coded post-its with the participant number in the corner
- make notes on quotations and observations
- don’t make notes on general problems, only note what the user was actually doing
- don’t note down solutions (the objective is to capture the facts, and then think of solutions after analysis)
When we analyse the user research (in sessions called ‘playbacks’), the developer will lead instead of the user researcher. Each developer takes the whole product team through everything they noted down in their user's lab session.
What we’ve learned from this new approach
Developers now come to user research sessions as participants not just observers.
They have an important role to play leading the sessions, and making sure insight is properly recorded and played back to the wider team.
Developers have a better understanding of the issues users experience, and why the team’s work is prioritised in a particular way.
Piles of post-its stuck on a wall are a very persuasive visual indicator of why an issue needs to be resolved. If you’ve spent time explaining each issue to the team, then it’s crystal clear what needs attention.
It’s extraordinarily hard to watch someone struggle to use something you’ve built. Our initial login implementation was taking some users ten minutes or so, and even then they were still failing to complete the task. This was due to a combination of the page flow and a bug. It was dreadful to watch so we fixed that first.
If you work in central government are interested in using GOV.UK Notify in your service, let us know.
Follow Martyn on Twitter and don't forget to sign up for email alerts.
1 comment
Comment by Mr Anon posted on
"notes have to be on colour-coded post-its" - I think you might be able to successfully achieve this without coloured post its.
The worship of post-its is becoming such a cliché. "Individuals and interactions, over tools and processes". Post-its are just a tool, there are other ways!