“User researcher’s fallacy: My job is to learn about users. Truth: “My job is to help my organization learn about users.”
Caroline Jarrett
I like this quote from Caroline Jarrett very much because it sums up our idea of UX research in our organization. I am part of a team of 5 researchers at the Education Executive Agency of the Dutch Ministry of Education, Culture and Science. Our organization consists of almost 2000 public servants and over 60 development teams. This scale forces us to get creative as user researchers. In this article, I would like to describe how we plan our research to have the most impact.
Lessons from last year
- We have learned most of our lessons from trial and error. These are some of the problems that we faced last year:
- Usability testing was unpredictable and did not always work well within agile working. We wanted to work from a customer perspective, so we put a waterfall process before a sprint, which also did not work. People from development teams got frustrated with us because we ‘slowed down’ their process.
- Some teams had a dedicated user researcher, but other teams did not even get the occasional help. We had to think about scaling our research activities to reach all 60 development teams.
- Collected insights did not make it to other teams and projects working for the same users. There was little transfer or exchange between researchers and teams. The fact that we did not have one place to store all our insights did not help.
- Because of that we easily forgot what we had found out. People left the team, and insights disappeared into obscure maps or reports that no one ever read again, meaning we had to repeat the work.
- Decisions were not made on the basis of insights but on gut feeling. Technical conditions and business requirements ‘won’ over user needs.
With these lessons in mind, we critically looked at our role. As user researchers, we play a role in all three phases of the human-centred design process. For 2019 we have worked out our approach for each phase and how we want to work with other teams.
The Inspiration phase
Centralized research
We’re no longer doing discovery research in a development team. Instead, user researchers work on the centralized insights archive. We conduct extensive research into our user groups and choose topics that are relevant to them. We advise multiple teams about these topics and user groups. Our hope is that by turning this around we will stop getting dictated to by business requirements and instead let users control the research agenda.
Our insights no longer get lost
Since last summer we have worked with Sticktail, a (Dutch) tool for a centralized research archive based on storytelling, or sticky stories as they are called. Everyone at our organization can get an account and look through all the insights and documentation themselves. They can search for insights by user group, topic or application. Insights from multiple studies are combined and strengthen each other, and every team has the same user knowledge to fall back on. Consequently, our insights no longer get lost. As some of our researchers find it hard to write accessible, good-to-read insights, we are now focusing on our writing skills with the help of one of our content design colleagues.
Using generative research methods
When we conduct discovery research we co-create with our users as much as we can by using generative research methods, for example, by collaborating with schools or motivating students to engage with their peers in our studies. We visit our users in their environment, even if that means that we have to travel far. (Our office is in Groningen, the northernmost city in the Netherlands, so this really means something!).
The Ideation phase
Tell a good story
We are the conscience of our users and do whatever we can to lobby for them in our organization. To achieve this, we tell stories about them. We actively look for stages for these stories in all parts of our organization. As user researchers, together with the other UX disciplines, we take the lead in service design within the organization.
Assist teams in working with users
User researchers know different methods and tools and help other teams to use them. We facilitate teams working together with users. Furthermore, we help teams to implement user insights in their projects, e.g. at the beginning of a new sprint, so they make a good start from their users’ perspective. What’s more, we assist teams in making more in-depth user research products that are specific for their service.
The Implementation phase
Last year we did a small survey and asked over 40 development teams what they wanted to see ‘from the client’. More than half of them said they wanted to know and see how users used their product and to speak to users themselves. Great!
Teams are responsible for user and accessibility testing
Teams are given the responsibility to put the user first. When they go live with a new or adapted service they have to test for usability and accessibility themselves. We coach them in test skills so they are able to do the research work on their own. We support with equipment and help them to find the right participants. And, of course, we make sure that the insights that transcend the usability study end up in our research archive.
Let’s go
While a number of things are familiar to us, other things are really new. I am very curious about what we will learn and what will and won’t work. I am also interested to find out about user research approaches from other organizations. How do you organize the user research discipline and why?
Maike Klip
Design researcher at Dienst Uitvoering Onderwijs (Dutch government) | Website
She works as lead User Researcher at DUO. With a team of five researchers, they conduct company-wide research and coach other development teams to incorporate the user into their workflow. Next to her job, she studies at Willem de Kooning Academy where she uses design research to find out which role empathy plays in the making of digital government.
