Is design building value or just burning budget? (Q&A)

[Bryan]

Today we’re digging into @Sol_Mesz’s article, Design: cost, expense or investment? Her observation is that design can be treated in one of three ways inside a company: as a cost, an expense, or an investment. That label matters because it shapes influence, budget decisions, and whether design is seen as strategic or optional

She explains how design is classified, which usually comes down to the business model, accounting practices, and the product team’s structure. Product-driven companies are more likely to treat design as a cost tied to building value. Service and consulting organizations often treat it as an expense that supports operations.

You can think about design like this:

• If design is treated as a cost, designers need to show how their work drives revenue, retention, and product value. Design becomes a strategic investment.

• If design is treated as an expense, designers need to show how their work improves efficiency, reduces waste, and lowers operational effort.

Let’s jump into the discussion

You argue that leaders should not waste energy debating labels. What matters is understanding how your organization already sees design and communicating value in terms it recognizes.

Here’s the question that many see as their main challenge: I see many leaders wanting to earn influence by tying design work to outcomes. At the same time, many still rely on taste, craft, or good intentions alone.

What do you believe needs to change for design to make that shift?

Let’s dig into creating design with Sol Mesz, a featured Helio author who writes about creating value through design.

[Bryan]

Excited to jump into these topics Sol, thanks for joining me. These ideas and concepts are super important to product and design.

[sol_mesz]

I think design leaders need to become much more aware of the difference between design outcomes and business outcomes.

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.

Let me give you an example: I was recently working with a Design team in the car insurance industry. They were doing a great job at improving page speed and reducing form errors in the quote flow. From a UX standpoint, everything looked better. But the metric that really mattered to the business wasn’t speed or errors — it was conversion from quote to signed contract. Until the team connected their design output to that metric, design improvements were not perceived as value creation (investment) but as design tweaking (cost).

That’s why differentiating design outcomes from business outcomes is crucial: speed and error rate matter because they influence quote completion, drop-off, and ultimately revenue. 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.

And that’s how design earns influence: by showing, in the organization’s own terms, how the experience (and the design decisions that lead to it) move the numbers that leadership already cares about.

[Bryan]

@sol_mesz

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.

Agreed. We need to think about how these metrics are mapped, with leading and lagging indicators. That’s how we want to help people in Glare.

Here’s my next question. When design is treated as an expense, it creates a very different set of expectations. I’d argue this is the default for most design teams today, and it makes it much harder to show design impact.

In that model, however, you recommend that designers justify their work by demonstrating that it improves efficiency, reduces waste, or lowers operational effort. How should teams start to think about this?

[sol_mesz]

The first thing designers need to do is understand what actually matters to the business in that specific moment. Expectations can be different depending on the company’s product and context.

For example, in a growth phase, metrics like conversion, activation, or expansion might matter most. In a more mature or regulated business, reducing drop-off in critical flows, increasing self-service adoption, or lowering customer support contact rates can be far more valuable. The key is that designers need to understand which outcomes leadership is trying to move right now and connect their work to those outcomes.

The metrics mentioned above are outward-looking metrics, tied to how the product performs in the market. These change with the company’s stage and goals.

The second category is inward-looking metrics, which tend to matter regardless of stage because they affect the organization’s ability to operate efficiently. For example, design decisions that reduce the number of edge cases, simplify flows, standardize components, or prevent errors don’t just improve the user experience — they reduce engineering time (and therefore costs), customer support load, compliance risk, and internal processes. That’s real, measurable value.

In short, teams should focus on making their contribution legible. When designers can show that their work either improves market outcomes or lowers operational effort — ideally both — design stops being seen as a discretionary expense and starts being recognized as a lever for value and efficiency.

That’s often the fastest path to credibility: speaking directly to what the business is trying to protect, optimize, or sustain.

[Bryan]

@sol_mesz

For example, in a growth phase, metrics like conversion, activation, or expansion might matter most. In a more mature or regulated business, reducing drop-off in critical flows, increasing self-service adoption, or lowering customer support contact rates can be far more valuable. The key is that designers need to understand which outcomes leadership is trying to move right now and connect their work to those outcomes.

Love this. A business is always in flux. So you’re saying it’s the designer’s responsibility to interpret the problem they’re solving. I really like the outward and inward definitions. They make a lot of sense.

Peter Drucker famously defined a company’s purpose as creating and keeping a customer, which lines up well with this thinking. It keeps things simple. Once you’ve earned a customer, the goal is to solve their problems efficiently.

