I used the phrase "design as a business tool" in a workshop last year. A senior designer, maybe 15 years of experience, stood up and said his clients don't even want to hear about it. "Once the project is done, they vanish," he said. "They don't want strategy. They want screens delivered on time."
He wasn't wrong about his experience. But he was diagnosing the wrong problem. His clients didn't reject design strategy. They rejected a relationship where the only value exchange was deliverables. The moment the deliverables stopped, the relationship ended cos nothing else held it together. That's a client relationship problem, a value positioning problem, a trust problem. Calling it a "design strategy doesn't work" problem is like saying your car doesn't work cos you've been putting diesel in a petrol engine.
I see the same reaction to the word "strategy" itself. People comment under posts saying "strategy is vague" or "strategy doesn't mean anything." And honestly, for someone who's spent years executing someone else's plan without ever building their own, the word probably does feel empty. You can't see the value of something you've never held.
But the data says something different about whether strategy matters.
McKinsey tracked the design practices of 300 publicly listed companies over five years. The ones with top-quartile design practices, which includes having a clear design strategy, saw 32% higher revenue growth and 56% higher total returns to shareholders than their counterparts [1]. DesignRush's analysis found that design-driven companies outperformed the S&P 500 by 228% over a ten-year period [2]. These numbers aren't about prettier interfaces. They're about design operating as a strategic function connected to business outcomes.
The question worth asking isn't whether strategy matters. It's what a design strategy actually is, practically, and how you build one when your organisation hasn't asked for it.
What a Design Strategy Actually Is
Let me clear out the things it gets confused with first.
A design strategy is not a BRD. Not an SRS. Not a project plan with Gantt charts. Not a sprint retrospective. Not a business plan given a design-sounding name. If you've seen a document called "design strategy" that was really just a timeline with milestones and a few persona slides, someone mislabelled their project plan.
A design strategy is a plan that defines how design will help achieve business goals while meeting user needs. It's the decision-making structure that tells your design team what to prioritise, why those things matter, and how success will be measured [3].
Tim Graf, writing the UX Strategy Blueprint in 2026, put it sharply: "If your design work is entirely dictated by a product roadmap you had no hand in creating, you do not have a strategy" [4]. That line should sting a little cos it describes most design teams in India. The PM creates the roadmap, the designers execute it, and everyone calls the output "design." That's delivery. Delivery without direction is just labour.
Jaime Levy, who literally wrote the book on UX strategy, breaks it into four pillars: business strategy (what's the company trying to achieve), value innovation (how do we solve user problems in ways competitors don't), validated user research (proof that our assumptions are right), and killer UX design (execution that brings the strategy to life) [5].
Notice how three of the four pillars have nothing to do with screens. Business understanding, competitive differentiation, research validation. The actual interface design is one quarter of the strategy. Most design teams spend 90% of their time on that one quarter and zero time on the other three.
What a Finished Strategy Looks Like
A design strategy should be a document, not a deck buried in someone's laptop. Practically, it covers:
Business context.What is the business trying to achieve this quarter, this year, this cycle? Revenue targets, market expansion goals, partnership objectives, retention targets. You need to know this cos every design decision you make should connect back to it. If you can't draw a line from your design work to a business outcome, you're decorating.
User understanding.Who are the users, what do they need, what evidence do you have that those needs are real? Not personas invented in a workshop. Actual research findings, support ticket patterns, behavioural data, interview insights. If you don't have this data, the strategy includes a plan for getting it.
Current state assessment.Where is the product right now? What's working, what's broken, what's the gap between where you are and where the business needs to be? This includes design maturity assessment. How does the organisation currently treat design, and what needs to change for design to deliver its full value?
Design principles for this project.What rules will guide design decisions? These aren't generic ("make it simple"). They're specific to this context. "In this product, speed of task completion matters more than visual polish cos our users are processing 200 orders per day." Specific principles prevent every review meeting from becoming a taste debate.
Research plan.What do you still need to learn, what methods will you use, how deep do you need to go? This is where knowing the project's risk level matters. A regulatory compliance project needs deeper research than a minor UI refresh. Over-researching a low-risk feature wastes time. Under-researching a high-risk one costs more.
Implementation plan. How will the design work get done, in what sequence, with what dependencies on engineering, content, and other teams? Timelines, collaboration touchpoints, review cadences.
Success metrics. How will you know the design strategy worked? Specific, measurable outcomes tied to the business objectives from the first section. Retention improved by X%. Task completion time decreased by Y%. Support tickets for this flow dropped by Z%.
Governance. Who reviews design decisions, at what cadence, and who has final say on direction changes? Without governance, the strategy drifts the moment a senior stakeholder has a new idea in the shower.
That's a strategy. Compare it to what most design teams operate with, which is a Jira backlog of tickets created by the PM with "design review" checkboxes.
"My Organisation Would Never Let Me Build This"
Fair. And also, this is the part where I push back.
Tim Graf's research found that "you cannot skip levels of UX maturity. If your organisation is at stage 1, writing a five-year strategic plan is a waste of energy" [4]. He's right. If your organisation doesn't understand what design does, presenting a 15-page strategy document will confuse people, not convert them.
But NNGroup's research found that the most common challenges for design teams were "lack of UX vision and strategy, confusion about what UX strategy actually is, and too much focus on business needs at the expense of users" [4]. The teams that struggle most are the ones that have no strategy at all.
So the question becomes: how do you build one when nobody asked for it?
Start small. You don't walk into a Monday standup and announce "I've created our design strategy." You build it in pieces, each piece proving its value before you introduce the next.
First piece: connect one design decision to one business metric. The PM credit blog covered this through the five shifts. Declare a target at kickoff. "This redesign targets a 15% reduction in checkout abandonment." Measure the result. Report it publicly. That one connection, design decision to business metric, is the seed of strategic thinking. It's small enough that nobody needs to approve it. And once you've done it three times, people start expecting it.
Second piece: write a one-page problem statement before you open Figma. What's the business objective? Who's affected? What evidence exists? What's the cost of not solving it? This is the 4-component problem framework we published in the problem-solving blog. A one-page problem statement, shared with the team before design begins, is strategy at its most fundamental level. It says: we know what we're solving and why.
Third piece: propose a research plan proportional to the risk. Not every project needs two weeks of user research. Some need three days. Some need zero, the data already exists. The judgment of how much research this specific project needs, based on its risk, its novelty, and its stakes, is strategic thinking. It's also what separates a senior designer from a mid-level one. We wrote about reading risk in the context of evaluative vs exploratory design approaches where matching depth to risk is the core skill.
Fourth piece: present outcomes, not artefacts. When you share your work, don't present screens. Present: the problem you identified, the approach you took, the reasoning behind your decisions, and the outcome you're targeting or have measured. This is what the career ladder breakdown describes as the difference between mid-level and senior presentation. Mid-level shows what they made. Senior shows why it matters.
Each piece is individually small. Nobody needs to approve a problem statement or a success metric. But after six months of consistently connecting design work to business outcomes, proposing research proportional to risk, and presenting outcomes instead of artefacts, you've built the foundation of a design strategy without anyone giving you permission.
Strategy as a Maturity Lever
There's a metaphor I use with designers that's specific enough to land in India. You can put jaggery in milk, but if you don't stir it, the sweetness stays at the bottom and the top tastes the same as before. Having the right ingredients doesn't change anything without the work of integration.
Strategy in a low-maturity org works the same way. You can write the best strategy document in the world, and if the organisation doesn't have the governance, the culture, or the leadership to integrate it into how decisions get made, it sits in a Google Drive folder getting stale.
Building a strategy doesn't automatically increase design maturity. But the act of building it, the conversations it forces, the connections it creates between design and business, the visibility it generates, those things do increase maturity. Not the document. The process of creating it.
When you sit with business stakeholders to understand their objectives, you build a relationship that didn't exist before. When you propose research based on project risk, you demonstrate judgment. When you report outcomes tied to business metrics, you build credibility. Each of these interactions raises design's visibility and influence in the organisation by one small increment. Over time, those increments compound.
This is why design leaders who actually lead, the ones we wrote about in Design Leadership Is in Turmoil, are the ones who build strategy as a practice. They're not waiting for the org to mature. They're using strategy as the mechanism through which maturity happens.
When Strategy Meets Confidence
One challenge that even experienced strategists face: how do you know if your strategy is good enough to act on?
You've done the research, talked to stakeholders, mapped the business objectives, defined the principles. But that nagging question remains. Is this direction solid? Did you go deep enough? Did you talk to the right people? Is there a blind spot you can't see?
There's an upcoming tool called Konfomthat's tackling this exact gap. It scores how much confidence a direction has earned before you build, based on the work actually done: whether the decision is clearly framed, whether the stakes are properly sized, whether evidence has been gathered proportional to the risk, and whether the right stakeholders have weighed in. Instead of a gut feeling about whether the strategy is ready, it gives a visible score that shows where the direction is strong and where it's still thin.
The insight behind it is one I've seen play out across hundreds of projects: the frameworks tell you what to do. They never tell you how much is enough for this specific project. That judgment gap is where most strategies either over-invest or under-prepare. Konfom is currently in early access, free for the first 100 members.
What Changes When You Have a Strategy
The difference between a designer with a strategy and a designer without one is visible in every meeting, every review, every stakeholder conversation.
Without strategy, you're reactive. The PM sets direction, you execute. Stakeholders give feedback, you incorporate. Leadership changes priorities, you pivot. Your value is measured in speed and output volume. You're a production function.
With strategy, you're proactive. You defined the problem before the PM wrote the brief. You proposed the research plan. You set the success metric. You connected the design work to a business outcome that leadership cares about. When stakeholders give feedback, you have principles to evaluate it against. When priorities change, you can articulate what that change costs. Your value is measured in outcomes, not output.
That shift, from production function to strategic contributor, is the same shift the PM credit blog describes from the credit perspective and the workshop facilitation blog describes from the leadership perspective. Strategy is the underlying capability that makes all of it work.
If you want help building this capability, whether you're a designer trying to create your first strategy or a design leader trying to embed strategic practice across your team, that's what our mentorship programs and team training are built around. Book a strategy call. The irony of using a strategy call to talk about building strategy isn't lost on me.
Free Resource: Design Strategy Planning Tool
We built an AI-powered tool that walks you through building a design strategy step by step, with prompts for each section, examples from real projects, and templates you can customise.
Design Strategy Planning Tool
An AI-powered tool that walks you through building a design strategy step by step, with prompts for each section, examples from real projects, and templates you can customise.
No spam. The tool opens right after.
Sources & References
- [1] McKinsey & Company. (2018). "The Business Value of Design." 300 companies tracked over 5 years. Top-quartile MDI scorers saw 32% higher revenue growth and 56% higher TRS. mckinsey.com
- [2] DesignRush. (2025). "Design-Driven Companies Outperform the S&P 500 by 228%." Comprehensive analysis of design ROI data. designrush.com
- [3] UXPin. (2026). "Design Strategy: A Practical Framework for UX Leaders." uxpin.com
- [4] Graf, T. (2026). "The UX Strategy Blueprint: A Practical Framework for Building, Communicating, and Executing Design Strategy That Drives Product Outcomes." Including NNGroup research on UX strategy challenges. timgraf.com
- [5] Levy, J. (2015, updated). "UX Strategy: Product Strategy Techniques for Devising Innovative Digital Solutions." O'Reilly. Four pillars: business strategy, value innovation, validated user research, killer UX design.
- [6] Monday.com. (2026). "Design Strategy Explained: Essential Frameworks and Execution Tips for 2026." monday.com
Further Reading on Xperience Wave
- Why Product Managers Get Credit for Your Design Work (And What You Can Do About It)
- You Solved Exactly What You Were Asked to Solve. That's the Problem.
- She Shipped Three Times While He Was Still Researching. They're Both Right. That's the Problem.
- Design Leadership Is in Turmoil. And No One's Talking About It.
- Junior to CXO: What Each Level of the UX Career Ladder Actually Demands in India
- How to Facilitate a Design Workshop When Everyone in the Room Knows More Than You
About the Author
Shaik Murad is Co-founder and Head of Product & Design at Xperience Wave, a UX design studio based in Bangalore, working across designer mentorship, UX services for businesses, and a design community of 1,370+ designers.
- Murad, Co-founder & Head of Product & Design, Xperience Wave
