This is part one of two on the people team’s recent members' activity alpha. I'm a user researcher and I want to share the process and practices used to get the team immersed in research and understanding the users.
The process and practices are as much about research as they are about design. Especially as one of the main elements of successful and useful outcomes for any product or service is for the two to work together.
This is also why there are two parts to this story, and the design side will be covered by my ever inspiring design colleague, Victor Hwang, in part two.
What is members' activity?
After a brief discovery phase, the team moved on to alpha with the aim of exploring how users might understand the “activity” of MPs and Lords and to test different ways of displaying information about it.
It covers a wide range of things MPs and Lords do in Parliament, like voting and debating, as well as some of the things they do outside Parliament as part of their work. The scope is exceptionally wide, which has been challenging and rewarding for the team.
What we mean by alpha
It was important to distinguish from the start that moving to alpha wouldn’t mean starting to build and test solutions to validate our knowledge from the discovery phase. We didn’t want to only focus on the things we think we want to know about them.
Instead, the underlining aim for Victor and I was to keep everyone’s minds open to exploring ideas and not treat the prototypes as the solutions. So the team objective was to try different approaches to the MP pages and to explore how we can help groups like researchers, journalists, and the public to better understand what MPs and Lords are doing.
Where the team was after discovery
We were still learning about our users (who they are and what they do) due to the short discovery phase and we had limited knowledge of how people use the current site. Things like this impacted how research and design activities were planned and executed in alpha.
These complexities also meant that the team needed to get comfortable with not knowing much at this point. They had to trust us that clarity would come later.
To achieve this, the first priority for me as a researcher was to set and articulate clear intentions for the research. I also had to get the team involved and immersed in it.
Doing the research
At the beginning of alpha, I ran a workshop with the team where we split the users into high level groups based on our discovery findings:
- members of the public
- "intermediaries of information" like journalists, researchers, and so on
- internal users
This included discussing the needs of the user groups, what we currently know and don't know about each of the groups, and the considerations of recruiting participants for usability testing at the alpha stage.
Example of a user need:
I need to be able to check the facts so that I can be sure it's accurate and something I can report
Example of a hypothesis:
Research/data suggests that...journalists need to check facts on a story they are writing about MPs/Peers
So if we...try to make it easier to search certain facts in our data
We might see...them finding what they are looking for quicker and more easily
Things that informed the choice of research methods
The team still had many unanswered questions about how certain user groups currently find, and potentially use, information about MPs and Lords. One of the main aims for the alpha was to start out with the initial hypotheses based on the user needs defined during discovery.
Based on these aims and the timescale, we planned to do three rounds of research. These rounds were a combination of asking users to show us how they use the current Parliament website, talking to them about their information needs for MP/Lord activity, and testing different ideas/prototypes.
The eternal loop of research
The daunting ambiguity and fog of not knowing everything is often the hallmark of early exploratory research/design processes.
Even if things are ambiguous it doesn’t mean research has to be. On the contrary, it can help to establish routines and patterns for the team to help deal with being unsure about the rest.
For this reason, each round of alpha research followed roughly the same pattern, with the important moments outlined below.
Each round of research was kicked off with a team question session. In these sessions, a designer and I would go through the prototype/concept to be tested and collect any questions team members might have about it.
This was also the opportunity for me to go through the session structure and aims so that the team knew what to expect on the research day.
All the team members attended research observation sessions and made notes that were roughly grouped around relevant stages of the journey (on the printed prototype). The data was then analysed by the team in a session to uncover emerging insights and initial findings.
Making sense of things
After the analysis session, I refined the initial findings and insights with Victor to make sure we had considered why users do certain things in certain ways and what the core reasons and problems might be. The outcome each time was a list of actionable insights and findings that then could be prioritised by team for the next round.
Recap and prioritise
The team re-capped the user needs, initial hypotheses, and the findings from the research round. The findings and insights were then collectively prioritised by the team based on the potential user impact.
Those that were prioritised would then move on to be used as a basis for setting design challenges for the next round. The rest of the findings would be placed in a "backlog" which is a list of things that the team has learned but has not yet done design work around.
How did we get from challenges to ideas and another round of research? This will be covered by Victor in the members' activity: the design part.
Read more about the work we're doing to improve parliament.uk.