Skip to main content

Members' activity alpha: the research part

A research session with post-its and notes on an MP's page

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

A pyramid showing the internal users, intermediaries, and the public
The user groups of 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 user research loop incorporating questions, objectives, research, analysis and iteration
The user research loop

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.

Team questions

MP page with feedback on what users will want to know about each section

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.

Team involvement

Some of the team during the research session
Some of the team during the research session

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

Categories of members' activity
Categories of members' activity

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

Sharing and comments

Share this page