*But Were Afraid to Ask
UX Strategy is like sex in the sixth grade; everyone talks about it, almost no one is doing it, and the learning material is all about its consequences.
- UX strategy is a form of communication.
- A good UX strategy is short (fits into one page).
- And doesn’t focus on UX design.
- It is aimed at senior managers and executives, but send it to your team too and add your personal touch to it
- The goals are the first and most important part of the strategy document, you should balance business and user goals here.
- Finish the document with a schedule and the cost, those are the other things senior managers will look for.
- For a quick win use the kaizen-ux delivery process.
A story from the stone age of the web
More than a decade ago I used to work as a front-end developer. Back then this meant that I had to write HTML, CSS and JS, and fix it for Netscape and IE (the fixing part was 90% of the workload). Oddly enough web development started with visual design. There was very little or no strategy involved.
Fast forward to 2015: If you take a closer look at how user experience is “created”, you can find shocking similarities. Even large corporations tend to start UX with a design, and then they spend a lot of time trying to “fix it”. There is very little or no strategy involved. If there is, it is an afterthought, not the very first step of the process. Now it’s time for the UX community to enter the bronze age, and start
smelting ore creating UX strategies.
Don’t pounce on UX Design
The main problem with most user experience strategies I have seen is that they focus on UX Design. I think that a strategy should start with business objectives and user goals and focus on user research. Not only because that’s the next logical step after creating a strategy, but also because UXR tells you “what’s wrong?” and “why is it wrong?”. UX design consists of tactical solutions to the problems, which leads to delivery.
Long UX Strategies are bad, m’kay?
Long strategy documents might resonate well with some people, but in my personal opinion they are a waste of time. You should keep them as simple and short as possible. This way you will be more likely to get buy-in. Chuck Hollis argues that you should keep strategies simple:
I often get trapped into thinking I have to share the wonderful world I’ve discovered. That won’t work. As I’m going through my refinement process, I’m consciously ditching big parts of the discussion that aren’t relevant and only serve to muddy the water.
Who Are You Planning For?
Let’s face it, the most likely intended audience of strategy is a handful of senior managers and executives. They will most likely care about 3 things: goals, schedule and cost. This is great, because more than that would not fit in a short strategy document. Senior managers and executives would not spend hours reading a very detailed strategy, complete with dozens of addenda and footnotes longer then this blog-post.
Also send the one pager (especially the objectives) to each team member. Having a solid strategy increases morale. Don’t forget that you should pour a bit of yourself into it. A personal touch always helps.
Goals – How to start a strategy document?
You will be tempted to start with “Why is UX strategy important?” or “Background information”. The thing is I would suggest to start with: “How does this help the organisation?”. This will maximise impact and grab the attention of the readers (attendees if you are presenting it).
First we must have clear business objectives, and an understanding of how UX can help meeting both business objectives and user goals. As UX manager, you must be a champion of users inside the organisation, but you should also have a strong passion for helping the business succeed. A good UX strategy reflects this duality.
The most important thing here is to set the right expectations. The goal of the document is not to explain things in detail, definitely not to go into fine details (like test design and panel segmentation), but to secure buy-in for the UX.
Schedule and cost
The schedule/cost section is often the trickiest part. You should always thoroughly research the time, money and other finite resources needed for any project. It also helps to check for alternative solutions.
Just because you always used one eye-tracking lab, it does not mean you need to use the same lab again, and it might be worth re-evaluating if the projects need eye-tracking in the first place. Maybe you can cut costs there.
How does this fit into the big picture
Contrary to popular belief, the whole point of this blog is not (entirely) to show the world how awesome I am, but to help you deliver outstanding digital experiences. To achieve outstanding UX I recommend the Kaizen UX Delivery Process.
This process starts and ends with a UX strategy. Because it is a continuous improvement process, the essence of the previous iteration (complete with the feedback you get after delivery) will lead to a new, improved UX strategy.
Communication is Key
You should show the strategy to your line manager (or whoever asked you to create it) when it’s done. By done I mean you have written it, let it “age”, pondered over it for a few days (if possible) and reworked it once or twice.
This is not the end, only the beginning: It is very important to patiently explain it (or its relevant parts) to everyone involved, and try to get as much feedback as possible. Failing at certain parts of it is ok, and less painful in the early stage.
If your strategy initiates a (research focused, user centric) discussion high in the chain of command, then it was worth it. When it comes to signing-off a UX strategy, failure or partial failure can be a rite of passage, and it can help get the organisation more user centric, or more data-driven/research focused… and you can always create a new one amending the shortcomings of the previous one.
UX strategies should be the starting point of the UX process, and writing them should be a common task for a UX expert. As companies embrace user-centricity this will happen naturally. I don’t think the length or scope will change, and communication will always be the key element here.