Steakholders vs. redesign: how to convince with numbers, not aesthetics

"I like the way it is now." "Users are used to it." “Why touch what works?” "We don't have time for that right now.".

These are not stupid objections. This is the rational behavior of people who are responsible for the outcome and see little reason to take risks.

The problem isn’t that stakeholders “don’t understand design.” The problem is that the designer speaks the language of design, and the stakeholders think in the language of business. Translation is the designer's job.

## Why Stakeholders Resist Redesign

To understand the mechanics of resistance is to learn to work with it.

### Fear of an unknown outcome

“We now have 4% conversion rate. After the redesign will be... “unknown”. The unknown is more frightening than the bad known result. It's basic psychology.

**It helps to reduce the uncertainty. Data from past redesigns, A/B test instead of full launch, phased rollout.

### The cost of change is visible immediately, the benefit - then

The redesign takes team time right now. Results will come in 3-6 months. It's bad timing for decisions.

**How to calculate the cost of inaction. If we do not redesign, we continue to lose X rubles a month. In 6 months it's Y - more than the redesign costs.

### Past negative experiences

We have already done a redesign in 2021. Nothing special.” Perhaps the previous redesign wasn't measured correctly. Or not based on the data. Or it really didn't work.

**What helps: * Show how this redesign differs from the past. Specific data issues, measurable goals, and a plan to verify the outcome.

### "What matters to us now is something else."

Competition for resources is always there. The redesign competes during development with new features.

** Which helps:** ROI comparison. Adding a new feature will bring X in a year. Onboarding redesign with current data will bring Y. What's the priority

## The Architecture of a Persuasive Argument

### Start with the problem, not the solution

A typical mistake is, “I want to remake onboarding.” Stakeholder thinks, “Why, he works.”.

Right: We lose 42% of users in the third step of onboarding. And most of them are going away because they don’t understand. I want to fix it.”.

Now the stakeholder does not assess “whether a redesign is needed” – he already agrees that there is a problem and thinks “how to solve it.” That's another conversation.

### Add the price of the problem

The problem without price is abstraction. The problem with price is reality.

“42% of users leave onboarding. Of these, approximately 30% would reach the paying user in normal transit. With our traffic, that’s 150 lost paying users per month. At ARPU 800 ». – 120,000 ». per month or 1.44 million per year.

Now “onboarding redesign” is not about design. That's about 1.44 million a year.

### Offer a measurable goal, not just “do better”

"I want to improve onboarding" is an opinion. “I want to raise the pass of onboarding from 58% to 75% in 3 months” is the goal with the criterion of success.

Measurable goal reduces risk in the eyes of the stakeholders: they now know when a decision is considered successful (or not).

### Offer a plan with minimal risk

A complete redesign is the maximum risk. Lower risk options:

• A/B test of new solution against current
• Gradual rollout (first 10% of traffic, then more)
• Redesigning just one problem step, not the whole float
• Prototype and test with users before development

When the risk is reduced, consent is easier to obtain.

## Dealing with specific objections

### "Users are used to"

This is a real argument, but it works both ways. Users are used to a problematic interface, but that doesn’t mean they’re comfortable.

**Support data shows X calls per month on this topic – users are not used to it, they struggle with the problem every time. Here are the session records where you can see it.”.

Support data and session recordings are the best counterargument “users used to”.

### "We need to release the features first."

It's a competition for resources.

** Answer: ** I understand the priority. Here's a comparison: Feature X, we estimate, will bring Y users. Onboarding redesign with current data will bring back Z lost paying users. Here's the calculation. Which is more important from a business perspective

Don’t fight for priority – ask management to choose consciously.

### It's subjective - I like the current design

Aesthetics are subjective. No data.

** Answer: ** I understand that I like the visual version. I'm not suggesting changing it because it doesn't look like it. I suggest changing it because the data shows [a specific issue]. The visual result is an effect, not an end.”.

When a conversation goes from “like/dislike” to “works/doesn’t work,” you’re on a different level.

### "We have no data."

It's not a dead end.

**Response: ** I suggest we start by collecting data. I need [specific – set up a funnel in analytics / run 5 tests with users / put a feedback form]. It'll take [time]. Then we will have grounds to decide.”.

Sometimes the right step is not redesign, but diagnosis first.

## How to work with different types of stakeholders

### CEO/Owner

Thinking: money, risks, competitors, growth rate.

