The 11 minute guide to a bulletproof UX strategy

The heart of great UX strategy lies in thorough research. Unfortunately, UX research is usually a mess.

If you’re an outsider, you’re still getting to know everyone involved in the project at the same time you’re navigating which research activities to take on. If you’re an insider, it can be the same story.

Even if you already know everyone, it’s a new project, and that means new approaches, new information, new documents, new everything.

Sure, there’s been a kickoff, but now you’re into the real stuff. You have to become an expert on this product as quickly as possible.
You have to figure out who to talk to, what they know, how to make the most of each resource, and how to turn it all into a sound UX strategy everyone will agree with.

The well of knowledge

The principal stakeholders on the project will have a good idea who’s available to talk (and they will likely be on the list themselves). If they don’t, they can point you to the people who do.

Oftentimes, for example, larger companies have a user researcher on staff who will already know plenty about any existing user base. If you’re building something brand new and there is no user base just yet, your options will be far more limited. Either way, discovery involves people and data.

There are a few places you can go to gain insight relevant to your product’s future success. Each one has different cares and concerns.

Primary stakeholders

These are the people in charge of the product.

In a startup — especially a newer one — it’s usually the CEO and/or CTO. New companies don’t often have more than one or two major stakeholders. For more established startups, you may also find a product manager.

Whatever the title, in a startup situation, odds are good that at least one of your primary stakeholders is the person authorizing your paycheck.

When you talk to one, speak to data and to revenue. In startups, primary stakeholders often have a financial stake in the business. In larger companies, their jobs depends on a product’s financial success.

As explained in the free Field Guide to UX Strategy, include questions like:

• There are a billion ways to make money. Why this one?
• What do you see as the biggest concerns with regard to the user’s experience, and why?
• What do you think is working well?
• How do you believe this product compares to its competitors?
• What particular metrics would you like to see improved?

(Pro tip: Keep your questions scoped to what a particular person cares about most and knows most about. A primary stakeholder may be intensely concerned with the state of the business, but this doesn’t mean he or she is a wealth of expert information outside of their own role.)

When they give you answers about the product’s purpose, scope, users, competitors, and so on, these answers are driven by financial concerns. So when you make recommendations later on, be sure to couch them in discussions about what percentages of users do generally or are doing in this case, and with regard to how a decision affects the product’s ability to make money.

For more on this, Kim Goodwin has a great writeup on the kinds of questions to ask.

Secondary stakeholders

These are people whose roles are incredibly important, but not to the level of actual ownership or financial stakes. People like development leads, marketing leads, and whoever’s going to be doing the bulk of the visual design work.

Secondary stakeholders can also be people outside the company or the immediate project team, like an investor or investment group, a higher-level executive, or even someone the CEO deems worthy of decision-making power.

In interviews with secondary stakeholders, first lay out the high-level description of what you and the primary stakeholders have decided or want to achieve. From then on, focus only on the part of the project the secondaries affect. If it’s a graphic designer, ask about what visual design directions might be feasible, what’s been done in the past, how that person thinks the current version performs, and so on.

What you ask entirely depends on the person’s role. Stick to the person’s area of interest. Anything outside of that carries high risk of misleading information and perspective.

Current users

If the product exists already, you can almost certainly dig up some enthusiastic users.

Your instinct is going to be that these people need some sort of compensation for their time. It’s not likely true. People love to give their opinions. They will not expect anything from you unless you plan to take up a lot of their time. Keep it to one to three phone calls and you’ll get happy, talkative people who want to help in any way they can.

The stakeholders will know who the most active users are and how to reach them.

Simply email the users to set up a meeting (phone, Skype, in-person, whatever is convenient). Introduce yourself, explain your role, explain that the company is researching ways to improve the product, and ask if they’d be willing to answer a few questions. Do this in as few sentences as possible to respect their time.

Here’s a few tips:

• Set up meetings with at least three users. More can be better, but not always. After five or so, you’ll start to hear all the same things the first four said.
• Invite other team members. For example, another designer or researcher can help take notes while you focus on follow-up questions. Marketers and developers can also benefit from a firsthand understanding of the user’s background and behaviors.
• Build rapport by asking about their lives, their hometowns, how they became so attached to the product you’re asking about.
• Instead of asking only about feelings and preferences, ask about behaviors. For example, “What do you do when…” instead of “How do you feel when…”. Also try asking more open-ended questions since you’ll have more room to explore compared to binary yes/no questions.
• Prepare a list of questions beforehand. Treat this as a guideline rather than a script, since the interview will likely deviate somewhat from what’s on paper. But that’s alright because it gives you room to investigate user characteristics that you might have overlooked during preparation.
• Ask lots of follow-up questions when you start discussing the product. No answer is cut and dry. If a complaint starts but then goes nowhere, chase it. Find out what’s causing the grief. Do this for anything that piques your curiosity.
• Before you get off the call, ask if you can get back in touch once you have some design ideas worked out. You want to make sure you’ve interpreted their concerns and needs correctly and are able to address them in the product.

To learn more about user interviews, Erika Hall has written up an excellent piece on the topic for A List Apart.

Beta testers

If the product is brand new, the stakeholders may have a relatively functioning prototype hanging around online already.

