What a UX strategy is — and why most teams should write one
A UX strategy is a short document that says what good looks like for the people using your product, and how the team plans to deliver it. That’s it. No frameworks, no McKinsey decks, no 113 slides.
When I join a project, one of the first things I do is ask if there’s a UX strategy in place. Most of the time there isn’t. Sometimes there’s a brand book, or a product roadmap, or a Notion page someone wrote a year ago and then forgot. Rarely is there a document that actually says: this is what we mean by a good experience, and this is how we’re going to get there.
It’s not that teams don’t care. They almost always do. It’s that nobody’s written it down, so the care gets spent in fifty different directions and the product ends up feeling like a committee made it. Which, in a way, it did.
What a UX strategy actually is
The phrase trips people up, so I usually pull the two words apart.
UX is what someone experiences when they use your product. Not what the product does — what it feels like to use. Two apps can have identical feature lists and feel completely different. iPhone and Android. Notion and Confluence. Linear and Jira. The features are the same on paper. The experience isn’t.
Strategy, stripped of the consultant baggage, is three questions. Where are we now. Where do we want to be. How do we get there. That’s the whole shape of it. Everything else is detail.
Put them together and a UX strategy is a document that answers those three questions specifically about the experience you’re building. What’s the experience like today, what do you want it to feel like, and what are you actually going to do to close the gap.
It’s not a deliverable for clients. It’s not a marketing document. It’s a working tool the team uses to make decisions when nobody’s in the room to ask.
What goes in one
I’ve written a lot of these over the years and the contents vary, but the bones are usually the same.
Where you are now. A short, honest snapshot. Who your users are, what they’re trying to do, where they get stuck, and how the current experience compares to alternatives. Not a research report — a summary the team can hold in their heads. If it’s longer than two pages, it’s not doing its job.
Where you want to be. This is the part most teams skip, because it requires picking a direction and sticking to it. Not goals like “improve the user experience” — that’s not a goal, that’s a wish. Specific principles you can actually hold a design decision against. We’ll come back to those in a minute, because they’re the part that does the most work.
How you’ll get there. The practical bit. What’s going to change. Who’s going to do it. What you’ll stop doing to make room. I’m partial to this section because it’s the part most strategies leave out, and it’s the reason most strategies don’t survive contact with real work. A direction without a plan is a wish list.
Length-wise, a good UX strategy is short. A page can be enough. Two is plenty. Anything longer and people will paste it into Claude and ask for the summary — which means the summary is the real strategy, and you wrote the rest for nothing.
Goals are principles, not action items
The most important section in any UX strategy is the one defining what good looks like. And the best way I’ve found to do that is to write principles, not features.
Principles are desired outcomes. They sound like sentences, not roadmap items. Some I’ve used over the years:
Design for everyone. Build for the eighty percent, not the loudest twenty. Every team I’ve worked with has someone — a stakeholder, a power user, a vocal customer — who keeps asking for the next feature. Most of those features serve almost nobody. A principle like this gives the team something to point at when the request comes in, instead of just saying no and feeling bad about it.
Optimize for speed. Most products are judged on how fast they feel before they’re judged on anything else. Not literal load time — perceived speed. How quickly something responds. How few steps it takes. People will forgive almost anything if the product feels fast.
Different is good. Make the important thing obvious. The primary action should be visually distinct, placed where people expect it, and impossible to miss. Insecurity is the root of bad user experiences. If the user is wondering what to do next, you’ve already failed.
Always start with what’s familiar. Your users spend most of their time in other apps, not yours. Look at the patterns they already know. Borrow shamelessly from the conventions of the industry you’re in. Familiarity isn’t a lack of imagination — it’s respect for the user’s time.
These are just examples. Yours will be different, and they should be. The point isn’t the specific principles, it’s the form. Write things you can hold a real design decision against on a Tuesday afternoon when nobody’s watching.
Why this matters more now
For most of my career, UX strategy was the kind of document large teams wrote because they could afford to. Smaller teams skipped it. They were busy shipping, and shipping was the hard part.
Shipping isn’t the hard part anymore.
The cost of building has collapsed. Anyone can put a working product on the internet in a weekend. Tools write half the code. AI handles the parts that used to take a junior designer a week. The bottleneck used to be execution, and execution is now nearly free.
Which means the hard part is the part that was always hard but easier to ignore: knowing what’s worth building, who it’s for, and what good would even look like. When making things was expensive, you had to be careful before you started. Now you can start anything, which is exactly why so many teams are shipping a lot of things that nobody needed.
A UX strategy used to be a luxury. It’s becoming the thing that separates teams who ship useful work from teams who ship a lot of work. I’ve written about this from a couple of different angles — vibe coding for designers covers what changes when designers can build, and simple is hard is about why restraint is the harder discipline. A UX strategy is the document that makes restraint possible.
What a strategy actually does
The thing nobody tells you about UX strategies is that the document itself isn’t really the point. The point is the conversations you have while writing it. The disagreements that surface. The assumptions that turn out not to be shared. The “wait, is that what we’re optimizing for?” moments that happen when you try to put it on paper.
The strategy is the artifact. The alignment is the work.
When I look back at the projects where the team shipped well and the ones where it didn’t, the difference was almost never talent or budget. It was whether the team agreed on what they were actually trying to do. Sometimes that agreement existed without a document. More often it didn’t, and the document was what made it real.
If you’re on a team without a UX strategy, you don’t need a long one. You don’t need a template. You don’t even need to call it a strategy if the word makes people roll their eyes. You need a few pages that say what good looks like, what you’re going to do about it, and what you’re going to stop doing to make room. Then you need everyone on the team to actually read it.
The surprising thing isn’t that most teams don’t have a UX strategy. It’s that most of them are doing fine without one, until suddenly they aren’t.
A strategy is what you wish you’d written before things got hard.
I wrote a chapter on UX strategy in Products People Actually Want — if you want the longer version.