So your boss doesn’t believe in design research

This post is for anyone facing an uphill battle trying to convince an organization that design research is important. Know that you’re not alone: It’s common for designers working in startups and small companies to struggle to make space for research.

I recently attended an event to pair women starting out their careers as UX designers with senior mentors, run by an organization called XX + UX. The evening involved multiple short one-on-one meetings akin to platonic speed-dating. Hastily scribbled on my name tag in Sharpie was the fact that I did UX Research, the most salient among my grab-bag of design generalist skills.

Unexpectedly, most of my dozen conversations that evening focused on how to convince an organization that it’s worth carving out time for research in the fast-paced world of Agile and Lean development. While I’ve often struggled with this myself, I was surprised at how many other designers were feeling the pain of organizations that don’t believe in design research*.

*For simplicity in this post, this includes surveys, guerrilla usability testing, ethnographic research, and all other manner of developing product insights.

Speak the language of your decision-makers

Designers have empathy for their users, but often forget to apply this same approach to the decision-makers in their companies. If you’ve struggled to get buy-in on a design research process, it’s likely because your company’s decision-makers are focused on other important things like shipping product faster, keeping investors happy, and not running out of money. While good user research supports company growth, it’s up to you as the designer to make that case.

A finance team doesn’t say that they make spreadsheets for a living; they talk about their benefit to the company in terms of how much money they save. Recruiters don’t say that they write emails and make phone calls; they help build teams necessary for a company’s growth. Start to think of research as a way to give value to the company, and be ready to articulate why it’s important using words that other teams will understand.

Put another way, focus on why you do research, not the mechanics of how you’ll do it. I’ve listed below some phrases that my team has found to be useful when communicating with non-designers. The section on quantitative research may also be useful for you.

You’ll notice that many of these phrases focus on speed. Trigger warning for anyone allergic to business speak.

• Quicker time-to-value
• Move slow to move fast
• Confirming product-market fit to de-risk development
• Increase learnings from MVPs, allowing for quicker iteration. (This one’s especially useful if your team follows a lean methodology.)

Learn what your company values, and do your best to frame your research in terms that are palatable to decision-makers.

Make some of your research quantitative

Credit to Abi Kelly for compiling the list of design metrics.

Many things that design touches can’t be easily measured. However, if you make a number of changes to your product, and see no discernible change in any metrics, then you should do some soul-searching about whether these changes were actually that important. Over time, you should be able to point to certain metrics and take credit for improvements.

While there’s no single number that captures what design does, there are a number of options that align with improving the experience for your users. Some ideas include:

• Net Promoter Score (NPS)
• Customer Satisfaction Score (CSAT)
• Customer Effort Score (CES)
• How long it takes users to complete a certain task

Pick metrics you care about, and become involved in tracking them. Remember that metrics are a form of research.

It’s not selling out to care about numbers and the bottom line. Good designers are systems-thinkers, and should embrace the ways that design influences the broader product ecosystem. If your impact is great enough, there will be numeric indicators you can point to as outcomes of a well-executed design process.

Redefine speed

You win a race at the finish line, not the starting block.

Moving quickly and breaking things is all the rage these days. Regardless of how you personally feel about this approach, if your boss believes that speed is a team’s #1 priority, it’s unlikely that you’ll be able to convince her otherwise. You may have more luck heartily agreeing that speed is important, and focusing instead on how to define speed. Here’s how a sample conversation might go:

Manager: We don’t have time for research right now. We need to ship feature X ASAP, and can iterate after shipping an MVP. Can you start sketching some wireframes?

Designer: It sounds like we’re on the same page about wanting to ship feature X as quickly as possible. I know you want us to start sketching some solutions right now, but a [sanity check, quick validation, etc.] will help us know we’re heading in the right direction. Speed isn’t just about how quickly you jump of the starting block, it’s about how quickly we get across the finish line. And we’ll get there much faster if we can run in a straight line instead of going in circles.

Use a metaphor

Credit to Jen Ren for this concept.

Imagine you’re a doctor, and a patient comes to see you with a headache. What treatment would you give that patient to fix the headache?

I’m no medical expert, but I think it’s fair to say that a reasonable approach would be:

1. Patient presents with symptom: headache
2. Doctor does an examination: visual, temperature, asks questions, etc.
3. Doctor makes a diagnosis: object in head
4. Doctor prescribes a treatment: remove the object.

Jumping straight from a symptom (headache) to a treatment is absurd. While it would be possible for a doctor to prescribe painkillers to everyone with a headache, overall it would be an inefficient and wasteful way to practice medicine.

But that approach is no different than when time someone asks you to jump straight from a symptom — “Traffic to this page is down!” — to a treatment — “Add a button to fix it.” Without doing an investigation into why said metric is down, there’s no reasonable way to know what the right fix is. Sometimes you’ll get lucky and guess the right solution, but in the long run the team vastly increases its success rate by being able to diagnose a problem before building a treatment.

Proceed until apprehended

You might have to do successful research before you’ll get permission to do research. Wait, what? This sounds like a chicken and egg situation: Which came first, the research or the researcher?

Here’s the trick: start with an intern. In my experience, there’s a lot less scrutiny over what an intern does with his time compared with a full-time employee. It’s easier to sneak research into the process when that research is being spearheaded by an intern.

Hire a smart intern, then set him up for success. Assign him to strategically important projects in dire need of research support, and develop a week-by-week plan of attack. Partner with the developers and PMs working on your intern’s project to make sure design is adding value, and document how the work your intern does leads to a better outcome.

When an in-house team witnesses the value of design research firsthand, it can convert them into believers. Having other teams ask for design research is a powerful way to convey the importance of design research to your company’s decision-makers.

Don’t call it research

In direct contradiction to everything else I’ll write in this post, invoke the word ‘research’ very sparingly when talking about what you do with non-designers. I’ve gotten feedback that “research just sounds slow,” and have found that it can be helpful to substitute words that sound more action-oriented:

• Sanity check
• Insights
• Testing
• Validation
• Scalable feedback loop
• Root cause analysis (this one goes over well with engineers)

Use your instincts here. If you feel like the decision-makers at your company value research, embrace the term. But if you sense a pushback to the idea of research, give these other options a try.

Any research is better than no research

The metrics for what makes a “good” design process has historically been defined by agencies. Though a design process is intangible, agencies have found a way to package up their unique take on design and sell it as their product. This makes sense; if I’m a client looking to have a logo designed, I’m not buying the logo itself, because that hasn’t been designed yet. I’m buying into the process I expect to lead to a good logo.

I’ve seen too many in-house designers struggling to follow “good” design practices within organizations where it’s just not possible. If this is you, don’t beat yourself up. Those designers have:

• A dedicated project team focused on this one project
• A clear design brief with all stakeholders defined and bought in prior to kickoff
• A timeline with dedicated weeks for research

If you’re like any of the in-house designers I’ve met, any one of these items would be a luxury. All three is unheard of. So stop comparing yourself to designers working in agencies, and do the best with what you’ve got.

Design research isn’t all or nothing. Getting feedback on mocks from a few of your friends is better than not getting any feedback at all. Getting on a call with one customer is better than not calling any. Find ways to work research into your company’s process one bit at a time, and be persistent.

You’ve got this!