Rapid UX Research at Google
How do you conduct impactful user research in a short space of time?
As the manager of a Rapid Research team at Google, I’ve built a team around just that — delivering meaningful insights, fast. My job is to ensure our product teams get the insights they need quickly and effectively.
For my team, that means getting everything done within the space of a week.
In this article I’d like to share my experiences setting up this practice and ideas how to do it yourself!
The need for rapid research
My adventure at Google started in 2014. When I joined the Communications team, I started out on a product without a dedicated researcher. I quickly had to take inventory of the team’s projects and the questions that needed answering. There was a range of tactical and formative research that had to get done. I wondered how I might split my time between the two, juggling multiple needs and priorities at once.
I realized that with the right templates and processes in place, I could quickly get rid of the low hanging fruit through efficient usability studies and testing cycles. That’s when the idea of rapid research was born.
I developed a standard screener to use across my projects, a slide template to help me report back findings and before I knew it, I managed to streamline a lot of my processes to the point where I could turn research around in just one day.
My team is fortunate enough to have dedicated participant recruiters. Recruiters get a head start on filling studies by using a standardized screener. For the most part, I use the same screener for every study.
Over time, I was able to answer bigger questions in the space of several days, and increase the scope of my projects. In doing so, I realized that I could focus on not just the one app I was working on at the time, but use this process for apps across the entire organization.
In late 2016, I had the opportunity to formalize my role and build my own dedicated Rapid Research team at Google. Researchers embedded in product teams or teams without dedicated researchers come to us with specific questions that need answering. My team then acts as an internal consultancy, supporting product teams in answering questions we feel are suitable for a rapid approach.
Let’s talk about the nitty gritty of how we make this happen!
The rapid research timeline
Our rapid research team works in weekly cycles, kicking off a new project every Friday, and going through an entire research and analysis process in the space of one week.
Friday — What do we want to learn?
Friday is kick-off day. Partners and researchers are expected to come with a clearly defined question in mind. At the very least, we need a solid research question and the start of the required assets (designs, mockups, prototypes, sketches).
Monday — Pilot
On Mondays we’ll pilot our proposed study, often with Google employees, to make ensure we’re setting ourselves up for success. This is an opportunity to tweak the discussion guide, prototype and other elements of the test before we jump into the next 1–2 days of research sessions.
Tuesday/Wednesday — Conducting the research
We’ll spend 1–2 days in the lab or the field actually conducting research sessions. In between sessions, we’ll start to pull out themes from our data and identify relevant supporting material from recordings to feed into the final presentation.
We encourage our stakeholders to observe the studies as much as they can, whether in the office or over Google Hangouts. We’ll do debriefs after each session to ensure we’re all on the same page, which is a big part of how we can move so quickly.
Thursday — Prepping the findings
This is the day when the final presentation comes together. As a team we’ll conduct a slide review prior to the final report, getting everyone on the team together to review each others’ slides. It’s an opportunity to get feedback and raise any previous work that may be relevant to the project.
Friday — Read-out day
It’s time to present our findings!
For lab studies, we’ll prepare slide summaries with supporting quotes, short video clips or gifs. Each presentation includes background on the method, participant profiles and a refresher on the research question. We’ll often include a tl;dr in there to make sure the team can quickly pull out the key findings.
People who had the chance to observe some of the sessions will often have a good idea of what the results might be and usually come prepared with some questions to ask too.
Intercept studies are often shorter and more lightweight. We often feed the results from these studies back to the team earlier in the week with a quick one-pager so they can be off and running with the results before Friday.
Practical tips for conducting rapid research
One of the ways that my team is able to move so fast is by setting ourselves up for synthesis throughout the project. We do this by automatically time-stamping our notes:
- The team uses a dedicated Google sheet with a custom time-stamping script built-in, that automatically adds a corresponding timestamp to each note, making it easy to pull out quotes from video files when we need them. Here’s some information on setting up one of these yourself!
- Pear Notes is another option for adding timestamps to your notes with built in recording capabilities. For time-stamping notes in recordings, you can also use Usertesting.com or Validately
- Another option for note-taking if you don’t have the luxury of taking notes as you go is a transcription after the fact. Descript makes it fast and affordable to transcribe audio files and identify relevant quotes
Synthesis on the go
Sometimes we start coding themes as early as day 1. The team is constantly working on the read-out throughout the project. We make use of down-time between sessions to start pulling out patterns, quotes, and editing video! We use Camtasia and Screenflow for fast video editing.
We always have two researchers assigned to every project. It’s no secret that running a rapid study every week can be intense, so it’s nice to have someone to switch off with and take notes.
Limit your study to about 5 participants per day, alternating between moderating and note-taking with the other person on the project each day.
We use a variety of methods to help us get the insights we need:
- We’ll often do quick intercepts in the field, where rather than taking detailed notes, we’ll draw relevant insights onto paper printouts of concepts
- From time to time we’ll use laptop hugging for remotely observing participants as they perform tasks on their mobile . The participant will face their laptop away from them and then hold their phone in front of the laptop, making it really quick for us to do rapid mobile testing
- For testing concepts, we’ll sometimes run ‘speed dating’ sessions, where we’ll present different low-fidelity sketches or design concepts to participants to get quick feedback and validate and prioritize user needs. Participants are shown drawings that illustrate a perceived need, and individually rank the severity and frequency of the need. Discussion allows for diverse perspectives to emerge and provides context around any tensions, allowing the more promising concepts and needs bubble up.
What types of projects benefit from rapid research?
Rapid research isn’t suited to every method or project. Overall this method works best for tactical research, intended to test designs and assumptions, such as:
- intercept interviews
- remote or in-person usability studies
- concept testing
- light survey work
- user journey evaluations
- literature reviews
- competitive analysis
Efficiencies are everywhere you look
At its core, rapid research is about developing and iterating on the templates and processes you use to arrive at a streamlined and efficient research approach. It’s about identifying what might be slowing you down and finding methods and tools to mitigate that. Once you’re satisfied with the tools and methods you have in place, you can start to increase the scope of your research and look at answering bigger questions in less time.
Got any rapid research tips of your own? We’d love to hear them!