Evidence Connected
User research linked to product decisions rather than filed.
UX Strategy Services
UX Strategy Services That Decide What Not to Build
A roadmap assembled from everything anyone requested is a queue, not a strategy. UX strategy services connect what users actually need to what the business needs, and produce the harder half of the output: a defensible account of what is not being built and why.
We Produce the Exclusions Too
Any strategy that excludes nothing has not made a decision.
Exclusions Stated
What is not being built, with the reason recorded.
Criteria Agreed
How future requests get judged, so the argument happens once.
Sequenced
Order that reflects dependency and value, not who asked loudest.
Measured
What would show the strategy is working.
What makes a UX strategy real rather than aspirational
A strategy that lists principles everyone already agrees with has decided nothing. These checks test whether it actually constrains what gets built — which is the only thing that distinguishes a strategy from a statement of values.
Primary user namedWhich user the product optimises for when needs conflict
Explicit trade-offsWhat the product deliberately does not do well
Success definitionWhat outcome the experience is meant to produce, measurably
Current-state evidenceWhat is actually happening today, from data rather than belief
Prioritisation ruleHow competing requests are decided when both are reasonable
Scope boundariesWhat is out of scope, stated rather than implied
SequencingWhat happens first, and what it unblocks
Capability requirementsWhat skills or tooling the plan assumes exist
Organisational fitWhether the plan survives how decisions are actually made here
Review triggerWhat would cause the strategy to be revisited
Explicit trade-offs are the test that removes most documents calling themselves strategies. A plan that promises simplicity, power, speed and flexibility has ranked nothing, so every future conflict is resolved by whoever is most senior in the room.
UX Strategy, Explained
What Does a Strategy Contain?
Four parts, and the third is the one usually missing.
Discuss Your Strategy →- 1
Who It Is For
Specifically, including who it is not for.
- 2
What Problem It Solves
The problem, not the feature list.
- 3
What Is Excluded
And why, recorded so it does not get relitigated quarterly.
- 4
How Success Is Known
Measures agreed in advance.
What UX Strategy Work Covers
Evidence, decisions and the criteria that keep them holding.
The research that feeds it is covered by UX research. The evidence it works from is UX research; delivery of what it decides is product design.
How We Develop UX Strategy
Synthesise what is known, decide, and write down what was excluded.
Synthesise Evidence
What research and usage data already show.
Define the Audience
Including who is out of scope.
Frame the Problems
Ranked by value and confidence.
Decide and Record
What is in, what is out, and why.
Agree Measures
What would show it is working.
When strategy is the missing piece
Strategy work is warranted when the problem is repeated inconsistent decisions rather than a specific broken screen. Applying it to a straightforward usability problem is an expensive detour.
Products built by request
Where the roadmap is whatever customers asked for most recently, and the product has become a collection of features rather than a coherent tool. The strategy supplies the basis for saying no, which is what has been missing.
Organisations with several teams pulling apart
Where each team optimises its own area sensibly and the combined result is incoherent. This is not a design failure but a coordination one, and it needs an agreed primary user before component-level consistency helps.
Products serving conflicting audiences
Where two user groups want opposite things and every decision splits the difference. Naming which one the product optimises for is uncomfortable and it is the decision that unblocks everything downstream.
Businesses planning significant investment
Where a rebuild or a major expansion is being considered and the sequencing matters. Deciding what to do first, and what it unblocks, prevents spending the budget on the most visible work rather than the most consequential.
Teams whose research does not get used
Where findings accumulate and nothing changes, usually because no decision was waiting on them. The fix is upstream: tying research to specific decisions, which is a strategy problem rather than a research one.
Decisions
Why the Exclusion List Is the Valuable Output
Anyone can produce a list of good ideas. The decision is what gets left out.
What does recording exclusions prevent?
The same argument recurring every quarter. A feature considered and rejected returns, nobody remembers the reasoning, and it is debated again from scratch.
Recording the decision and the reason means the discussion is short: here is why we decided against it, has anything changed?
It also protects against reversal by whoever asks most persistently, which is otherwise how roadmaps get made in the absence of written decisions.
Why do feature requests make a poor roadmap?
Because they are solutions proposed by people describing their own situation, weighted by who is loudest rather than by how many share the problem.
Ten requests for different exports frequently indicate one underlying problem — a report that cannot be read in the product — which a strategy would surface and a request queue would not.
Aggregating requests into problems, before prioritising, is most of what strategic work does that a backlog does not.
A strategy is mostly a list of things you will not do
Documents titled UX strategy frequently contain a set of principles — intuitive, delightful, accessible, fast — that no organisation would argue against. Because nothing was excluded, nothing is settled, and the document has no effect on any subsequent decision.
A strategy becomes useful at the point it makes something harder. Naming a primary user means other users are secondary when needs conflict. Choosing depth means accepting a steeper learning curve. Choosing simplicity means declining capability that some customers will want. Each of these is a real cost, and it is the cost that makes the strategy operative.
The test is to look at a contested decision the team recently made and ask whether the strategy would have settled it. If both options remain defensible under the document, it is a values statement rather than a strategy — useful for alignment, useless for prioritisation.
Strategy has to fit how the organisation actually decides
A plan that assumes design has authority it does not have will not survive contact with the organisation. Where the roadmap is set by sales commitments, a strategy written as though product decides is describing a different company.
This means the strategy has to account for how decisions genuinely get made — who can commit to a customer, who arbitrates between teams, what happens when a large account asks for something off-plan. A strategy that works within those constraints will be followed; one that assumes them away gets overridden the first time it is inconvenient.
Sometimes the honest conclusion is that the constraint is the problem, and the recommendation is organisational rather than about design. That is a harder message and it is more useful than a plan that quietly assumes a different decision-making structure.
Sequencing matters more than the list
Most strategies identify a reasonable set of improvements. Fewer say what order to do them in, and the order frequently determines whether the programme succeeds.
Some work unblocks other work: settling information architecture before redesigning screens, or establishing a component foundation before building many new interfaces. Doing these in the wrong order means building things twice, and the second build is rarely funded.
Sequencing also determines whether the programme survives politically. Early work that produces visible improvement buys the credibility to do the structural work that produces none in the short term. A plan that begins with eighteen months of foundational work usually gets cancelled at month seven, however correct it was.
Questions, answered.
UX strategy services connect user evidence to product decisions — defining who the product is for, what problems it solves, what is explicitly excluded, and how success is measured.
A roadmap lists what will be built. A strategy explains why, and records what is not being built and why — which is what keeps the roadmap from being relitigated every quarter.
Because rejected ideas return, nobody remembers the reasoning, and the same argument is had again. A written decision makes that conversation short.
Not directly. Requests are solutions shaped by each person's situation and weighted by who asks loudest. Aggregating them into underlying problems is what strategy adds to a backlog.
Against measures agreed in advance — task completion, activation, retention, support volume. Measures chosen afterwards tend to be the ones that already moved.
Because rejected ideas return, nobody remembers the reasoning, and the same argument is had again. A written decision turns a recurring debate into a two-minute answer.
Product strategy decides what to build and for which market. UX strategy decides how the experience should work to serve that, including which user is primary and what the product deliberately does not optimise for. They are closely coupled, and UX strategy without a settled product direction usually ends up making product decisions by implication.
If the problem is specific screens failing, design work is the answer and strategy is a detour. If the problem is that decisions keep being reversed, teams pull in different directions, or the product keeps acquiring features without becoming better, that is a strategy gap and no amount of screen-level improvement will resolve it.
Until something structural changes — the market, the primary user, or the business model. Strategies revised every quarter provide no stability to decide against, which defeats their purpose. What should be revisited regularly is the sequencing, since priorities legitimately shift as work completes and conditions change.
Someone with the authority to decline work, because that is what a strategy is used for. Ownership by a person who can only advise means the document exists and gets overridden. Where design has no such authority, the strategy has to be agreed with whoever does or it will not hold.
Through outcomes the strategy claimed to affect, defined before the work starts — task completion for the primary user, support volume in a targeted area, activation for a named segment. Measuring general satisfaction tells you little, and attributing revenue to experience changes is rarely defensible. Any figure should come from your own instrumentation rather than an external benchmark.
Still deciding if ux strategy services is right for you?
Talk to UsIt Came Back the Next Quarter
A feature is proposed, discussed at length, and decided against for good reasons. The meeting ends, the roadmap is set, and the decision is not written down anywhere.
Three months later the same feature is proposed again, by someone who was not in the room, and nobody can reconstruct why it was rejected. So it gets discussed at length, again.
The most valuable artefact a strategy produces is not the list of what is being built. It is the shorter list of what was decided against, with the reason attached, which turns a recurring argument into a two-minute answer.
Free Strategy Conversation
Talk Through What You Are Prioritising
Tell us what is on your roadmap and how it got there. We will help you frame the problems and decide what to leave out.
Claim Your Free Marketing Audit
Enhance Your Brand Potential At No Cost!
- Expect a response within 24 hours
- NDA available upon request
- Dedicated product specialists