Recently the User Research team at PDS went to visit the GOV.UK Verify User Research team to learn about running lab based user research.
First, our research team spent a day in the GDS user research lab, observing how they run their user research sessions. We then shadowed Jake from the Verify team to see their analysis and debriefing process. It was an interesting opportunity to see the processes and methods used by an established research team and we learned a lot that could help the development of our own team.
There were three specific areas that interested our research team and will influence some of the things we’re looking at now.
The User Research lab
GDS’s user research lab has a video feed that links to a large bank of TV screens (no one way mirror!) in a large separate viewing room. This setup shows a live viewing of the participant and their computer screen. The recording also switches between several views to give observers and note-takers a well-rounded view of the participant.
The large room meant that they could accommodate many viewers and stakeholders to each session. The feeds are also recorded for further analysis if needed. For more info, read their blog post on their user research lab.
At Parliament, we’re in the early stages of setting up a research lab. We’ve claimed a room and are in the process of getting software and hardware that’ll let us run lab-based user research sessions. After seeing the success of GDS’s lab and learning about what they would do differently in a future lab, it’ll help us to make good decisions when building our lab and avoid potential pitfalls.
Involving stakeholders
An impressive part of the research process we saw at GDS was the high level of stakeholder involvement throughout the research process. They regularly invite stakeholders to come and be the note-taker for each session, capturing observations on sticky notes. A helpful poster they’ve made explains the process on the govdesign tumblr.
During the analysis stage, each stakeholder was invited to come and walk the group through their observed user’s experience by explaining their sticky notes. These were then grouped with similar issues from other users for the findings. The researcher also had a transcript of each session for reference and to flesh out the stakeholder’s notes, if required.
The advantages of this high level stakeholder engagement are:
- it helps the stakeholders have a shared understanding of any issues. This is better than if they were simply informed about them afterwards by the user research team, as the stakeholders witnessed and wrote notes about any issues themselves
- the stakeholders may have an alternative and potentially deeper level of understanding about the product than the research team. This can increase the quality of the interpretation and analysis of any issues that occur
Although our research team has had some success working as embedded researchers within teams, there’s plenty of opportunity to increase the involvement of stakeholders in the research process. This is something we’ll explore more in the future.
Debriefing
Another interesting thing was the debriefing session. Rather than spending time producing a detailed report document for the team, they instead ran a low-key debrief where the researchers walked the team through the analysis boards, explaining their findings to a group that included designers, the product owner and other stakeholders.
This was then followed up immediately with a meeting, where the team decided what actions they were going to take and how they wanted to focus the upcoming research sprints. As a method of debriefing a small, well-knit team, it meant that the results were communicated as soon as possible, rather than waiting for a report to be written. Seeing this process helps our research team understand potential ways of sharing their findings to make sure that the research has impact but it's also timely.
Overall the visit was a great opportunity to see a team working at full strength with an established process and was a model that we hope to learn from as our team develops. I’d like to thank Jake, Jeba and Lorna from the GOV.UK Verify team for inviting us and for sharing their research processes.
The user research team want to speak to people who use Parliament’s committee reports. If you use the reports and are available for a short discussion, please email the user research team.