In Glare, we’ve grouped business goals into categories, but I really like these two rollups.

In many ways, business goals are open and loosely defined. The ways companies win and keep customers are rarely as straightforward as some designers expect, which creates a lot of creative overlap and ambiguity.

How do you recommend designers find that overlap with stakeholders and executives who are focused on protecting the bottom line?

[sol_mesz]

In most organizations, goals and metrics are often directional rather than precise: “increase sales/conversion”, “growth”, “reduce customer care costs”, “be more efficient”. Is the reality designers are operating in.

When metrics are unclear or only directional, designers shouldn’t wait for perfect definitions — they should work with the signals that already exist and help sharpen them through action.

The first step is to infer metric hypotheses from existing evidence. The organization is always signaling priorities somewhere. What product metrics does the team already track, even informally? What shows up repeatedly on the roadmap? What has leadership emphasized in recent all-hands or reviews? What did product, sales, or marketing recently ask for? From those signals, designers can form a working hypothesis — for example, “It looks like acquisition is the priority right now, because most initiatives are focused on new users.”

Designers could also ask focused, directional questions instead of open-ended ones. Asking “what’s the metric?” often leads to generic answers. More useful questions are: What change do you expect to see after this ships? How would we know this helped? These questions don’t require perfect clarity, but help reveal which metrics actually matter.

Another way to reduce ambiguity is to trace the origin of the initiative. Was this driven by data, by customer complaints, by sales friction, or by an executive bet? Understanding where a feature or project came from often reveals the implicit metric behind it — even if no one named it explicitly.

And when there truly is no defined metric, designers can propose one. Not a full measurement framework, just a minimal one: what problem we’re solving, for whom, what behavior we want to change, and what observable result would indicate progress. This opens the conversation by giving stakeholders something concrete to react to.

These are a few examples that show how designers can reduce ambiguity around metrics: not by demanding precision upfront, but by making assumptions explicit, and refining them together with stakeholders. That’s often enough to align design work with the bottom line — even when the goals start out vague.

[Bryan]

@sol_mesz

Another way to reduce ambiguity is to trace the origin of the initiative. Was this driven by data, by customer complaints, by sales friction, or by an executive bet? Understanding where a feature or project came from often reveals the implicit metric behind it — even if no one named it explicitly.

Yes, this makes so much sense. We have to understand the needs of the people and teams involved in these design initiatives. It’s not enough to look only at users. There are systems in place that support them, many of which go beyond direct interaction with customers.

We encourage designers to think about the systems and processes that sit behind their projects and shape the user outcomes.

This can be challenging and create doubt for many designers. The imposter syndrome takes over. Do you have suggestions or ideas for starting the process, especially when these other groups may not completely understand why a designer wants to understand their role and goals?

[sol_mesz]

There are two ways designers can get this process started: the first one is by using what I call “the magic word”: why. The other one is by taking a systems view. And both should be used together.

Let’s start with the magic word: why. This “why” is shorthand for what problem are we trying to solve, and for whom. Understanding the why behind a request is essential to delivering value. If you don’t know why you’re building something, or what problem it’s meant to address, it becomes very hard to know whether design actually made an impact.

Now… when asking “why,” be careful not to sound defensive or confrontational. The intent is to open a space for discovery and understanding, to start a conversation that generates insight. Approached with curiosity, this question helps uncover the context and dynamics behind a request, surface implicit assumptions, and understand the systems and teams affected by design decisions. That understanding is what allows design to connect decisions to outcomes, especially in complex organizations where impact isn’t always visible on the surface.

Along with the why, a systems view is also needed. As you mention, products sit inside larger systems made up of processes, teams, tools, and constraints, and those systems shape the user experience as much as the interface does. Designers can add a lot of value by making those systems visible.

In practice, this means expanding the definition of “who we’re designing for.” Sometimes the primary user is a customer. Other times it’s a support agent, a compliance team, or an internal operator who has to deal with the consequences of a broken experience. When designers take those actors into account, they naturally uncover clearer metrics — effort, rework, cycle time — that connect design decisions to business outcomes.

Taking a systems view and grounding their work in how the organization actually functions is another great way to deliver value and earn credibility.

[Bryan]

@sol_mesz

There are two ways designers can get this process started: the first one is by using what I call “the magic word”: why. The other one is by taking a systems view. And both should be used together.

