The Lean Research Sloppy Joe
Doing design research when you need to ship.
I‘ve never met a product team that doesn’t believe user research is important. Actually getting that research done is a different story.
When I first moved from a dedicated design research role to a hybrid UX role, I struggled with balancing spending time to understand user problems with working on designs that needed to get out the door. Not long after, I ran into Tomer Sharon’s work on Lean User Research. I realized that, because I was still thinking of design research as its own independent discipline, I was getting stuck in the deliverable business and burning time. By switching my focus to working with my team to identify the right problems to solve, I found an approach thats helped me make my research more actionable and nudged our team to GSD.
Earlier this year I got a chance to talk at SAP’s UX Boost Event on what I’ve learned about making research work at startups. Here are the principles that have guided me and my team along with some pointers for getting started. Forward!
User research needs to be less like a sandwich and more like a sloppy joe. Let me explain.
Part of making research work is making sure its not a big deal. When talking about the differences between explorative research and evaluative research, I describe design research as a sandwich. You kick off with field studies before you begin building and then do usability research afterwards to get feedback on what you’re making.
While this model is great for introducing design research to a team, I’ve since learned that research is never this clean and, well, it shouldn’t be. By letting the process get messier and letting your explorative and evaluative research mix into a design, you can maintain momentum while still getting out there and connecting with real humans.
Breathe. Let the process get dirty and let go of the beautiful presentations. Plus, showing off a great product will be more impressive than a process case study. I promise.
For research to work in a quickly moving team, everyone needs to smell users.
Having worked as a full time researcher, the biggest time sink can be in the creation of decks and research reports for the people that weren’t there. These decks take so much time because so much of user research is about building empathy in your team for users. Creating empathy with dead slides takes a lot of time and the emotions that the best presentations can provoke are only a shadow of what you experience in the real world. After trying to cram the time to put these decks together while also doing design work, I realized that you can short-circuit the share-out by having your team with you in the room during research sessions. While this doesn’t negate the need for analysis, it does get you and your team to solving the problem together much faster and leads your team to feel design problems much more intimately.
Powerpoint decks don’t fire off mirror neurons**. Real experiences with real people do.
User research can be fast. But there’s still a methodology.
While lean user research can get you to solving the right problem faster, it takes an understanding of the rich fields of ethnography and human and computer interaction to trully understand these complex organisms that are ourselves. The only thing worse than bad design research is mediocre design research presented persuasively. So lets walk through some principles that you can stick to when trying to do the good kind.
5 PRINCIPLES OF LEAN USER RESEARCH
Here are five guidelines that I like to share out with teams to get them started on understanding this methodology:
1. Watch more than you listen.
The intent of listening to our customers is the right one. The problem with listening to users is that, when people start talking, they usually start trying to predict their future behavior. And, well, we’re all generally horrible at this. Until you become an expert at analyzing user conversations, you’re better off asking questions that lead users to show, not tell.
A great heuristic is that you want people leaning in and doing stuff. As soon as they’re leaning back, they’re rationalizing. This is a sign that you want to get people back to completing some sort of task.
Well what if you can’t get in there and get people to actually do stuff? That’s ok. While not ideal, you can still get people to tell recent stories about the problems you want to help them solve. The great thing about stories is that they include details that are easier for our memories to recall with efficacy. They’re also usually littered with little details that you would otherwise miss and can help you find that little insight that will help make your product special.
2. Observe in Context.
Getting out of the office and watching users in their natural context is an activity thats easy to overlook when working in tech, especially when designing for desktop. While its impossible for me to tell you what weird and interesting thing you’ll learn from a user in their natural environment, I promise you that there will be something weird, interesting, and, most importantly, useful.
3. Features are our job. Look for the why.
This guideline is probably the most contentious of all.
If we made a hierarchy of good user research queries…
- In the fiery depths of hell would be theoretical future prediction questions
- At the top you would have watching people
- Next up you would have questions that lead users to tell stories about recent experiences
- And somewhere in the middle you’d have ‘what features do you want’
The reason feature questions are dangerous is because a feature is usually one person’s particular solution to a much bigger problem. If we can get our teams to back up from a feature to the bigger problem, then we can come up with more solutions that are a better matched to the goals of our teams.
When users do come up with a feature (which they will), don’t worry. Just figure out why your users think their feature ideas are important and then use this ‘why’ to develop features with your team.
4. Start by watching out for 3 things*
There are a lot of really good guides for field research that are beyond the scope of an article. The below list of three things will help you capture most of the experience breakdowns that are relevant to product design.
- Routines — What rituals do they have? What do people do repetitively?
- Interrupts — What interrupts them? What disrupts their flow?
- Transitions — Where do they transition? What are the in-between moments that connect disparate activities?
5. Watch 5–6 People Using Your Product
When it comes to understanding how we can better solve the problems we’re trying to solve, watch 5–6 people. Research shows that we can get to 80% of usability problems with this heuristic and its a great starting point. That is, as long as we do a good job defining our user and recruiting the right participants.
Those are my guidelines for getting started for making research work when you need to ship.
Agree? Disagree? Check me out, and Get at ya boi.
*This list of three things is a sub-set of a list presented by the brilliant Tomer Sharon.
**A lesson taught to me by a brilliant mentor, Michael Kronthal
