Capability · UX Strategy

Deciding what to buildbefore you build it.

UX strategy decides what experience the software should create and why — which users it serves, which jobs it does for them, and the priorities that keep hundreds of later decisions consistent.

People conflate UX strategy with UX design, and the two are not the same. Design is how the experience looks and behaves. Strategy is the argument for why that experience should exist in the first place — which users it serves, which jobs it does for them, and how doing those jobs well moves the business.

You can spot software built without UX strategy from a mile away. It has a settings screen with forty toggles because no one would decide on defaults. It has five ways to do the same thing and no clear way to do the important thing. Every feature was somebody's good idea, and none of them add up to a point of view. UX strategy is what supplies the point of view.

Our job is to give the experience a spine — a small set of principles and priorities clear enough that hundreds of downstream decisions can be made consistently, by different people, without a meeting for each one.

Anchored in jobs, not features

We lean heavily on jobs-to-be-done thinking, because features are a trap. Customers don't want a feature; they hire your software to make progress on something they care about. When you understand the job — the real one, in the customer's context, with all its emotional and social weight — the feature decisions get dramatically easier.

So we map the jobs your software is being hired for, rank them honestly, and use that ranking as the tiebreaker for everything downstream. It's remarkable how many roadmap arguments simply dissolve once everyone agrees on which job matters most.

A strategy you can hold in your head

A UX strategy that lives in a hundred-page document is useless, because no one reads it and no one can act on it under pressure. The strategies that actually change how a team works are short enough to remember: a handful of principles, a clear priority order, a few things you've explicitly decided not to do.

We write for the moment of decision — when a designer, engineer, or product manager is staring at a tradeoff at 4pm and needs to know which way to lean. If the strategy doesn't help in that moment, it isn't strategy, it's paperwork.

Where it fits in the method

Every Artifact engagement runs on one method: Understand → Design → Build → Launch → Grow. These are the stages where UX Strategy does the most work. See how we work.

  1. 01Understand

    We map the jobs people hire the software to do and rank them, so the product has a clear priority order before anything is designed.

  2. 02Design

    Principles get pressure-tested against real scenarios in working prototypes, not just argued in workshops.

  3. 05Grow

    Decision rules and priorities keep the software coherent as new features arrive and new people start making decisions.

What you get

  • A prioritized map of the jobs your software is hired to do
  • A short, memorable set of experience principles with real teeth
  • An explicit list of what the product will and won't do
  • Decision rules that let teams stay consistent without constant escalation
  • A north-star framing that connects the experience to business outcomes

Who it's for

  • Product teams whose feature list has outgrown any coherent point of view
  • Organizations planning a major build who want to decide before they design
  • Leaders tired of relitigating the same roadmap arguments every quarter
  • Teams that have research but haven't turned it into a position

Common questions

Isn't this just product strategy?
They overlap and should talk constantly. Product strategy tends to focus on the market, the business model, and what to build. UX strategy focuses on the experience of using it — the jobs, the priorities, the principles that make it coherent. Done well, each sharpens the other.
Can you do UX strategy without a lot of research?
We can start with what you have, and we're honest about the gaps. Sometimes the right first move is a focused round of research; sometimes there's enough signal in existing data and customer-facing teams to take a defensible position now and refine it. We'll tell you which situation you're in.
How does this connect to design and build?
Directly, and without a handoff. Because the same senior team carries the work from strategy into research, design and engineering, the strategy shows up in the software instead of getting lost in translation between teams.

Building something big? Decide what it should be first.

Tell us the problem. We'll tell you honestly whether software is the answer — and bring the strategy, design, engineering and AI to build it.

Start a Project