From Pixels to Profit: Proving Design’s Business

You redesigned the onboarding flow. It’s clearer, faster, and no longer feels like filing taxes inside an escape room.

The team loves it. The stakeholders approve it. Someone drops a fire emoji in Slack.

Then leadership asks, “What did this actually do for the business?” And suddenly, “the hierarchy is much stronger” feels a little underdressed for the meeting.

Design can improve revenue, reduce operating costs, and help teams avoid expensive mistakes. But explaining that value takes more than a beautiful before-and-after. You need a credible connection between what changed, how it affected people, and why the business should care.

That connection starts before you open Figma.

Start with the business problem hiding inside the design request

“Redesign the dashboard” is a request. It tells you very little about the problem worth solving.

Are customers missing important actions? Is the support team explaining the same feature repeatedly? Are prospects struggling to understand the product during demos?

Each answer leads to different design decisions—and different ways to evaluate them.

Before starting, ask:

• What is happening that we want to change?
• Who is affected, and how?
• What does that behavior cost the business?
• What evidence would tell us we improved it?

You don’t need a spreadsheet that predicts revenue to the penny. You need an agreed-upon reason for doing the work.

If nobody can explain what success looks like, you’re about to spend several weeks designing toward “we’ll know it when we see it.”

Historically, a destination with terrible parking.

Build a chain you can actually defend

Business value becomes easier to explain when you connect a design decision to a user behavior and then to a business outcome.

For example:

Clearer setup instructions → more customers complete setup → more customers reach the product’s useful features → potentially better paid conversion.

Notice the word potentially. Improving setup doesn’t automatically increase revenue. Pricing, product fit, acquisition quality, and plenty of other factors still exist. Annoying, but true.

Your job is to identify which links you can measure and where your assumptions need testing.

For an onboarding project, that might mean tracking completion, time to first meaningful action, and eventual paid conversion separately. If completion improves but conversion doesn’t, you’ve learned something useful: the next obstacle may be beyond onboarding. A credible explanation leaves room for that possibility.

Pick a few measures that answer the question

You don’t need twenty-seven metrics. You need a small set that helps you decide whether the work succeeded.

For most projects, I’d look for three things:

• A user measure: Can people complete the task accurately, with reasonable effort?
• A business measure: Did conversion, support demand, retention, or another relevant outcome change?
• A guardrail: Did the improvement create a problem somewhere else?

Suppose you simplify an account-opening process. More completed applications might look like success—until you discover that errors and downstream rework also increased.

The guardrail keeps you from celebrating a problem you’ve relocated.

Choose measures that fit the project. A billing redesign and a component-library cleanup shouldn’t have identical scorecards simply because someone made a template.

Get the “before” before it disappears.

It is remarkably difficult to prove improvement when your baseline is “everyone remembers it being pretty bad.”

Before changing the experience, capture what you reasonably can: task completion, error rates, support contacts, abandonment, or time spent on a workflow.  Document how the measure is defined. “Active user” can mean three different things in one meeting, and all three people will sound confident.

If analytics are limited, start smaller. Review support tickets. Observe people completing the task. Run a structured usability study. Be clear about what that evidence can establish. Finding fewer usability problems in testing supports a usability claim. It does not, by itself, establish an increase in revenue.

Limited evidence can still be useful. Inflated evidence becomes a credibility problem.

Be honest about what caused the change.

You launch the redesign. Conversion rises. Excellent.

Marketing also changed the campaign, sales introduced a discount, and engineering cut load times. Less excellent for your tidy attribution slide.

When feasible, work with product, engineering, and analytics partners to test changes in a way that helps isolate their effects. When that isn’t possible, explain the limitations of a before-and-after comparison.

“The redesign contributed to an improved onboarding experience during a period when activation increased” may be more defensible than “Design increased activation by 18%.”

Use the strongest claim your evidence supports.  Sharing credit doesn’t weaken your contribution. It shows that you understand how products actually improve.

Count the value that never reaches a checkout button.

Some design work creates value by making delivery more efficient or preventing avoidable rework.

A well-used design system can reduce repeated decisions. Early testing can reveal that a proposed feature solves the wrong problem. Clearer handoffs can reduce clarification loops during implementation.

Make those benefits concrete.

If you’re evaluating a design system, examine comparable work, adoption, implementation effort, and maintenance costs. A library of unused components has very limited economic powers. Also distinguish capacity from cash savings. Saving people time may let them support more customers or deliver other work. It doesn’t automatically reduce payroll expenses.

And when research stops a weak idea, document the decision and the planned work it changed. You can explain the avoided commitment without inventing an alternate universe where you know exactly how much the failure would have cost.

Tell the story leadership needs to hear.

A useful impact update should explain:

The problem. What changed. What happened. How confident we are. What we should do next.

Keep the artifacts available, but lead with the outcome. Instead of opening with the twelve screens your team redesigned, explain that customers were getting stuck during setup, what you changed to address it, and what the evidence now shows. If results are mixed, say so. “Completion improved, but support demand stayed flat” gives the team a clear next question to investigate.

Proving design’s value means making your contribution understandable and your reasoning trustworthy.

The fire emoji can stay.  It just shouldn’t be your primary KPI.