Before/After: How to Show the Value of a Redesign to Be Believed

"Better beautiful" is not an argument. Beautiful - subjective. "Better" is not an argument. Better for whom, by what criteria?

Before/after communication only works when it shows not a visual change, but a change in user behavior and business outcomes.

This article is about how to document and show a redesign so that the management, the client and the whole team understand that it works.

## Why the standard “before/after” does not convince

A typical redesign presentation: on the left is an old screenshot, on the right is a new one. The designer explains, “Here we simplified, here removed the extra, here made more clear.”.

Problem: This is a conversation about design decisions, not results. Stakeholder looks and thinks one of two things: “looks better” (subjectively, unreliable) or “why should we have changed this” (a legitimate unanswered question in a screenshot).

A convincing before/after answers other questions:

• What specifically didn't work before (with proof)
• Why exactly is this decision
• What Changed in User Behavior After

## Convincing before/after structure

### Level 1: Problem with proof

Before you show "before" - show that "before" was the problem. It's not a designer's opinion, it's data.

** Which works as evidence:**

• According to analysts, “65% of users quit form at this point.”
• Session recording: "Here's 30 seconds as a real user can't find a button"
• Quote from the interview: “I pressed the wrong thing three times – it’s confusing”
• Heat map: "Click here - and it's not clickable"
• Support data: "47 requests per month asking how to do X"

One screenshot of a "do" without proof is just an old design. Screenshot + data is a documented problem.

### Level 2: The logic of decision

Why that particular decision? Not "so we decided," but the chain:

Problem → Cause → Solution

“Users didn’t notice the button (problem) → because it wasn’t visually highlighted and competed with three other elements of similar weight (cause) → we made it the only primary action on the screen and increased the contrast (solution)”

This takes 2-3 sentences. Without this, the stakeholder does not understand the logic and begins to offer alternatives to “maybe just change the color?”.

### Level 3: Measured results

This is the most important and often overlooked.

If the redesign is started and you can measure the result - measure. It turns “seems better” into “proven to work.”.

If the result cannot be measured yet (the redesign has not been launched), honestly say that this is the expected effect and indicate how you will measure.

## Before/after documentation formats

Different audiences need different formats.

### For stakeholders and management: a business case

One page or one slide:

WAS.
[Screenshot before]
Metric: [meaning]
Problem: [1–2 sentences with data]

STILL
[Screenshot after]
Metric: [new meaning]
Result: [change in percent and in money/users]

Why did it work?
[2-3 sentences on the logic of the decision]

Numbers are the language of leadership. “Task completion rate has risen from 58% to 79%,” says more than “became more comfortable.”.

### For the team: design solution with justification n

Confluence/Notion page or Figma comments:

• Context: what is the flow / screen, who are the users, what is the task
• Problem: Data + Quality Insights
• Research: What you watched what you found
• Solution: What Changed and Why Each Decision
• Alternatives considered and why not selected
• Metrics of success: what we will measure and how much

This is not a report, this is a document for colleagues who will work with this decision.

### For portfolio: history with change

Case structure:

1. Context and challenge
2. What was wrong (data + user insights)
3. Process: How to find a solution
4. Solution: What did you do
5. Result: What has changed (required in numbers)

Without results in numbers is an incomplete case. “I think it’s better in my opinion” doesn’t count.

## How to remove metrics: Basline before redesign

The most common mistake is not to fix “before” before rolling out “after”. Then there's nothing to compare.

### What to fix before redesign

2-4 weeks before the launch of the new design fix:

** Quantitatively:**

• Conversion rate on variable flow (total and for each step)
• Task completion rate (if measured)
• Error rate on problem elements
• Time on task (if relevant)
• Drop-off on funnel steps

Quality:

• SUS test results (you can quickly run with 5 users)
• Quotes from interviews about problematic places
• Session recordings with characteristic behavior patterns

### How much to watch the results

• **2 weeks is the minimum for conversion rate
• **4-6 weeks for retention and behavioral changes
• 3 months for business impacts

Do not look at the results after 3 days and do not draw conclusions. Novelty effect (users behave differently simply because something has changed) distorts the data in the first week.

