We're working hard on Government as a Platform to make sure user researchers are doing the right job. We've had some problems figuring out what that job is at times.
So we've developed eight principles for how to be a user researcher on Government as a Platform.
1. Start with your team's needs
Everyone knows we start with user needs. Except we don't. We start with the needs of our team.
When we don't do this our research isn't useful to our team and they ignore it. There's nothing more pointless than doing research that no one listens to.
As soon as we start meeting the needs of our team they trust that we're here to make their lives easier. They listen to us. Then we switch to a relentless focus on user needs.
2. Use research questions
We do research in an agile environment. But the sprint cycle isn’t quite right for planning research. We need a way to plan our research and track our progress over time. We use research questions for this.
The first thing we do on any project is sit down with the whole team. We ask them what they want to know from the research. They come up with dozens of questions they want answers to. We organise these into a set of research questions that everyone agrees are important.
We use these questions to plan the research we need to do. Then we answer the questions.
3. Talk to users all the time
It is critical to always be doing research.
Without constant research we can't get our team the exposure hours they need with users. Or we turn up at research playbacks with nothing to show. Or we just don't get a proper feel for the problems our users have.
We all talk to users every single week. We do a mixture of telephone interviews, lab sessions, guerilla tests and site visits to make this easy.
4. Involve the whole team
The job of our user researchers is not to do user research but to help our teams understand what matters to users. When this happens the team does user-centred design without thinking about it.
Our whole team generates the research questions. Developers take notes in the lab. A non-researcher comes on every site visit. Everyone takes part in debriefs and playbacks. We ask the product team what they would change about the research to make it better.
It's easy to stop doing this. People are grumpy. Co-ordinating everyone takes work. You can do things faster yourself. But it's the single most important thing on this list.
5. Present one list of problems
Our research process generates a list of the top 10 problems for the team to work on. The team prioritises this list together every two weeks. Everything else we find goes into a research backlog, which we ignore.
This sounds radical and reductive but it means our team always knows what to work on. The beauty of agile is you don't have to address everything at once. The team solves the biggest problems and we come back and do it again in two weeks.
Our team are fantastic at solving problems. Our job is to make sure they are working on the ones that matter most to our users.
6. Maintain a research wall
The research wall is the centrepiece of our work. We use it to show four parts of our research that are critical to the team.
We show the interface and highlight the issues coming out of research in context. Our designers and developers constantly refer to the wall while working. It's powerful.
We show the list of the top 10 problems. Our product managers use this list to plan and track their ideas for solutions. Problems only leave the list if they disappear in the next round of research.
We show the research questions and our progress against them. Our researchers use this to plan research and decide which questions to ask when we meet users.
We show things that were problems that our team has now solved. This makes us feel good. It's important to feel good.
You might think our walls are decoration. You’d be wrong.
7. Document the research
OK. Now we get to the grunt work. Just because we work fast doesn't mean we don't document our work.
We document our research activities: what was it, who did it, when and where did it happen. We include notes, recordings and any materials.
We document our analysis sessions: photos of post-it groupings, frequency counts of important issues and lists of findings.
We document our research playbacks: the top 10 problems, the research backlog and any problems marked as solved this cycle.
And we document the ever-changing answers to the research questions in one big Google Doc that we add to over time.
I'm not going into all the reasons that documentation matters. It matters. And it doesn't take long if it's a habit, so we make it a habit.
8. Manage your contacts
More grunt work. Our users are service teams. We have to find and recruit them ourselves. This is a staggering amount of contact admin.
Let's look at GOV.UK Notify. We've spoken to more than 60 service teams in the last four months. We take each one from first contact, to telephone interview, to lab session, to site visit, to beta partner. Each stage involves scheduling activities. The people we talk to change. The services themselves change.
We need to be great at email, phone calls, calendars, room bookings and travel arrangements. We use Trello to manage our contacts and maintain a research pipeline. This is the foundation of all our work.
All eight principles are critical
Every user researcher on Government as a Platform does all eight of these things. Even the less glamorous ones. Especially the less glamorous ones.
There are lightweight ways to do all these things. We encourage these. But I want to be clear. We would rather slow the pace of the research on a project than stop doing a single one of these things. Because when we do these things the whole team has a laser focus on meeting the needs of our users. Not just for a sprint or two, but for the whole product lifecycle.
And that's what we are here to do. That's the right job.
Follow Will on Twitter and don't forget to sign up for email alerts.