How to Present a Website Redesign Before and After Without Relying on Looks Alone

A website redesign presentation should explain more than which version looks newer. Clients need to understand what the old page made difficult, how the new design responds and which claims still need evidence from the working website.

A useful before-and-after review connects each visible change to a visitor task. It avoids promising higher conversion rates, faster performance or better accessibility simply because a mockup has cleaner spacing. Those outcomes require appropriate testing after the design is implemented.

Choose a fair comparison

Capture the old page and prepare the new mockup at comparable widths. Use the same page, similar content and a clearly identified device layout. If the old page contains a seasonal promotion while the new design uses a different offer, explain that difference instead of attributing every improvement to visual design.

Keep the original comparison files labeled and dated. A reviewer should be able to distinguish “current live page captured for reference” from “proposed redesign.” Avoid leaving the two images under vague filenames such as final and final-new.

Start with the original problem

Describe the issue in concrete terms. “The enquiry action is separated from the service explanation” is more useful than “the page feels outdated.” “Visitors must compare three offers with different information structures” is more useful than “the cards need to pop.”

Where you have evidence, state its source and limits. A support request, a usability observation or an analytics pattern can inform a design hypothesis. Do not present a personal impression as a measured finding, and do not invent percentages to make the redesign sound more persuasive.

Explain the response in a short change narrative

For each important section, describe the old arrangement, the proposed change and the intended benefit. For example: “The previous service page placed eligibility details after the enquiry form. The redesign brings those details before the action so visitors can assess fit before contacting the team.”

That explanation is specific enough for the client to challenge productively. They might know that eligibility differs between customer groups, which could change the design. A presentation based only on visual preference would be less likely to uncover that information.

Keep the first review focused

Select a manageable set of changes for the first conversation. Navigation, message hierarchy and the primary action usually deserve discussion before small decorative refinements. If the client has to react to every detail at once, important decisions may disappear among minor preferences.

Provide a short reading order: “First compare the opening section. Then review the service cards. Finally follow the enquiry journey.” Use section names or clear references so feedback can be connected to the relevant part of the design.

Present desktop and mobile deliberately

A desktop before-and-after comparison does not establish that the mobile layout is clear. Prepare a separate mobile comparison when the arrangement changes. Look at reading order, content density and whether the primary action remains understandable on the narrow layout.

Do not describe a smaller rendering of the desktop image as a finished responsive design. Static screenshots preserve their internal composition when scaled. If the mobile page rearranges sections, show the corresponding mobile source design.

Use preview links without confusing versions

Swelik lets you share a browser preview and replace a design while retaining its public link. For a before-and-after presentation, explicitly identify which version the recipient is looking at. If both references need to remain directly available, use clearly named separate previews or a deliberately prepared comparison document.

Do not assume the reviewer can access your private management history. Keep that link private and send only the references intended for the client. When you update the proposed design, accompany the link with a short summary so the client understands why a familiar URL now shows revised work.

Agree on the next validation step

End the presentation with a decision and a plan. The client might accept the information hierarchy while leaving the pricing copy open. Capture both outcomes. After implementation, verify the real navigation, form behavior, responsive layout and content before treating the redesign as complete.

If the project aims to improve enquiries or purchases, decide how that outcome will be evaluated. A mockup can support a hypothesis about usability or persuasion. It cannot demonstrate a business result by itself.

Build a comparison around three concrete changes

Choose a small set of changes that matter to the page's purpose. For example, a consultancy redesign might clarify the audience in the hero, separate overlapping service descriptions and place the enquiry instructions beside the form. These three changes tell a coherent story about understanding and acting on the offer.

Present each change using the same structure: previous arrangement, observed concern, proposed response and next validation step. Consistency makes the explanation easier to follow. It also prevents a beautiful new section from receiving a detailed rationale while a less visually dramatic but important content change is barely mentioned.