## Previous Previous post: What to Do When Results Are Disappointing

Sometimes redesign does not give the expected effect. This is not a reason to hide the data – it is a reason to understand.

**Conversion rate has not increased - what to check **

• Has the traffic changed (a different source, a different audience)?
• Was there a novelty effect in the early days (a sharp rise then a slump)?
• Are there new problems that offset the improvements?
• Is the correct metric to measure this change?

How to present a neutral or negative result:

Honesty works better than concealment. We expected +20% conversion, got +3%. That’s why we think it happened and what we want to test next is maturity, not failure.

## Visual design before/after

Screenshots are good. But there are more efficient formats.

### Annotated screenshots

Screenshot of “do” with problem markers + “after” screenshot with decision markers. Arrows, takeouts, explanations. The viewer immediately sees the connection between the problem and the solution.

### Video comparison

30-second video "before" (the user gets stuck on the step, leaves with an error) and "after" (the same flow quickly and without problems). It's more convincing than any screenshot.

### Live demo vs. recording

If the stakeholders are technically savvy - live demo. If not, the recording is better: you can choose the indicative moment in advance.

## AI and Before/After Documentation: Prompts for Work

### Write an Executive Summary of Changes

We redesigned [what exactly].

Problem solved: [description with data]
What changed: [list of key decisions]
Results: [before and after data]

Write an executive summary for the guide (half page):
- What was wrong and how it affected the business
- What we have changed and why exactly this
- What you got (numbers)
- What's next?

Tone: business, no design jargon.

### Prompt: Write a rationale for a design solution

I made the following design decision: [description]

Context: [What is the flow, who are the users]
The data that led to this decision: [data]
Alternatives considered: [list]

Help me write the reasoning for the decision for the documentation:
Problem (1 data paragraph)
The logic of the decision (why so)
- Why alternatives are rejected
- What will we measure to see if the solution works

### Prompt: prepare a case for portfolio

I want to write a redesign case for my portfolio.

Data:
- What redesigned: [description]
- Original problem: [data]
- Process: [doing]
- Solution: [changed]
- Result: [before and after in numbers]

Write the case structure and text for each section.

Requirements:
- Convincing for a potential employer/client
Focus on decision-making, not visual beauty
- Results with specific figures
Volume: 400-600 words

## How to shoot “before”: a specific technique

Documenting before is not just a screenshot. A complete “do” includes several layers.

### Layer 1: Visual fixation

• Screenshots of each screen flow in 1x (desktop) and mobile
• Screen recording of flow (30–60 seconds)
• Heatmap if you have a tool (Hotjar, Clarity)

Tool: Loom for quick screen recording with commentary.

### Layer 2: Quantitative fixation

A snapshot of data from analytics with a date. What to shoot depends on the flow, but minimally:

• Total conversion rate flow
• Drop-off on every step
• Bounce rate on the input screen (if landing)
• Error rate, time on task

Save not only the numbers, but also CSV or analytics exports. After 3 months, the original data may not be available.

### Layer 3: Quality fixation

• 3-5 quotes from interviews or reviews about trouble spots
• 1–2 session recording where the problem is visible (link + timestamp)
• Support data: number of requests on the topic per month

The quality layer is the “user voice” that makes the “do” lively and compelling.

## Special cases: when the standard before/after does not work

### Radical redesign

If the changes are so big that before and after are difficult to compare directly, a different approach is needed.

Instead of comparing metrics: Achieving goals. Prior to the redesign, 23% of users reached aha moment in the first 7 days. After: 51%”. This is comparable despite the fact that the interface itself is fundamentally different.

### When there is no "before" data

It happens that the analytics was not configured, there is no data.

What can be done:

• Conduct retrospective research: interviews with users about their experience with the past version
• Find indirect data: appeals in support, reviews in stores
• There is no baseline and the result cannot be compared directly

That’s fine — but that’s what it teaches you to fix a basline next time.

### Iterative redesign

If the redesign is in small iterations (not one big release, but a series of small changes), track each iteration separately.

Maintenance of the "design journal": the date of change, what exactly is changed, the metrics before / after this specific change. Over the course of a quarter, it becomes an understandable story of progress.

