The small change that got our whole company interested in usability testing
Six months ago, it was a struggle to get internal buy-in to do usability testing. People thought research took too long and that it stalled the development process. Product Design would go into a room and run sessions for a full day. Then we would have a long meeting to do a thorough dive into the findings. We would catalog and code every insight to prep for next steps and future projects. Good for the long term, but not helpful to a team who is building right now. Development teams were in the dark for a week, sometimes longer.
Fast-forward six months and we’re talking to more users than ever before — way, way more. Not only that, but people across all teams ask when we’re talking to users next — including directors and our founders.
One thing, in particular, had a big impact: We changed the way we communicated our findings.
We set out on a mission to change the way teams thought about usability testing: Testing is how we grow.
We wanted testing to be a normal part of how we worked, not something that put work on hold. Product Design wanted to create a culture where anyone in the company wanted to test questions, concepts, and features. It’s through challenging ideas that we get to better ideas. We wanted to create a culture where the entire team used learnings to inform next steps. What you learn is only as good as how you apply it, and, at the time, only Product Design was using research findings.
So, we changed our process to make insights visible to everyone.
We made it faster. Now we share what we learn after every single session. After the participant leaves, we stay in the room to do a quick debrief. One person facilitates, asking the others what stood out to them as it related to specific sections of the test and the goals of the research. As we talk, one person writes down the key notes on sticky notes. Because the test just happened, everything is fresh in our memories, and the discussion flows easily. In fifteen minutes or less, we have a summary of what we saw, and it directly relates to the goal we wanted to test.
We made it simpler. Every insight that we write during the debrief fits on one sticky note. Because each insight ties back directly to the goal of the test, we can easily arrange all sessions’ notes side by side. We arrange them on a whiteboard or other open space in a format that’s easy to scan. Whether or not you were in the session, you only need to look at one whiteboard to get a quick summary throughout the day.
We made it more accessible. We put the sticky notes on a whiteboard in an open area where anyone can look at it. Channel-wide Slack notifications, at the start of every day, alert people to what’s happening and where to find updates. They’re encouraged to reference the board throughout the day and afterwards when we’re planning next steps. We also use the board to do “lunch and learn” presentations for those who want to go more in-depth.
What happened as a result?
Research is more integrated into our process, both in discovery and development. Instead of something that stalls the process, testing became a tool that improves how we generate and validate ideas, both during ideation and after we’ve built something. The team uses the summary board as a reference and meeting place for discussions about next steps. People are more likely to use the information when they have easy access to it. Sometimes we even use the board during the brainstorm sessions that follow testing.
Research is more collaborative. After people experience the speed and simplicity of learning from previous tests, they’re more likely to get involved in future tests. The turnover from idea to test to learn is shorter than before, and every person can see how they might contribute — whether for building a prototype or taking notes in tests. Additionally, the debrief following tests is a small time commitment, and the discussion format means everyone can do it. No prior usability testing experience is required.
The whole team is invested, not just interested, in research. People who attend sessions see their contribution to the research and take their observations back to their teams. People who build prototypes get feedback quickly and see their work get better. When your peers gain knowledge, you’re more likely to want that knowledge too. Notetakers have come from all teams — and they volunteered!
We’re not the only ones talking about research anymore. People ask when and what we’re going to test. Then they ask again after to find out what happened, and we can easily walk them through the result summary on the board. The placement of the board between a meeting room and the common area means people regularly walk past it and often stop to look it over. Research is visibly part of the workflow and the environment at IDAGIO.
Conclusion
When we learn, we want to learn more — learning fuels more learning. Because research learnings are accessible to everyone at IDAGIO, everyone at IDAGIO is learning together.
Stay tuned for more updates in the coming weeks. We plan to share the different formats we used to communicate findings with our team so that you can use them, too.