**Language: ROI, payback period, comparison with competitors, cost of inaction.

What catches: Our competitor X remade the onboarding 6 months ago. According to open data, their retention has increased. We use a similar scheme, we risk falling behind.”.

### CPO / Product

Thinks: metrics, roadmap, resources, priorities.

Language: Impact on key metrics, place in roadmap, expected effect on NSM.

**This directly affects the activation rate, which in our tree metric leads to retention. This is the calculation of the impact on the quarterly target.”.

### Head of Dev/CTO

Thinks: technical debt, complexity, development resources.

*Language: scope, technical debt, complexity of implementation.

** What catches you: ** This is not a rewriting from scratch. Specific Scope: [List]. Development evaluation: [hours]. And the bonus is that we'll also clear up the technical debt in this part.”.

## Document “Case for redesign”: a template

When you need a formal document for approval:

Problem
Data: [number-specific metrics]
Cost of problem: [in rubles or users per month]
Data source: [analytics/support/research]

Proposed decision
What we change: [specifically, not improving UX]
What NOT to change: [important to reduce anxiety]
Launch approach: [A/B/phased/full launch]

Expected outcome
Metric: [what we measure]
Objective: [Specific value]
Date: [when expected]
The pessimistic scenario: [what if the result is less]

Cost
Design: [clock]
Development: [hours]
Total: [Amount or time]

ROI
Upon achievement of the goal - financial effect: [calculation]
Payback period: [term]

Risks and Mitigation
Risk 1: [Description] → Mitigation: [How to reduce]

## AI and working with stakeholders: Prompts

### Prompt: Prepare an argument

I need to convince [CEO/CPO/CTO] of the need to redesign [what exactly].

The data I have:
[List]

The main objections I expect are:
[List]

Help:
1. Build a convincing argument in the language [the role of stakeholders]
2. Prepare responses to each expected objection
3. Offer a conversation format (length, structure, visuals)

### Prompt: Translate design arguments into business language

Here are my arguments for a redesign [that]:
[List of arguments written in design language]

Translate each argument into business language:
- Take down the design jargon.
- Add a financial or metric dimension where possible
- Formulate it as people would understand without a design background

### Prepare for a difficult conversation

I have to talk about the redesign with [the stakeholder description].

This person usually objected: [pattern description].
The previous attempts to convince him ended: [what happened].
What matters most to him in this context: [what you know].

What's the best way to build this conversation?
Offer: where to start, how to dose information, what questions to ask, what exactly not to say.

## When not to convince: an honest assessment of the situation

Not every redesign needs to be “sold” at all costs. Sometimes stakeholders are right in their resistance.

When it's worth stepping back:

• You do not have data that confirms the problem
• Redesign is based on the designer’s taste, not user insights
• Resources are needed for more important tasks right now
• Previous redesigns have not been measured and trust has not been built

An honest “let’s collect data first” is stronger than “trust me, I’m a designer.”.

## How to build trust of stakeholders: a long-term strategy

One-time persuasion is tactics. Continuous trust is a strategy.

### Show the results of small changes

Before you ask for a big redesign, show that small changes work. Fixed one screen → increased task completion rate → showed the numbers. Now the next conversation about a bigger change starts with "he proved his solutions work.".

### Switch to the language of metrics in everyday work

Don't expect big projects. In every retrospective, every synca, talk about design in numbers. Introduced onboarding tools – errors in the form decreased by 30%. It forms language.

### Ask for small “yes” before big ones

Consistency Psychology: A person who agrees with a small one more easily agrees with a large one. “Can I do 3 user interviews on this issue?” → interview result → “Can we do a new flow test?”

### Involve stakeholders in the process

Stakeholder, who participated in the formulation of the problem, attended 1 interview with the user, saw the session recording - no longer "stakeholder versus redesign." He's a co-author.

## What to do after rejection

Getting no is not the end. It's data.

“Not now” is not the same as “never.” “No data” is different from “no trust in design.” Ask directly, “What do we need to have to make this a priority?”

Record and come back. Write down the objections and agree on when to return to the question. “Let’s go back to the next quarter with retention data,” more specifically, “OK.”.

Start small. If a large redesign is not approved, ask permission for a small experiment. Small change, A/B test, user test. This reduces the risk and provides data for the next conversation.

The steakholder who said no today is your partner tomorrow. Relationships are more important than a specific project.

