Design strategy: a working framework

TL;DR. A design strategy is a one-page plan that says what design will and won’t do this year, who it’s for, what success looks like, and which two or three initiatives carry the weight. It’s not a manifesto, not a Figma board, and not a mood. It’s the bridge between business strategy and the next sprint, and it lives in a wiki where the next person who joins can find it.

If your team’s design strategy is currently a Figma file nobody has opened in four months and a Loom recording from last quarter’s all-hands, you’re not alone — most of them are. (Maple, our UX designer, has a houseplant on her desk and an opinion about every design framework. We’re sparing you most of them.) The good news is that a design strategy is not actually a complicated document; the bad news is that most of the templates online are forty-page decks pretending otherwise. The rest of this post is the working version: what it is, how it’s different from design thinking, the five steps that actually matter, and where the doc has to live to be useful in October.

A design strategy is a plan, not a poster

The textbook definition: a design strategy is the intentional application of design principles to meet business goals — a plan that includes business objectives, user research, design principles, an implementation roadmap, and success metrics. That’s accurate and almost useless to a team trying to ship something next quarter.

The working definition: a design strategy is a one-page answer to four questions.

Who is design serving this year? Which users, which customer segments, which internal stakeholders. Specific.
What does success look like? Measurable outcomes, not “better UX.” Activation rate up by X, support tickets down by Y.
What are design’s two or three big bets? Not the whole backlog — the two or three initiatives where design is load-bearing.
What is design not doing? The list of things it’s fine for design to skip this year. This is the section that makes the strategy a strategy and not a wish list.

A poster is a strategy missing the not doing list. A plan is a strategy with one. The difference is which of them you can actually execute against.

Design strategy vs design thinking, in two sentences

These two get used interchangeably and they shouldn’t.

Design thinking is a methodology for solving a problem — empathise, define, ideate, prototype, test. It’s how you work on a thing.
Design strategy is a direction — which problems are worth solving for the next year, who they’re for, and what success would look like. It’s what you choose to work on.

You can run design thinking inside a design strategy (“this quarter we’re sprinting on onboarding; here’s the empathy research that informs it”) and you can run design thinking with no design strategy at all (“we sprint on whatever the loudest stakeholder shouted last” — common, not recommended). The strategy is the upstream choice; design thinking is the downstream method. Mix them up and your team ends up busy without being aimed.

What goes in a design strategy doc

A working design strategy is one page. Five sections, in order, each a paragraph or a short list:

Audience. Who design is serving this year. Two or three named user types, plus the internal stakeholders who’ll feel the work. “Tier-1 SaaS admin” beats “users.”
North-star outcomes. Three to five measurable goals tied to the business. Same numbers your CEO would recognise. “Trial-to-paid conversion from 8% to 12%”, not “increase delight.”
Big bets. Two or three initiatives. Each a one-liner: “Rebuild the onboarding flow for self-serve sign-ups,” “Ship a real settings surface so support can stop hand- holding.” Owners attached.
Principles. Three to seven sentences your team uses to break ties when two reasonable designs disagree. “Keyboard-first, mouse-optional” is one of ours; pick yours, defend them, and don’t pad the list.
What we’re not doing. A list of plausible work design won’t take on this year, and why. The hardest section to write. The most useful one.

That’s the shape. The Toptal design strategy guide and the Nielsen Norman Group’s UX-strategy articles go deeper on the why; the shape on the page should still be a single doc. Templates are scaffolding, not finished work — the headings give you the bones; the team fills in the specifics, defends them, and revisits them next quarter.

A working five-step framework

A design strategy framework is the operating loop that produces and refreshes the doc above. Five steps, none of them require an offsite.

Read the room. Read the business strategy, the roadmap, last year’s metrics, and the support tickets. You’re looking for the gap between “what the company says it wants” and “what the team is actually shipping.” That gap is where design earns the year.
Pick the audience. Two or three user types you’ll centre. Don’t pick five; you can’t serve five well. The audience choice is the strategy.
Set three to five outcomes. Numbers that can be true or false at the end of the year. “Improve UX” is not an outcome; “Reduce time-to-first-page from 12 days to under 7” is.
Commit to two or three big bets. Each one is a project that, if it works, moves the outcomes. Each one has an owner. Each one has a date. Two or three is the number; four is too many; one is fragile.
Write the not-doing list. The plausible design work you’re saying no to this year, and why. Some teams call this strategic underspending; some teams call it Tuesday. Either way: it’s the section that lets the team focus.

That’s the loop. Every quarter — at the QBR, naturally — you re- read the doc, mark what worked, and decide whether the bets need amending. The strategy isn’t an annual carving in stone; it’s a quarterly conversation with last year’s version of you.

