Discovery research as a team sport
In the service manual team, our mission is to provide ‘better guidance for teams creating government services’.
During our recent discovery phase we wanted to establish who our users are, and what their needs are, so we can provide the guidance they need to deliver better services.
We decided that if we all took part in user research during discovery, the whole team would get first-hand insight into our users’ needs. And this would give a clearer focus for prototype building and continuing user research during alpha.
This was new to me
This is the first time I've worked in government. And the first time I've done ‘Discovery’ research.
It was exciting, and initially a little intimidating, to work in a multidisciplinary team with so much interest in user research and articulating our users' needs. Everyone was keen to be involved in the research — including recruiting users, which is surprisingly time consuming.
3 weeks, 29 users and 7 locations
Our timeframe for discovery was short (just 4 weeks) and we wanted to speak to and observe as many users as possible.
Within 3 weeks, our team of 8 spoke to 29 people from London, Newcastle, Bristol, Birmingham, Coventry, Liverpool and Preston. And with the whole team involved, everyone had the chance to observe how users engage with the manual (or not, as we sometimes found).
Recruiting and then scheduling interviews across the country with multiple interviewers and note takers was challenging at times. We’ve used a simple spreadsheet, shared calendar and a visual board to track who and where we were interviewing.
To prepare the team for the interviews, I put together a brief ‘how to’ guide on the need for open questions and to resist interjecting (basically the the art of active listening). Everyone in the team also observed a session and acted as note taker before going out to lead an interview.
Observing users in their natural habitat
Going out and speaking to our users in their workplace meant that we saw first-hand the frustrations of not being able to find specific content in the service manual.
Some users solved this with bookmarks so that they could very quickly parachute to specific content. Others consulted with internal guides instead, because the manual is not entirely trusted or believed to be up to date.
We also saw how the manual looked on different browsers and devices, which we may not have seen in the lab.
Analysis as a team sport
Analysis involved us all coming together as a team with our 29 interview transcripts. This created a lot of fantastic insights (all captured on post-it notes), that we constantly moved and regrouped. We emerged with clear themes and some firm user needs.
We optimistically set aside one day for our analysis, but this ended up spilling over into a second. In hindsight, 2 or 3 half day sessions might have been better. Over the course of a whole day, despite the biscuits and chocolate, fatigue did set in.
What did we gain from the whole team doing discovery research?
Having everyone involved in research and analysis during discovery meant we avoided user research being used like an internal agency.
In previous jobs in agencies and even in house, I would get a brief, carry out the user research and then deliver insights: it didn’t work. Typically, I delivered insights too late and with frustratingly little impact.
On the service manual team we've all met people who use the manual. We all understand and can explain our users’ needs.
We're in a great position to address them during alpha and as we move into beta.
Keep in touch. Sign up to email updates from this blog. Follow Patricia on Twitter.
3 comments
Comment by AdrienR posted on
"To prepare the team for the interviews, I put together a brief ‘how to’ guide"
Would you be willing to share this guide openly? I'm always interested in seeing how others approach this. Thanks!
Comment by Alex posted on
Id also be keen to see this 'how to guide'
Comment by John Gibbard posted on
Thanks Tricia, great to hear the GDS perspective.