Designers shouldn't outsource the definition of success. But I see it happen all the time, and most designers don't understand why.
Here's the pattern I see in my coaching and client work sessions. Designers get handed a business goal they had no part in defining, and then they get judged against it. It's a trap. The best design problems have a business goal to map to, and the fix is refusing to let anyone else define your success by their own lack of clarity.
The pressure on design keeps climbing. More output, plus the slop sent downstream to "improve" some goal nobody clearly articulated. In my design leader coaching sessions, the conversations keep circling the same thing. Designers disenfranchised with the business, getting lost in the process, trying to work with stakeholders, and then overly focused on the sausage-making. That's a hard place to find satisfaction in the work.
I made an illustration in my recent LinkedIn post to talk through how I think about this, and I want to walk through it here.
Here are the patterns I see
A few patterns show up over and over.
Designers give business people more credit than they've earned, and retreat too fast when they can't solve the problem that day. That leader's confidence is often a thin, brittle veneer. The hesitation to push is really low confidence in front of authority. Don't back down, and don't forget that design is a problem-solving method too.
Designers come in the front door arguing for what users need, when the stakeholder is just trying to get something off their plate. You can't advocate for users until you've established the underlying pain the business is feeling.
Most business problems can be simplified. There's just no shared language to articulate them. When you can say "we want to attract new customers," then ask how many and by what means, the conversation turns into a partnership. Every one of these problems maps to a goal on the board: Growth, Retention, User Experience, Efficiency, Operations. That map is how the work becomes legible to the business.
Design operates blind. It underestimates what other groups need to make an idea happen, and it doesn't have its own data. So designers interpret watered-down, asymmetrical asks and let others attribute the results. Design needs its own data and its own way to structure arguments with it.
Business goals are a shared language
When we talk about what a business goal is, this comes directly from how we've defined it in Glare. Business goals are the levers a company pulls to create a better outcome. That outcome could be driven by marketing, by technical work, by improving operations.
Here's a list we've found useful to start the conversation. There's probably more, but these are good ones to start with.
- Growth: prove product fit, attract new customers, grow sales, gain market share
- Retention: keep customers, reduce churn, earn loyalty, increase spend
- User Experience: show value fast, drive adoption, improve customer satisfaction, prove launch success
- Efficiency: work faster, lower support costs, scale efficiently, fund what matters
- Operations: align strategy, lead with evidence, strengthen brand trust, prove design impact
Here's the thing I've found. When designers try to support the business, the business doesn't always know how to articulate these goals. So it behooves designers to look at this list and challenge the assumptions stakeholders are making. Are we trying to grow sales, or attract new customers? Those two answers have a material impact on the design choices inside a workflow.
If you're trying to grow sales, maybe you're being more articulate about who gets into the application and what they do once they're in. If you're trying to attract new customers, maybe you're at the top of the funnel and attention is what matters most. The onboarding experience changes pretty radically depending on which goal you're actually chasing.
Ask the stakeholder how they see it unfolding. What's the supporting mechanism? What channels are they using? Where are people coming from, and what landing pages drive them in? Having that context is what lets you do the work.
The mapping of design and business
We're not actually working on the business problem. It's not design's job to define the lever inside a business goal. What we can do is shape how users fit into it, and what users need from it.
Now, you could argue the business should be running generative research to figure out what users need, and I agree with that. But most business problems come from market research or competitors, so designers usually get handed the problem from that posture.
<iframe width="560" height="315" src="https://www.youtube.com/embed/FYNEbGm8KhI?si=E0zKAydDTnvnm7Sm" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
You're not going to move a business problem by starting with a user need the stakeholder doesn't care about. What you can do is translate the business goal into something that works on the user side.
That's what the mapping is for:
- User needs drive user outcomes
- Product outcomes are the experiential parts you can map to the application or the analytics
- Business outcomes are the business results, like more money per user or top-line revenue growth
The business doesn't care about the design result. It cares about the business result. So Design has to understand that its success gets dictated by a business result, and ultimately map back to it.
Show causal or correlative relationships between what design is doing and the business goal. That happens in the mapping of the design metrics and outcomes.
This won't be a clean one-to-one every time, and it doesn't have to be. It's a mapping, not a direct translation.
User needs, user outcomes, product outcomes, business outcomes, and business goals are a framework for creating alignment. They let people see that activities are happening at each level, and that something is driving the business result.
Design isn't a workflow group
Look at the workflows in a business: sales, marketing, product, engineering, strategy, operations, finance, legal. I purposely leave design off that list. Design is a co-partner across these functions, not another box in the row.
When design tries to build its own process to slot in next to these stakeholders, it usually ends up at odds with what the business is doing. The business has ninety other things to work on, so it sees design as an output to drop into someone's plan. That doesn't work. Design creates value by working holistically across these functions, but designers won't get invited into that conversation until they clearly show they care about the business problem and can surface where design helps.
That's the loop. Design helps achieve business goals by improving user outcomes. The experiences users are sometimes desperate to get from a product or service. Design won't always make things better or differentiate the product. Sometimes just having the function, or having a technical solution, is enough. So design has to articulate where it's actually creating value. Otherwise it loses credibility.
When design and product leads come to me, the breakdown is usually right here. The business hasn't fully articulated what it's trying to do, and there's no mapping back to what design is trying to accomplish. When that alignment doesn't exist, design is always chasing its tail on problems that might be irrational. Timelines get unrealistic. The ability to measure what design contributes gets lost, because nobody considered how design was supposed to move the business goal in the first place.
Connecting design outcomes to business outcomes
We ran a Q&A with Sol Mesz on the Glare forum that lines up closely with this, coming at it from the metrics side. Her framing is worth reading in full, but one distinction stuck with me.
In many organizations, design teams measure things like usability scores, task success rate, error rate, speed, satisfaction. In other words, they focus on experience quality, while leadership is making decisions based on revenue, growth, risk, or efficiency. So the missing part (and the biggest challenge) is connecting how the quality of the experience impacts the business.
...When designers make that causal chain explicit, the conversation changes. Design stops being defended on taste, craft, or good intentions, and starts being discussed in terms of impact.
— Sol Mesz, Is design building value or just burning budget?
That causal chain is the mapping. Sol's point about tracing the origin of an initiative, whether it came from data, a customer complaint, sales friction, or an executive bet, is another way to find the goal on the board when nobody has named it out loud. Worth reading the whole thread.
What I'd tell design
Stop letting other groups define what your success looks like. Name the goal, map the work to it, and hold that line.
Design is a method, a function, and a deliverable all at once. It's broad like that, and there's no better time to be a designer. It comes down to getting these parts right in ways that support the business. The designers who can do this see measurable success, in the business and in their own contributions.
Curious what you're feeling on this. Come find the thread on the Glare forum and let me know.