Where the design strategy lives between meetings

This is the part the long-form SERP guides skip. The top-3 results for design strategy explain components and frameworks at length and never say where the doc actually sits between sprints. Here’s the lesson, after watching teams ship and re-ship the same design strategy in slightly different formats: the strategy lives or dies by whether your team can find it on a Tuesday afternoon.

Concrete moves that work:

One page, in your wiki, not a deck. The deck is for the all-hands; the page is for the team that opens it twice a week. Pages load in 50–150ms depending on your network on Raccoon Page; if your strategy doc takes a second to load, your team will read the Slack DM about it instead.
Linked from the team charter. A team charter holds the scope; the design strategy is the design-shaped slice of it. If they’re not linked, neither one gets used.
Updated, not replaced. When the strategy changes, edit the page and bump the last reviewed date. Don’t make a new page called “Design Strategy v2 (final FINAL)”. That’s how strategies die — death by versioning.
Findable by the search bar in one query. Title it “Design Strategy 2026” and let search do its job. Sub- second loads, keyboard-first is the practical bar; if search doesn’t return it on the first hit, the doc isn’t in the right place.

The strategy is also where new designers onboard. “Read this page, then we’ll talk” should take a new joiner an hour and land them with the same context the rest of the team has. If they finish the page and still need to read four more, the strategy isn’t the strategy.

This is the same shape as every other operating-discipline doc — same loop as a team charter, a quarterly business review, or the knowledge-management discipline that holds the rest of the team’s writing together. The digital workspace is where they all live.

When you don’t need a design strategy yet

Three signs writing a formal design strategy this quarter is the wrong move:

You’re a team of two designers (or one). Two designers sharing a Slack DM and a Figma file are the design strategy. The doc earns its keep when the team can’t agree on what to work on without one.
You don’t have a stable business strategy to align to. Design strategy is downstream of business strategy. If the company is mid-pivot every six weeks, the design strategy will be too — and writing it down formally is premature optimisation. Wait six months.
You’re pre-product-market-fit. Pre-PMF, design works on whatever the next experiment needs. The strategy is “learn fast,” and that strategy doesn’t need a five-page doc to defend.

Above that bar, the doc earns its keep. Below it, you’re writing strategy theatre, and the team will read past the page on the way to actual work. Pick the cheapest plan that fits the job. (Same logic, by the way, applies to wikis: our Free tier — three users, one space, a hundred pages, no card — is the right home for the first design strategy doc a team writes; if and when you grow into needing real-time co-editing on it, the Team tier at $8/user/month is the honest math.)

Things people actually ask

What is a design strategy, in one sentence? A one-page plan that says who design is serving this year, what measurable outcomes it’s chasing, which two or three initiatives are load-bearing, and — this is the load-bearing part — what design is not doing.

What’s the difference between design strategy and design thinking? Design strategy is the direction (which problems are worth solving); design thinking is the method (how to solve a specific problem). The strategy is upstream of the method. Mix them up and your team ends up busy without being aimed.

What’s the difference between design strategy and UX strategy? UX strategy is the user-experience-specific slice of a broader design strategy — same shape, narrower scope. Most small teams write one document and call it whichever fits their org chart; both names are fine.

Why is UX design strategy important? Without one, the design team’s work is a queue of whoever shouted loudest. With one, the team can say no to shouting that doesn’t fit the year’s priorities — which is the actual mechanism that makes design teams effective at scale.

Who writes the design strategy? The head of design, in conversation with the product and business leads. Not in isolation; the strategy is downstream of the business strategy and a strategy nobody else has read is a strategy that doesn’t exist.

How do you measure the success of a design strategy? By the outcomes you wrote into it, not by the strategy document itself. If the “trial-to-paid conversion from 8% to 12%” goal lands at 11%, the strategy mostly worked. If it lands at 9%, you missed; figure out why.

How often should a design strategy be updated? Reviewed quarterly, materially edited annually. The bets and priorities adjust quarterly; the audience and outcomes shift yearly. If you’re rewriting the whole thing every quarter, you don’t have a strategy — you have a roadmap with delusions of grandeur.

What are common design strategy pitfalls? Two big ones: writing a strategy without a not-doing list (it ends up a wish list) and writing a strategy nobody can find on a Tuesday afternoon (it ends up irrelevant). Both are fixable; both are common.

If your design strategy is currently a Figma file nobody opens twice, the upgrade isn’t a different file — it’s a short doc on a fast wiki the team will actually read. Try the Free tier on your team’s first one-pager. If you can’t find it again in October, write to us; we want to know which heading you skipped.