They’ll refer to this as “the current site” or “current app”. “The existing site” doesn’t always resemble the thing the stakeholders really want to achieve. But sure enough, they’ll have a few beta testers on the case.

Get in touch with beta testers. Again, at least three.

Usually, by the time you talk to all of them, there’s not much left of “the existing site.” The beta testers, you’ll discover, may need something else entirely. “The existing site” won’t live long.

(In some cases, “the existing site” is actually pretty solid. When that happens, your job is mostly to validate what’s good, tweak what’s not, and move on to a project that really needs you.)

Beta testers are often less invested in a product than users of more developed products. They’re also often more frustrated, since “the existing site” is usually heavy on bugs, light on features, and little more than proof of a weak concept still in need of good ol’ fashioned UX work.

Be empathetic. Ask about their usage cases so far. Their problems. Their disappointments. Their biggest wishes. Stress that your purpose is to improve the thing, and you can’t do it without them.

Subject matter experts

Once in a great while, you work on a project tied to a deep field of knowledge, like say, accounting, or environmental planning, or architecture. When you do, you should absolutely talk to whomever the stakeholders have identify as their resident subject matter experts (SME).

You probably won’t want to talk to them every day. They can easily overload you with facts and opinions that, while crazy fun to learn, will only slow you down and possibly send you off course.

But in appropriate doses, these people are your biggest assets. They frequently know things the stakeholders don’t and are happy to tell you how the stakeholders misinterpreted their expertise on prior occasions.

Often, the primary stakeholder for a product is the subject matter expert (especially if they have a strong technical background).

Never assume you understand something completely when talking to a SME.  Spend nearly 100 percent of your time asking questions and listening and restating to make sure you’ve heard them correctly. When you come back to them with design ideas later on, you can map your ideas to their previous input.

Even if you’ve done your job well, they’ll have things to nitpick. But eventually, you’ll get to something they agree with.

Users of competing products

Besides using competing products yourself, you can see what those products’ other users have to say about it. Not necessarily by stalking them online and trying to either poach them or get them to say inflammatory things, but by reading their reviews.

Buried inside their comments online are usually all kinds of hints about what they really have trouble with. Read between the lines.

Data

If there’s data to be had, it’s time to do a little dance of joy.

In person, people can lie. They’ll give you all sorts of false self-assessments about their dealings with a product, including how they supposedly do things, how easy or hard a task supposedly is to complete, and what they would supposedly do in a given situation. While informative and better than not talking to users at all, take their answers with a grain of salt.

Data gives you something to compare their answers to. If anything has been tracked on “the existing site,” pour over it and learn what you can. You could see that users tend to stay on a particular screen for what seems like a very long time. You could discover that only a small percentage of users are getting through the sign-up process.

Find out what’s available, and compare the insights to other sources to create a clearer picture of the behavior of any existing users. Event-tracking tools like KISSMetrics and predictive behavior tools like MadKudu all help you arrive at the real version of the truth.

UXPin, for example, uses MadKudu to map out the behavior of users leading up to a purchase.

Throughout the onboarding experience, individual product events (like “Create a Prototype” or “Commented on Prototype”) are also logged in KISSMetrics. The UX team can then combine the in-app data with user interviews and usability test results to triangulate where improvements are required for onboarding and post-purchase.

Putting it to work: The UX strategy document

I’ve talked many times about what goes into a UX strategy document.

Just about everything you learn in the discovery phase here will feed into a one-page document:  

• Vision- The product vision laid out by the primary stakeholders melds together with the thinking of most of these interviews to turn into a coherent vision statement for the long-term product design.
• Circumstances of Use – The user interviews and research will help you define the situations in which the product is used (Who, What, When, Where, Why).
• Design Criteria– Through all these stakeholder and user interviews, you’ll also identify design aspirations that will help you improve the product compared to its competitors, compared to now, compared to what the stakeholders think is working well and what isn’t. “Fast, easy, and intuitive” doesn’t fly. You need to focus on how you’ll achieve those principles, e.g. “Let users slice available statistics in any way that might be helpful, so that analysis can be done in a timely manner.”
• Success Metrics – Based on the existing data, you can project realistic success metrics for the design. Don’t just write down, “Get more traffic.” Ask how much traffic. Ask what you want that traffic to do while it’s hanging around on your website. Ask what percentage of people you want to sign up for your app three months from now as compared to today.

The important part is that you apply the information when creating the strategy document. No matter how much or as little as you get.

If there are no beta testers, no existing users, no existing site, no subject matter experts, and no data, it’s going to be up to you to find competing products — relevant or related products — and talk with the primary stakeholders to form a strategy without all that. This happens a lot. It’s nothing to panic about.

Conclusion

Invention doesn’t always have a lot of evidence behind it. In these cases, the discovery phase can take as little as a day.

In other cases, you can have several weeks to do all this research. You can spend three or four weeks on a project before you write a single line of the strategy document.

But at the end, you’ll have a UX strategy. And with that comes the guiding light for the rest of your project.

For more advice on planning and executing UX strategies, check out the free Field Guide to UX Strategy. The tactics are based on my 15 plus years of UX work with companies like Intuit, Rackspace, Adobe, Dodge, and others.

Read next: What Twitter’s jumping heart taught me about emotional impact