Investing in Your Success
“You are going to do research on your product - the only question is whether you do it before, or after you launch.”
This tends to resonate most immediately with folks who are familiar with the process of software development - designers, front- and back-end programmers, project managers, etc. - and anyone who’s been through even a single launch of the most run-of-the-mill website or digital product. They know, first-hand, the pain of testing after a launch, because they tend to get stuck with dealing with the aftermath of the easily-foreseeable mistakes: complaints from customers new and old, disappointing improvements (or terrifying drop-offs) in critical metrics, and the inevitable finger-pointing that follows.
It’s a horrible experience for teams, especially those who labored long and late into many of their nights to bring an experience to life. And almost everyone on the team can point backwards and identify one or more critical junctions where a different decision, or a different prioritization might have made things a little better.
There's a Better Way, that Most People Will Ignore
It’s easy to agree that there must be a better way, but it’s far more difficult to convince people of that better way when development budgets are being scoped out, and timelines set. Here are the most common objections/rationalizations I hear when proposing to include a robust UX Research plan into a digital project:
- We can follow best practices for most of this (also rhymes with “we’re going to use ABC kit for this”)
- We’ve got a smart team, we should be able to figure some of this out without testing
- We don’t have time/budget to test everything
These are all interesting and useful points, and they can help to illuminate some deeper truths about a project or a business if you use them as jumping off point for conversation, rather than a final proclamation.
"You can't stop clients from sticking a bean up their nose"
- Jared Spool
But You Can Help Get it Out
There's a certain world-weariness that experienced UX professionals have after a while, and the above quote encapsulates it nicely: though you may know better, the folks who write the checks ultimately get to make the decisions.
Since I’ve been at this since about 1998, I’m getting pretty good at nodding patiently and suppressing the urge to yank out my hair when I hear these rationalizations. It also helps that I’m as bald as a bowling ball, but if you’re not so lucky, here are 3 ways to justify and get buy-in for almost any investment in UX research.
- First, focus on the investment mindset: dollars spent on effective UX research always, always, always, return multiples in both savings and product advantages. This goes far beyond saying, “it is 10x as expensive to fix a problem after we launch as it would be to find that problem during development.” While technically (and provably [link]) true, you are far more likely to catch the attention of product managers and other key stakeholders if you focus on the upside. “We can leapfrog our competition/produce a product that’s 10x as good as what we have/score much more positive reviews and press if we spend 10% of our development budget doing research: we’ll get product priorities from our customers, as validate that we’re on the right track, so that we can focus our development budget on just the features that will make the most difference to our customers.”
- Aim to secure 10% of the overall project budget for “UX Research.” (Note: Not “UX”, but “UX Research.” “UX” can include anything even remotely related to anything the customer will see, including visual design and front-end development. Compartmentalize, my friends.) This is a low enough number that it doesn’t invite too much scrutiny, particularly if you have made a compelling argument about the returns on that investment. Also, getting it chopped in half during project negotiations, while frustrating, is not fatal. On even the skimpiest $1000 website redesigns, $50 will get you time with 5-10 people who are walking into a 7-11 who’ll look at your wireframe and offer useful feedback. (That is officially as cheap as it gets, folks.)
- Plan effective research: that means focusing on 5-10 “questions” that the team can agree are important to answer. Sometimes this starts as a list of “5-10 assumptions I’ve heard the team make, which are questionable assumptions.” Your job as a researcher is not just to do the research and answer the questions, but to help define what the questions are, and which are answerable.
If you put this all together into a nice, snappy, product- and customer-centric pitch to your team, it comes out as something like this:
“With 10% of our project budget, I can answer 10 critical questions we have about our audience/product/customer experience, and help us focus our time and effort on solving just the most important problems in the most efficient way. Oh, and we’ll likely save 10x as much in lost development time/rework after we launch.”
They will probably still say "no, we don't have time." AND THAT IS OK, because you have an "investment mindset" when it comes to UX Research - you are laying the seeds for future work that will help make your product or service better over time.