Scaling Research: Using Rapid Research to level-up your teams
This is a true tale about standing up a research program at Lyft that gets designers, engineers, product, and managers of all kinds to collaborate and ultimately lead (you read that right, lead) research. Call it what you will- Self-serve. Speed Dating. Rapid Research. Round Robins. Lightning research. DIY. This program has increased access to customer feedback for teams who don’t have a dedicated researcher or whose project questions are small in scale but high in impact.
Building this kind of program was a wonderful way to scale myself across a wide range of projects and invest in my cross functional team that paid off in dividends.
Disclaimer: This program is meant for a specific style of feedback and was developed and run by people who were trained in research.
TL;DR: 1. Get the word out. Creatively. 2. Empower teams & set clear roles 3. Select the *right* projects 4. Create templates 5. Train your people 6. Recruit 7. Lights, Camera, Gong (Data gathering day!) 8. Sharing the learnings
This Program is good for:
- Leveling up cross functional partners, especially designers
- Evangelizing what research is and how it can be useful in making
- Product decisions
- Demonstrating that research is a team sport
- Putting engineers (or other unfamiliar faces) in the driver’s seat to engage face-to-face with your customers
Away we go…
1. Get the word out
First, I had to drum up interest — I spoke at our NY office All Hands, pitched at engineering huddles, and reminded managers to bring up the opportunity to test ideas at their respective meetings. Oh, and I bought a gong with a marvelous tenor! I’d kick off my pitches by sounding the gong. It really got people’s attention and became the sound of Rapid Research.
2. Empower teams & set clear roles from the start
Then I’d meet with all interested parties. The meeting bit was a huge unlock in the early days as I got to meet a bunch of folks I wouldn’t have come into contact with otherwise and hear out what they wanted to learn, hypotheses they had etc..
Each project would “kick off” in person with a review and co-creation session of the test plan and discussion guide during a high energy team working session. I made it mandatory for everyone to have at least one other teammate participate so the load was shared and there was someone available for backups, dry runs, prototype feedback etc..
I asked teams to verbally commit to this process, delineating responsibilities:
3. Select the right projects
Six (6) projects per Rapid Research event is the sweet spot (7 if you think teams might drop out). As I refined the types of projects that would be good for the Speed Dating program I landed on four main categories:
- User Need Assessment: What are users’ overall or step-by-step needs? Aims to understand current behaviors and attitudes around a general topic. Looks like: high level foundational interviews.
- Design Comparison: Helps make decisions on design direction: Which design variant should we pursue? Helps provide insight into impact of proposed changes: How does this treatment version compare to our existing/control version?
- Usability: Can users successfully use an existing or prototyped feature? Helps test complex or new user flows: Are users able to successfully complete X tasks? Are users able to comprehend these instructions/copy.
- Product Feedback: Do users like my concepts? Why or why not? Helps get feedback on launched products: How do riders currently use our products? What are the pain points or ‘bright spots’ with our existing experience? Get initial reactions on new products: How does concept X resonate with riders? What initial questions or concerns do riders have?
4. Create templates
A whole article could be written about setting your teammates up for success via templates. Here’s a peek into our “Control Center” aka the organization of templatized decks and documents at team’s disposal while participating in our program.
5. Train your people
I created a “Moderate Like a Boss” training for all new facilitators. It’s a 60 minute live masterclass in gif-form, which gives useful tips on interviewing customers (think: non-leading questions, reading body language, managing bias, avoiding jargon). It ends with attendees putting their learnings into practice by conducting a mini-interview. Other teams and researchers have leveraged this training as well.
We have a company-wide internal badging system so to build the hype I created a badge for the training. Over 95 people have been awarded the badge from Content Designers to Technical Program Managers to Directors of Engineering. Turns out conducting interviews is a compelling skillset across disciplines.
6. Recruit
Recruit! I would handle the recruit. I’d use any of the online platforms for recruiting and would always ask recruits if I could contact them again- this enabled me to make a Rapid Research Participant Panel to draw from every few months instead of needing to start from scratch.
Oh and repeat after me- gen pop. aka general population! After a few rounds of specialty recruits, I switched to recruiting from the general rider and driver populations (not juggling the recruit across 2 riders who’ve recently gone to an airport, + 3 that sent a text to their driver, 2 that have never texted, 4 that have early canceled…true story.)
7. Lights, camera, gong (aka data gathering)
Dry Run the day before! This is a big one. The team should go through their test with someone from the office being the “rider” or “driver” as if it’s real. Get a sense of pace — are there too many questions and the discussion guide needs a trim? Did one section take a lot longer or shorter than anticipated? That extra teammate?
Day Of aka Show Time! With a clang of the gong we’re off to the races. Each team has roughly 20 minutes with each participant and 5 minutes of break time for participants to clear their heads and teams to huddle or take a bio break.
Each transition is marked by a sounding of the gong. This part is optional but I found it super fun.
After the participants leave we take a collective exhale, and huddle together to share some early observations about how the program worked and what teammates noticed from their sessions. This is the best part because you have teams who don’t always share this level of detail with one another come together — often teams will make connections between what they observed and how certain riders or drivers approached their area of focus.
8. Share the learnings
Share Out Lunch and Learn: This is the final milestone in the program and a fun one. We schedule an hour during lunch for teams to share their doc or deck of findings with the other teams. We invite a bunch of people to this gathering- other teammates working on similar or adjacent projects, relevant xfn partners, research groupies who want to hear the latest from our users.
And most excitingly, this program’s success has seeded increased investment in this type of work. We’ve already hired one dedicated rapid researcher on the driver side and will be looking for more rapid researchers to join our team in the second half of this year.
Important Note: Research is a team sport and this program is no exception. Thank you to the myriad of research and design partners who’ve helped develop and evolve this program over the years: Leah Rader, Lisa Ratner, Cait Osbahr, Adrian Phillips, Rebecca Blum, Kate Brena, Jessica Talbert, Cornelia Mrose, and Varna Vasudevan.
And special thank you to Hannah Chen for the ace illustrations throughout this article and David Hildebrand for the guidance throughout.
