The Curse of the Convert: Designing Better Design Research

You know the person, the one who is so excited about their thing, and they want to tell you ALL ABOUT IT. And they want you to start doing it too. It will solve all your problems. Just try their thing, you’ll see. Crossfit, HIIT, capsule wardrobes, intermittent fasting, paleo, meditation, Android, iPhone — they all have their evangelists. You have probably met them, you may be one right now.

When you talk to designers and researchers, you often hear about how much they like their careers. That what they are doing really matters. We also tend to get a bit evangelical about the role of research of all stages in designing great products and experiences.

And every convert needs a conversion story. This is mine.

Beyond good methodology

Early on in my career, I focused on the Backwards Research Process and quality assurance gate checks. I knew if I understood my client’s objectives, translated that into a survey or discussion guide, and made sure that was executed with proper data collection and analysis approaches, then I could stand up in front of them with confidence and make recommendations. I took very seriously the task of bringing “the voice of the customer” to decision makers, and felt my work could help make the world a better place. (It’s true.)

And then I realized it wasn’t enough for the research to be done correctly and that I had clarified something that was previously ambiguous. My clients needed to be able to do something with this clearer understanding. And it was my responsibility to make sure they could.

Checking off my clients’ research objectives wasn’t enough. I needed to show them contextual understanding of the space I was researching on their behalf. My recommendations needed to be actionable. The deliverables needed to be short, punchy , and engaging for non-researchers.

Sexy research sells

Like many design & UX researchers, I prided myself on substance. The problem was that sexy research always won the day.

Clients loved seeing a big, head-turning percentage point or a compelling video in my presentations. I learned that anything that was simple, dramatic, and told a story in an instant is what got a client excited — they didn’t care about rigor. I tried to slap this type of thing into my presentations, but it never felt authentic.

Even worse, it almost seemed some didn’t actually care about listening to the customer’s problems or needs. I remember sitting in meetings with smart decision-makers and the conversation would often turn to human-centered design. But when we started to discuss plans to actually validate and test an idea with end users (e.g., showing preliminary prototypes), the step was often pushed back to an undefined date, or cut from the budget completely. There was a lot of lip service at every level.

After countless meetings where this pattern kept repeating itself, I started to feel frustrated that research wasn’t getting traction. (This isn’t an uncommon complaint. There are countless articles about ‘how to get stakeholder buy-in.’)

Reframing the issue

When users have a problem with a product feature, we don’t say it’s the user’s fault. We say it’s failure in the product. And we redesign the feature or prompt to make it easier for users to accomplish their goals.

And then it hit me. We could apply this same line of thinking to our own research work. Otherwise we are falling into the trap of the new convert, and a lot of people are tuning us out.

Researchers need to stop talking about empathy and having a deeper understanding of the product’s user. It’s a story we tell ourselves, but that isn’t the value we bring. That is a tool, a step towards our actual goal of helping the design & product teams make better decisions.

Instead of feeling resentful after those meetings, we should take a look at how to fix our own “product” so that our own end users (designers, developers, product) could accomplish their goals of better and faster decisions. We’d been so focused on empathy for the users of the things we were designing, we lost sight of empathy for the teams we were working with.

Some tough challenges we posed for ourselves here at Normative:

Flip roles for onboarding: Instead of asking the product & design team to onboard us, why couldn’t we onboard them?

Redefining the objective: What is the “job to be done” with this research? For example, does the research need to:

• give the team or stakeholders confidence to make a crucial decision about next steps?
• help align the project team?
• serve as a way to excite senior stakeholders?
• result in marketing collateral to sway potential investors or partners?
• identify ways to improve the product itself?

Identifying risk: What will happen if the team and the organization doesn’t get the research? What risks will they expose themselves to (i.e., monetary risks, public relations risks, user adoption risks, technical risks, etc.)?

Show prototypes and co-create: Is there something we can show (or co-create with) the client early on so that the artifacts will be more valuable and we reduce time-costly rework? How can research be small, nimble and iterative?

Avoiding the paradox of choice: How do we provide the right options at the right time? Surface the information to the people who need it when they need it? How do we reduce cognitive overload and make people confident that they have the information needed to make the best decisions they can at this moment?

Redesigning the research customer journey

My role at Normative is to enable our teams to embed understanding and empathy into every product we touch, making sure the best ideas move forward. If the team is uncomfortable with reaching out to users early, then we can distill insight and context from online forums, what the users prioritize when they talk about the topic on social media, marketing collateral and academic literature. We can engage with friendly SMEs to help us navigate unfamiliar waters, or recruit expert users for ongoing support.

Many of our tactics won’t be new, many researchers will already have seen them in listicles (e.g. https://www.nngroup.com/articles/collaborating-stakeholders/) or at conferences, but our new framework allows us to select them strategically to deliver what the team needs instead of centering our desires about what we want to deliver.