Selling & Defending Research

February 23, 2020

The idea of “selling” research may raise some eyebrows, but it’s all too true. Unless you’re one of the lucky ones who work for a truly user-centric company, you’ll need to get buy-in for your project. Here’s a guide to proving research’s value and refuting resistance.

The Benefits

We’re Customer-Centric

In most organizations, we’ve achieved design having a seat at the table. As researchers and designers, it’s our job to advocate for the customer/user in the context of a company setting. If your company values customers, then encourage decision-makers to walk the walk.

With a continuous research process, you have real data at your fingertips. A strong research team will package this data into insights for product teams, enabling grounded design decisions, completing the circle of user-centric design. A research-driven design process enables teams to design and build relevant, impactful experiences for their users.

...of those organizations where design is not making an impact, 95% do little or no design research.
Richard Rutter, 3 Keys to Effective Design Teams
Design Thinking Ideo, Nielsen Norman, Stanford
Any way you draw it, research grounds decision making for teams that believe in user-centered design. Visualizations from Ideo, Nielsen Norman Group, and Stanford

Save Time & Money

Misguided product decisions cost us time, money, and team morale. With larger features, teams can spend thousands of hours on requirement gathering, information architecture, wireframes, visual design, building, and QA. Imagine that time being absolutely wasted because you didn’t validate the initial hypothesis or the usability of a critical flow. Assure your team you can meet them where they are in the product development process—bringing value in the near term.

Present your research project with your stakeholder’s language, in a way that uses their goals. Describe the ROI (return on investment—this might be their language) “Four days added to the overall project timeline is the investment. We’re investing in a solid understanding that people can use the product and accomplish their goals.”

Prevent Bias & Blindspots

Bias blocks product teams from launching groundbreaking work. Yes, you may fit part of the profile for a user, but you’re too close to the work! When you’re operating on assumptions, you’re assuming you know the user and the solution.

Work with educated guesses and validate them early and often. You are not your user, but you can find them with targeted recruiting. Reduce bias by being genuinely curious. Think of your goal as finding your own blindspots. Be a skeptic!

In a discovery process, use generative and descriptive research to avoid bias and blindspots.

  • Generative is for when you’re generating ideas and don’t have a problem to solve yet
  • Descriptive is for when you have a problem and need to describe the problem in detail
Generative or exploratory research: “What’s up with...?”
Descriptive and explanatory: “What and how?”
Erika Hall, Just Enough Research
This book is actionable research gold. Read it.

Short Case Study: DTC Dog Food

Say a founder thinks that people will buy dog food from door-to-door salespeople. They’re claiming it’s the “new DTC.” (Direct to consumer) You’re told to design and build them an app to place and manage orders.

Start by asking questions in the discovery phase. Someone’s given you a problem you need to describe, calling for descriptive research.

End Customer: Dog Owners

  • Have you talked to any dog owners who aren’t affiliated with the company? If no, please do. If yes, what are their pain points as a dog owner? Specifically, what are their pain points in feeding their dog?
  • Where do they currently buy dog food?
  • What are their dietary concerns for their dog?
  • When do they feed their dog?
  • How do they feed? (Do they have any specific commands or rituals?)
  • What’s their current purchase price point? (Do not ask what they’d pay, this is asking them to predict future behavior.)
  • Where do they live?
  • What does their average weekday look like?
  • Do they receive large shipments at home regularly?
  • Do they generally pay for shipping for online purchases?

Strategic Questions for Stakeholders

  • Why do salespeople need a custom app for orders and purchasing? (There may be a valid reason, even if you have doubts, try to minimize your bias.)
  • Is there an existing third-party software that has enough functionality for us to prove the hypothesis that people will buy from door-to-door salespeople? What are they or their competition currently using?
  • What competition is currently in the space? (Remember, some people think no competition is good. That’s not necessarily the case. Unless we’re dealing with truly world-changing tech, you may have an idea that just doesn’t work. Still, keep your hunches in check until it’s time to provide findings.)

That’s a lot of questions that need to be answered before you sketch one interface. Above, we’ve been given a problem, but need to dig in to better understand it. Make sure to run generative/descriptive research upfront to be sure you don’t waste your time.

A little further along in the process, evaluative research should happen in some form. We leverage evaluative methods when we understand the problem, designed a hypothesis that might solve it, and need to evaluate the solution. There are many different methods of evaluative research, usability testing is one of the most common.

For the DTC dog food problem, let’s say we conducted the descriptive research above. Let’s say we presented our findings to decision-makers and they made the call to build the pilot app. We’d map the salesperson’s journey from planning, taking an order at the door, and what happens next. From there, we’d usability test with actual salespeople in a real-life selling situation.

Customer Journey Map Sara Vienna
Mapping the customer’s journey helps us understand when and where to test.

This way, we’re testing if salespeople can actually accomplish their tasks with the app. If they can, great, then we’ve validated our hypothesis. (Don’t celebrate too fast, the work is still just beginning.) If they can’t, we will make edits and re-test, ensuring the app allows sales to be captured and processed.

The need for user research in simple terms—it’s hard to argue with testing a product that contributes to the bottom line of the business.
Triple Bottom Line
The triple bottom line of business includes people.