Label the concern honestly. If the team has not researched visitor behavior, call it a design hypothesis or a stakeholder concern. A comparison can still be useful without pretending that every choice is supported by analytics. The difference is whether the audience understands what is known and what remains to be tested.

Create a fair capture checklist

For the old reference, record the page address, capture date, visible state and approximate viewing width. Note whether a cookie banner, temporary promotion or personalized content appears. For the proposed design, record its version and the intended layout. This context helps the client interpret differences that are not actually part of the redesign.

Check whether the screenshots start and end at equivalent places. Cropping away an old page's useful information can make the proposal seem artificially stronger. If you intentionally compare only one section, say so and preserve a route to the wider context.

Compare content completeness as well as composition

A cleaner new page may simply contain less information. That can be a sound decision, but the removed material needs an explanation. Identify what was shortened, moved or deleted, and ask the client to confirm whether the remaining page still supports the necessary customer questions.

Use a content mapping note: “Existing eligibility details move to the service section; delivery information remains before the enquiry action; the duplicated company history is removed from this page.” This makes the redesign review concrete and gives the content owner an opportunity to catch omissions before implementation.

Handle disagreement about the old design

A client may have a strong attachment to an existing element because it reflects the company's history or was expensive to create. Ask what value they want to preserve. The answer may concern recognition, tone or a useful feature rather than the exact visual treatment.

Show how the proposal preserves that value, or acknowledge the tradeoff if it does not. Avoid presenting the old site as an embarrassment. A respectful comparison is more likely to reveal the reasons behind existing decisions, including constraints that may still apply to the new design.

Separate aesthetic preference from functional change

If a stakeholder prefers the original color treatment, discuss that preference in the context of the brand and readability. If they cannot find a service category in the new structure, treat that as an information issue. Combining both under “the client does not like the redesign” loses the distinction needed to respond usefully.

A review ledger can include one column for the observation and another for its type: content, structure, visual direction or behavior. The categories are not a score. They help the team assign the right next step, such as obtaining final copy, revising a section or demonstrating an interaction in the working prototype.

Design a short presentation sequence

Begin with the page goal and the limits of the comparison. Show the existing reference, then introduce the three main changes in the proposal. Give the reviewer time to inspect the full page before asking focused questions. End with the decisions needed now and the checks reserved for the implementation stage.

Do not ask for final approval immediately after showing a dramatic before-and-after slide. The contrast can dominate attention while lower-page details remain unseen. Provide the preview link and a clear review window when the client needs time to inspect content or consult another stakeholder.

Use a decision summary after the discussion

Write a short summary such as: “The new service grouping is accepted. The headline needs a more specific audience reference. The image direction is provisional until the client supplies the final photographs. Form delivery and navigation behavior will be checked in the staging site.”

This is more useful than recording that the redesign was generally well received. It tells the designer what to change, the client what to supply and the developer which assumptions remain open. Keep the summary tied to the reviewed version so a later update does not erase the context of the decision.

Plan evidence after implementation

If the redesign has a measurable business goal, agree on the evaluation approach before launch. Consider whether content, traffic sources or the offer are changing at the same time, because those changes affect how a result can be interpreted. Do not attribute every later movement to the visual redesign alone.

For a smaller project without formal experimentation, still define practical checks: whether visitors can find key information, whether forms work and whether the team receives the information it needs. A clear next check makes the presentation a useful project milestone rather than a claim that the new picture has already solved every problem.

Frequently asked questions

Should the old design always look worse in the presentation?

No. A fair comparison should preserve useful elements from the existing page and explain genuine tradeoffs. Highlighting only flattering differences can hide important content or functionality that must survive the redesign.

Can I compare a live website with a static mockup?

Yes, if you explain the difference. The live page has working behavior; the static mockup represents intended appearance. Do not claim the proposed interactions have been tested when only their visual states exist.

What should the client approve?

Ask for a decision on the stated scope and version. Use a design review meeting agenda to keep the conversation focused, then record outstanding content and development checks separately.