## Redesign presentation: how to submit and not just justify

Logic convinces rationally. The presentation convinces emotionally and visually. We need both components.

### Structure of persuasive presentation

**Slide 1: Problem (not solution) ** Start with data and real impact. Not "we want to remake X," but "this is what's happening to users right now.".

Screenshot session recording where the user is stuck is worth more than five slides with arguments.

Slide 2: The cost of the problem Translate the problem into money or users. Specific figures with calculation methodology.

Slide 3: Proposed solution Show me what, don't go into details how. Stakeholder cares about the result, not the process.

Slide 4: Expected outcome A specific target (not “became better” but “activation rate from 38% to 55%”) with a pessimistic and optimistic scenario.

Slide 5: Cost and plan** Resources, deadlines, how will we check the result.

Slide 6: Next step One concrete next step. “Approve the A/B test” is better than “approve the redesign.”.

### What exactly not to include

• Details of the design process (research, iteration, wireframes) are not for stakeholders
• The technical details of the implementation are for development
• There are too many options - the stakeholder will choose instead of approve

## How to Use Support Data as an Argument

Support data is an underappreciated tool of persuasion. These are live voices of users who complain.

### How to collect support data for an argument

1. Ask for helpdesk (Zendesk, Intercom, Jira Service Desk)
2. Tickets unloaded in the last 3 months
3. Filter by topic (the specific float/screen you want to remake)
4. Count how many tickets, how often the same question is asked

** Example of argument:** Over the past 3 months, support has received 134 requests on how to change the payment method. That's 15 percent of all calls. With an average processing time, 12 minutes is 26 hours of support work quarterly, or about 52,000 е at current rates. Improving this flow will reduce our assessment of claims by 70%.”.

This is incontrovertible — it's real data from internal systems.

## Tactics of small steps: how to get a “yes” in parts

Sometimes the best way to get permission for a big redesign is not to ask for it right away.

### Accordance ladder

1. “Can I do 5 user interviews on this topic?” is a small risk
2. The results of the interview: “This is what we found.” Can we make a quick prototype and test it
3. Prototype tested → “Test showed X”. Can I run an A/B test on 10% of traffic
4. The A/B test gave the result: Here's the data. I suggest a full launch

At each step, the risk is minimal – so it’s easier to get a yes. You ended up doing a complete redesign through a series of little approvals.

It's slower than "let's do it all at once." But it works.

## How to work with the committee: several stakeholders at the same time

To convince one skeptic is a task. A five-person committee with different priorities is another level of complexity.

### The “one ally” principle

Before you go to a general meeting, find one person on the committee who sees the problem as well as you do. Talk to him one-on-one, find out his argument. At the meeting, he will become an ally.

“One-on-one people agree, in a group defend a position” is a classic of group dynamics. A trained ally changes the balance.

### The “right question” principle

Instead of convincing, ask questions that lead to the right conclusion.

Not: "I think I need to redo the onboarding." Why do you think we have such a low activation rate compared to the benchmark? What do we need to do to lift it

When a stakeholder names a problem, he is already halfway through a solution.

### The “minimum solution” principle

Don't ask for everything at the first meeting. Ask for a minimum to collect more data:

I only need 3 things to bring you specific data: access to analytics, 5 hours to interview users, and 2 weeks. After that, we will have a clear picture.”.

Three hours and five interviews are virtually zero risk. It's hard to say no.

## Unconventional Situations: How to Persuade in Special Contexts

### Steakholder, who is "the designer himself"

A CEO or CPO with a design past is a special case. They consider themselves experts and perceive design proposals as competition to their own taste.

**Strategy: * Involve, don't oppose. “Your experience with [the previous product] is relevant here — how did you solve a similar problem then?” Make them part of the solution.

### Steakholder who "trusts intuition"

Some people make decisions by feeling. The data doesn’t convince them — or convince them less than the stories.

**Strategy: ** Tell the story of a particular user. Here is Alexei, a team lead of 20 people. He checked in, tried for 40 minutes, and left. Here is a record of its session.” One live case sometimes does what 10 slides can't.

### Stakeholder "let us just get started"

The product is in the stage of active growth, all resources for new features. "Redesign later.".

**Agree with priority, but share the problem. “I understand that feature is more important now. But one particular screen that blocks conversions is 2 days of work. Can we do it in parallel? A small task does not compete with a roadmap.