Haha, this immediately made me think of my kids in kindergarten. Five rounds of “why,” then suddenly they figured out how to use cuteness as a negotiation tactic.

Jokes aside, this is spot on. It’s simple and it works.

As systems get more complex, with AI agents and people making decisions together, many of the things a designer is asking “why” about are no longer visible. They’re buried in skill logic, automation rules, or training data. That’s where things start to get bumpy.

We’re heading into a stretch where humans and agents constantly collide in decision-making. And it raises a real question: who is the designer actually working with now?

My main question is how designers turn this into a clear value exchange for the business. As systems get more abstract, efficiency becomes harder to point to. How do you sell the value of the work in that environment? Judgement is a key value add.

[sol_mesz]

First, a clarification: asking why in this context is not the same as the “5 Whys.” This isn’t a root-cause analysis technique meant to drill down mechanically. It’s a framing device to understand what problem needs to be solved, for whom, and within which constraints. The goal isn’t to converge on a single cause, but to surface intent, assumptions, and trade-offs.

Having said that, when AI takes care of efficiency, judgement becomes one of the key drivers of value for designers.

With products that use AI, judgment helps you decide what the AI should and shouldn’t do, how to handle failure modes, what context the AI actually needs, how and when human agency is needed, setting appropriate confidence thresholds, building confidence in the system for users.

Typical judgement questions when adding IA to a product or process: should the system auto-approve this loan or flag it for a human? Should it generate that email draft or ask clarifying questions first? Should it handle routine customer inquiries or escalate anything ambiguous?

But judgment doesn’t stop there. Judgement is needed throughout the whole process:

• On the business and strategy side judgement is needed to decide what (and what not) to build. When building is cheap, it is easier than ever to build something nobody wants.

• On the product side: judgement is needed to understand or help clarify what problem the team is solving (or should be solving). Your stakeholders might say “we need an AI agent to handle customer inquiries,” but a designer asking why might surface that the real problem is inconsistent information across your support team, or that your FAQ is broken. That judgment call—“we’re solving the wrong problem”—can redirect the entire project and save the business from building the wrong thing.

• On the systemic side: judgement is about mapping dependencies and saying “this won’t work unless we bring compliance in early and redesign their review process.” That’s not about the interface—it’s about the system’s actual viability.

• On the metrics side: judgment is about defining metrics that align with the actual value you want to create. Teams often default to “AI automation rate” or “time saved,” but a designer might push back: “If we measure success that way, we’ll optimize for quantity over accuracy, and we’ll miss that support agents are being set up to fail.”

• On the operational side: judgment is identifying whether you have the right people in the room. Maybe you need ops in the design phase, not at launch. A designer’s judgment here is about flagging when critical perspectives are missing.

These judgment calls are about whether the project is set up to actually succeed—and that’s how designers add value across the whole spectrum.

[Bryan]

This has been a really insightful exchange @sol_mesz. I really appreciate you sharing your thoughts on how product and design teams can create more value with their work. Thank you!

[nathaliesmith]

Sol, this thread is gold. From the Operational side, this totally resonated with me “judgment is identifying whether you have the right people in the room.” We see this over and over again, saying the right thing, but to the wrong people or at the wrong time.

I have so many strong things to callout from this discussion, going to dive in further but wanted to thank you for bringing the heat here!

[sol_mesz]

So glad it resonated with your day to day and that you could extract value from the ideas we discussed

[MoData]

Great article @sol_mesz! How do you think researchers should approach this same cost vs expense positioning? Something we struggle with in client orgs is that ‘research’ is often viewed as a cost (which is the reason we’ve strayed away from that term altogether).

[EricZ]

@sol_mesz

Another way to reduce ambiguity is to trace the origin of the initiative. Was this driven by data, by customer complaints, by sales friction, or by an executive bet? Understanding where a feature or project came from often reveals the implicit metric behind it — even if no one named it explicitly.

And when there truly is no defined metric, designers can propose one.

Really love this framing, it’s important to actively engage and advocate for what you need to be successful.

That said, I’m curious if you have examples of building trust to gather these goals and metrics when initiatives are defined? Who are the key stakeholders?

[sol_mesz]

Hi Morgan,

I think research is one of the disciplines that most needs (and most benefits from) being explicitly connected to business outcomes.