The Benefits, Summarized

  1. Customer-centric companies should walk the walk and include users into the product development process, empowering cross-functional teams with data for decision-making.
  2. User research will save time & money, preventing an off-target product and potentially months of rework.
  3. Prevent bias & blindspots by stepping outside of an internal employee mindset—aka don’t drink the Kool-aid. Depersonalize design decisions by collecting objective user feedback. Remember, user research is one input, with team expertise, tech constraints, and market drivers being others.

Facing Conflict with the E-Word

You still may run into push back against user research. Practice empathy. Try to understand what’s really driving stakeholder concerns. Actively listen and use their language whenever you can. Have a conversation with the concerned party and try to keep neutral while you collect this data. 

  • What are they afraid of? 
  • How can you address and allay their concerns?
  • What are their business goals? 
  • How does research impact goals—positively and negatively? Acknowledge the negative and find a way to reposition it.

Reason: We already know our users

  1. That’s awesome! If this is true, request the documentation. You’re not a mind reader, are you? If you are a mind reader, please tell me what I’m thinking right now! Seriously, shared understanding across product teams is critical. 
  2. It’s likely that when you review this information, questions will arise, so suggest iteratively understanding your users. Maybe personas need an update because you’re breaking into a new, unexpected market segment. Personas might be demographic data-heavy without insights into pain points and drivers, and a survey or interviews would help round them. Maybe your team hasn’t had a chance to empathy map.
  3. There’s always something to uncover, but documenting users may not be your focus if teams feel informed enough to design a hypothesis to the user’s problems. Keep moving through the process because there will be a hole in product design that research can prevent. For example, it might be more appropriate to focus on the solution stage and task success in usability.
  4. When insights (read: “we know our users”) and enhancements make it to the product roadmap, and the user experience improves, everyone wins. People's use of technology does change, so we need to keep researching because the work is never “done. (Just like software.)
IBM User Research Methods
IBM design’s most-used methods aligned with goals from exploring the problem to measuring impact.

Reason: We don’t have time
Reason: It won’t fit into our process or it will change the scope

  1. That’s a valid concern! What is the ideal timeline? There’s a research method that can fit into the most aggressive of timelines.
  2. What phase are you in the project? What method of research might be best? Present that method in an easy to understand one idea-per-slide deck. Consider running remote research when timing is a concern because it allows you to collect more feedback in parallel and recruit faster.
  3. We don’t have time to make guesses, we need to have an educated hypothesis or a solution to user’s problems. How long might a redesign take if we’re wrong with our assumptions?
  4. It might be a little hard at first to get used to a process shift. Still, a misdirected product will certainly change scope in ways we can’t anticipate. Edit your scope first to include research whenever you can.
  5. If someone counters you with “we don’t have enough time to make it perfect” let them know this is applied research, not rigorous academic research. Testing digital products should happen where the use occurs, in-context, in the real world. If you’re in house and not constrained by scope, research should be conducted on a rolling basis.

Research methods should vary based on where you are within a project. Say you’re building a new product. You’ll need to think deeply about the problem and users, but may have a limited budget. If that's the case, focus on research methods you can collect with a small team: persona development, empathy mapping, job stories, and a card sort. Save your budget for usability and find the roadblocks to task success.

If you're working on an existing product, research can look very different. At this stage, you'll likely have some sort of workable data. If not, get that analytics install stat! Beyond analytics, you might use a diary study for qualitative feedback in context. You might conduct a heuristic analysis for a baseline. (Get in touch with me and I'll send you a template for heuristic analysis.)

Mixed Methods can differ at stages in the process
A new product vs. existing product may call for different methods.

Reason: We don’t have the budget

  1. What is the ideal budget?
  2. Pull together scrappy plans that can align with where you are in the process, now. In the beginning of a project, or in the generative phase, do and document online research about your target user and competition. If in the evaluative or iterative phase, show how usability can run with only 5 target users. With remote research, people can participate from home, so it’s generally more budget-friendly because incentive gifts cost less than in person studies.
  3. Instead of one long, expensive upfront research project, disperse research throughout the process. Let your team know that research is never done, so it makes the most sense to run research alongside product development to keep teams working toward the ideal user-centered solution.

Reason: The Founder/CEO tells us what to do and we just execute

  1. Most reasonable leaders can’t ignore data. Present that data and let them make the decision. You may not always agree with the decisions of decision-makers, but if you keep it professional you’ve done your best.
  2. Sometimes we’re wrong. The sooner we accept that we and our ideas are not perfect, the sooner we can objectively see a problem and design a solution. Try to help all members of the team see that, even leadership.
  3. In the future, it’s best to avoid organizations that are dictatorships—but sometimes you don’t know you’re dealing with that until you’re in the thick of it!

Reason: We can launch and learn

  1. We can and should! The things we will find are focused on function, task success, and bugginess. We should absolutely monitor these.
  2. We should also invest in exploring our assumptions so we can be closer to sure we’re building the right thing. This goes directly back to the goal of *not* wasting time and money.

Keep up the good, peaceful fight

Remember, you’re a designer or researcher in a company that actively recruited and hired you. (Even if you’re consulting.) You’re here for a reason. Remember the bigger picture. You’re the subject matter expert.

Don’t think you have to play some psychological jiu-jitsu on your decision maker. Present the benefits, and refute any arguments. Stay calm, don’t speak down to people who know less about research than you, and don’t make it personal. If a decision maker still opts out, you’ve done your best.

It’s about winning for the user. If you don’t win this one, learn from what didn’t work and go get them next time.


Do you have a team in need of design leadership?

Let’s chat.

get in touch