## Portfolio case through before/after: how to write convincingly

For a before/after portfolio, it works best because it shows not only what is done, but also what the result is.

### Strong case structure

Don’t start with “I’ve been given the task of redoing X” – it’s boring. Start with a user problem or business context.

Good start: The product lost 60% of users in the third step of onboarding. No one understood why — the data showed the drop-off, but not the reason.”.

Bad start: Customer asked to update onboarding design.

### What to show

** Decision making is more important than visuals. Employers and customers want to know what you think:

• What the data showed → how to interpret it → what I decided to try → why

**Alternatives considered are a sign of maturity. We thought about [option A], but we chose [option B] because ..

**Real results are absolutely necessary. Without them, the case is incomplete. If there is no data, honestly say it and explain what you planned to measure.

### What not to show

• Endless screenshots of intermediate options
• Detailed specifications (this is for handoff, not for case)
• Only a final visual without context why

## Before/after documentation tools

The right tool makes documentation quick instead of burdensome.

### Figma: Design story right in the file

**Figma Versions (File → Version History) – The change history is automatically saved. You can go back to any moment and compare it.

How to use before/after:

• Before the redesign begins: File → Save to Version History → Before the redesign [date]
• Upon completion: Another version of "After the redesign [date]"
• Now you can switch and take comparative screenshots

Figma Branching (in paid plans) - you work on a separate branch, the main version remains intact. A clear point of comparison with merzha.

### Notion: Knowledge base of design solutions

Page for each significant redesign:

# Redesign [what] - [date]

#Context
[In brief: what and why]

## Problem (with data)
[Data + Screenshots to]

##The decision
[Description + Screenshots After]

## Logic of decision
[why exactly that]

## Alternatives that have been considered
[What else was thought and why not chosen]

##The result
[Data in X weeks]

# What would you do differently?
[Retrospective]

This database in a year becomes a powerful tool for onboarding new designers and justifying future decisions.

### Loom: Video comment on the change n

A short video (3-5 minutes) where the designer explains:

• What was wrong
• What changed
• Why is that so

Better than any text document for async commands. Stakeholder watches 5 minutes and understands the essence without meeting.

## Before/after for the vs. command for the client: different formats

The same data should be presented differently depending on the audience.

### For the internal team

The team wants to understand the process and learn from it. They need:

• Why this is the decision (and not the other)
• What alternatives were considered
• What didn't work as expected
• What to do differently next time

Format: Detailed Notion document with full context. Include "inconvenient" details - it teaches.

### For the client

The customer wants to know: Was it worth the money? They need:

• What was done (briefly)
• What has changed as a result (numbers)
• What it means for business

Format: 1-2 slides. Only key metrics. No details of the process.

### For portfolios (potential employers/clients)

They want to understand: what does this designer think? They need:

• Context and problem
• Decision-making process
• The result

Format: A structured case of 400-800 words with selected screenshots. Emphasis on “why” rather than “what.”.

## Frequent before/after documentation errors

### Only visual without explanation

Two screenshots without text are pictures. Add at least 2-3 sentences: what was the problem and why it was the solution.

### Data without interpretation

“Conversions went from 3% to 4.5%.” This means 45 additional paying users per month with current traffic, or about 432,000 е per year with our ARPU. The interpretation is convincing.

### You only document victories

A redesign that fails to produce the expected results is also a valuable document. Explain what went wrong. It teaches the team better than ten success stories.

### It's too late to document

Documentation 3 months after launch is a memory reconstruction. Data lost, details forgotten, context blurred. Document at the moment: basline - before launch, the decision - at the finalization of the design, the result - 4-6 weeks after launch.

## AI to create visual comparisons

Technically, AI doesn’t draw comparison tables for you—but it helps prepare content for them.

### Prompt: structuring the comparison

I want to create a visual before/after comparison for the presentation.

Before: [description of the old screen, its problems, key metrics]
After: [description of new screen, changes, results]

Help structure the comparison:
1. What are the 3-4 aspects that show the difference best?
2. How to formulate signatures for screenshots (briefly, in the case)
3. What key quote from the data to highlight?
4. How do you file this for a CEO who doesn’t have time to read the details?