It’s a step a lot of people miss.
You may have painstakingly done the research and developed a fine strategy document, but that doesn’t mean you can just run off and start putting it to work. You need feedback as much as anyone.
And also, the people who contributed to your research would love to know you’ve been paying attention. They’d love to know you’re going to make a solid attempt at solving their problems.
Photo credit: Quantcast
The way to do this is to pull the crumpled 1-page strategy doc back out of your pocket and bring it to the people you interviewed previously. That, and to test out a few ideas to make sure they live up to your ambitions. That, and to see how the subject matter experts feel about it.
Finding The Right Time
The best time to validate your strategy is the second you finish a solid enough draft to show to people without a disclaimer attached. You don’t want to say, “It’s a work in progress.” You want to say, “We crafted this based on a lot of different factors, including the input you gave us.”
There’s a reason. Bear with me.
When you present design deliverables, one of the advantages of lo-fi work is that it elicits better feedback. When people see rough sketches, they think you’re not so invested in what you’re showing them. It’s just a sketch. This helps them feel like they can have opinions and speak freely.
Photo credit: Fairhead Creative
Conversely, the higher the fidelity, the more constrained people tend to feel. They think you’ve invested a lot of time and are nearly done, and therefore are less likely to offer sweeping insights. Instead, they’ll nitpick. (This is, of course, assuming you agreed on the design direction prior to this point.) You’ll get minor tweaks, not bold reactions.
For wireframes and prototypes, this is great. At least for a while — until agreement builds and you can refine the work.
For strategy documents, you don’t want strong reactions. Your strategy doc is based on a lot more than a single person’s input. It’s derived from data, stakeholder vision, competitive analysis, and from your own vision. And all of that has had the benefit of your experience, knowledge, skill, and talent as a UX professional to translate it into a strong strategy.
In other words, you didn’t just make it all up. When you’re presenting a strategy document, you’d better mean it.
Remember, a big part of your job as the UX person is to lead. You want people to know you’ve heard them, but also walk away with the confidence that you are taking charge. We will be making a better product. Rest assured.
A politician doesn’t ask questions from the stump. She lays out policy. She qualifies herself. She tells anecdotes to make a point. She crescendoes to a swell of applause.
If your strategy contained a horrible mistake, you’d have found about it before now. You presented your findings to the stakeholders, and they collaborated on and approved the strategy right along with you. There’s no mistake. And if there is, you made it together. You have a team standing behind you.
When it’s time to go back to the people you talked to during the research phase, bring them a structured, well-written, coherent strategy that lays out the product vision, its design criteria, and its success metrics, and step through it with confidence.
Grab design ebooks created by best designers
All for free
Do you want to know more about UI Design?
Download 'UX Design Process Best Practices' FOR FREE!
Download e-book for freeBack To the Users
When you go back to share your strategy with the users who initially gave you input, bring your notes from those initial interviews with you.
- Thank them again for the time they generously provided.
- Confidently review your strategy document. This is what the product will be. These are the principles we will live by to achieve that. And this is a list of metrics we’ll use to demonstrate it. What do you think?
- Take notes, or invite another researcher or designer along to act as the scribe.
- Then, one by one, remind them of a principle concern they had in your prior discussion, and show them something in the design that either deals with it or eliminates it altogether.
- If you have some, show them a few of your other favorite highlights, speaking exclusively to how the ideas will improve the product. Ask for their reactions. Let them react.
- Take more notes.
This process is not about “building consensus,” which ends up being a fancy phrase for “compromise” after you start bending to everyone’s demands. No. This is about making sure you heard everyone correctly and that your ideas will make their product experiences better.
Photo credit: GD Steam. Creative Commons.
You want their input. You want their reactions. You want to know that what you’re doing is something they can get behind. But you also need for them to believe in you. After you go live, you can tweak and rethink things all you want. You’ll do that based on data — actual numbers reflecting actual usage behavior. That’s later. For now, you want to focus on leading a pack of people behind a unified vision everyone supports and wants to subscribe to.
Do this well and the users you interviewed will become advocates. Hold back and they’ll become mutants on the attack.
Inviting Scrutiny From SMEs
Remember the subject matter experts you spoke to during the research and discovery phase?
You’ll want to let them take a look at the strategy as well. And any early designs that show it off. The SMEs, by definition, know more about the subject matter at hand than you do, or probably ever will. If anyone can poke holes in a design strategy meant to disrupt a status quo industry, it’s them.
Your SMEs could be lawyers, accountants, power users, or someone else. Whoever they are, asking them to scrutinize your strategy and designs will accomplish two big things for you:
- It will let you vet your strategy through one of the strongest resources you have.
- It will keep your SMEs talking, and feeling respected, and feeling involved in the process, which will later turn them into advocates as well.
The Truth Is Out There
There is one major alternative to consider in all this. Namely, when your product is already live and running.
You still can’t forego the strategy doc. You should still do the research and define the strategy — for every overhaul, for every feature. Your improvements should be based on a lot more than the data that comes from a functioning website.
But if you do have a live, functioning site, you can validate ideas in the same way: live.
Assuming you have a decent amount of traffic, you can run A/B tests. You can track usage patterns and analyze the data. You can learn how your strategy actually pans out once it’s gone beyond throwaway design deliverables.
You can stop dealing in hypotheticals and start getting very real about whether or not your strategy is the right one. You can flip the switch on a new feature, or a design aesthetic, or an entire app. And you can get real numbers back.
Increased risk, for sure, but there is arguably no better way to validate a strategy than to test it out on real people in real situations by launching the design based on it. Yes, you should mitigate that risk as much as you reasonably can beforehand, by doing all the things I’ve mentioned already, but don’t get yourself stuck in analysis.
Launch the thing. If it doesn’t work, revise.
Don’t marry yourself to any one idea. It’s all an experiment. Until you get real data out of it, it’s all hypothetical.
If you found this article helpful, check out Robert Hoekman’s e-book The Field Guide to UX Strategy, an actionable guide based on his 15 years of experience. Define, document, execute, and test your UX strategy with methods outlined in this free e-book.