A common pattern I see is that researchers feel they’ve produced thoughtful, rigorous reports full of valuable insights, while business stakeholders feel those reports are not very actionable. As a result, the research ends up in a (real or virtual) drawer. And when that happens repeatedly, research naturally gets framed as a cost rather than a lever for value.

Most of the times the issue isn’t the quality of the research itself, but how insights are framed. Many research outputs do an excellent job describing user problems, but stop short of making explicit how those problems impact the business. When that link is missing, it’s hard for decision-makers to understand which insights are valuable and why acting on an insight matters now.

One of the golden rules that I teach in my Product Design course is that user problems are always business problems. That should be your mantra when writing and communicating research insights.

What you want to communicate is not what is happening to users, but what happens to the business if this remains unresolved — conversion, retention, support load, risk, revenue, trust.

That shift alone goes a long way toward repositioning research from “cost” to “decision support.”

To help teams translate user problems into business impact I created a tool called “Insights Template”. Its purpose is to force that connection: from user signal → implication → business impact. You can find more details here: Insights template – Sol Mesz / Make better product decisions

Small note: the template has evolved quite a bit since I first published it, and I’m currently working on a V2. Happy to share once it’s out

[sol_mesz]

Hi Eric,

the way I navigate this problem is by identifying a few possible product/business outcome metrics for the project and then validating them with the stakeholder. This way of working adds value and credibility in two ways:

• First, it brings a product+business+metrics mindset into the design process. Instead of waiting for goals to be perfectly defined, I’m actively helping clarify what success might look like and how it could be observed or measured.
• Second, this approach shows stakeholders that I don’t just make “pretty screens”, but that the visual output comes after understanding the business problem (not just the user problem), the constraints, and the metrics the business is trying to move. The screens are a consequence of that thinking, not the starting point.

When you start designing “business first” stakeholders realize that you are a partner rather than just a provider.

Quick example

I was recently working with a team tasked with redesigning the rewards page of a retailer’s loyalty program. The original ask was: “improve the way prices are searched for and displayed.”

But before laying a single pixel on the screen, I asked the team to step back and ask a more fundamental question: what is the purpose of the rewards program? The answer was obvious: loyalty.

That reframing immediately changed the nature of the project. The goal was no longer to make the page look better, but to support loyalty. So the next question becomes: what does loyalty actually look like?

Loyalty means customers choosing this retailer over other alternatives. But since we can’t know where a customer would have purchased otherwise, we needed proxy metrics. In this case, the most relevant ones were customers buying more frequently and buying more items per purchase.

Once the team aligned on that, it became clear the rewards page wasn’t the real problem. The real issue was helping customers see the benefit of buying on this retailer vs somewhere else. So the challenge wasn’t designing a better rewards page, but showing users in the shopping flow how many points each product (and the full cart) would earn them to incentivize purchasing on this site vs the competition.

The shift from a design-first to a business-first perspective, completely changed where design created value and moved the project from designing screens to creating value for the business.

[EricZ]

@sol_mesz

Once the team aligned on that, it became clear the rewards page wasn’t the real problem. The real issue was helping customers see the benefit of buying on this retailer vs somewhere else. So the challenge wasn’t designing a better rewards page, but showing users in the shopping flow how many points each product (and the full cart) would earn them to incentivize purchasing on this site vs the competition.

Fantastic that you provided an example, and completely agree. In my experience, it’s on the designer to define the metrics as often the stakeholders will have high level business goals that aren’t directly applicable, or will simply be working from their brief.

Do you have a process of deduction for arriving at metrics? Or do you have resources you rely on?

[MoData]

This is something I see all the time too:

“A common pattern I see is that researchers feel they’ve produced thoughtful, rigorous reports full of valuable insights, while business stakeholders feel those reports are not very actionable. As a result, the research ends up in a (real or virtual) drawer. And when that happens repeatedly, research naturally gets framed as a cost rather than a lever for value.

Good research often gets forgotten because teams can’t act on it clearly or quickly enough.

We’re currently working with one of our long time clients to tighten the loop between research > design > production. We’ve had great success launching new features in their product, but it’s only a fraction of the total opportunities we’ve surfaced for them through user testing.

“What you want to communicate is not what is happening to users, but what happens to the business if this remains unresolved — conversion, retention, support load, risk, revenue, trust.”

Exactly this ^ is what we think is going to help us establish these tight loops, so that the research signals we surface are closely tied to business outcomes every time.

Love the template, looking forward to see V2 when it’s ready!