The next decade of web, defined Read our manifesto

How to redesign a SaaS website without losing what already converts

Adam Muchowski

Adam Muchowski

Developer

Published

Most SaaS redesigns fail for a boring reason: the team treats the website like a brand refresh instead of a product surface. The homepage, pricing page, and demo flow are already doing work. A redesign should make that work clearer — not replace it with a new narrative that nobody tested.

Start with the jobs the site already does

Before opening Figma, list the outcomes the current site must keep:

  • Qualified demo requests from ICP accounts
  • Clear answer to “what does the product do?” in under ten seconds
  • Trust signals that reduce sales-cycle friction
  • A path from problem → product → proof → next step

If a redesign cannot map each of those jobs to a specific page section, it is not ready to design.

Separate story from structure

Structure is the sequence of sections and CTAs. Story is the language, proof, and visual hierarchy inside those sections. Change them on different timelines.

Keep the structure stable when conversion is healthy. Refresh the story when positioning, ICP, or product scope has shifted. Redesigning both at once makes it impossible to know what improved results — or broke them.

Use proof earlier than you think

B2B buyers do not need another abstract promise in the hero. They need a concrete reason to believe the product fits their stack, team size, and risk tolerance. Move one strong proof point above the fold: a named customer, a measurable outcome, or a short product walkthrough that shows the core workflow.

Blue folder with documents, one connected by a dotted line, indicating file transfer.

A simple redesign checklist

Run this checklist in kickoff, not at the end of QA:

  • Which URLs must not regress in conversion?
  • Which messages are still true after the last product launch?
  • Which pages are sales-enablement assets, not just traffic pages?
  • What can ship in phase one without blocking the rest?

Phase one should feel unfinished on purpose

Ship the highest-traffic templates first: homepage, product, pricing, and one proof page. Leave secondary pages on the old system until the new pattern is validated. A staged rollout is less glamorous than a big-bang launch — and much easier to defend when something dips.

Adam Muchowski

Adam Muchowski

Developer

Need more info?

You ask, we answer

Keen to work with us but still have questions? We've gathered the most popular ones here. And if you'd like to ask us anything more specific, we're here to help. Reach out to us.

Jakub Startek

Jakub Startek

CEO & Co-founder

They fail because teams treat the website like a brand refresh instead of a product surface. The redesign often replaces what already converts with an untested narrative, instead of clarifying and strengthening the existing conversion paths.

Before opening any design tool, list the outcomes the current site must keep. These include qualified demo requests from ICP accounts, a clear explanation of what the product does in under ten seconds, strong trust signals, and a clear path from problem to product to proof to next step.

Structure is the sequence of sections and CTAs across the page, while story is the language, proof, and visual hierarchy inside those sections. The article recommends changing them on different timelines so you can see what actually affects performance.

Keep the structure stable when conversion is healthy, and focus on refreshing the story when your positioning, ICP, or product scope has shifted. Redesigning both story and structure at once makes it hard to know what improved or hurt results.

The article suggests using proof earlier than you think, including above the fold. You can move a strong proof point—such as a named customer, a measurable outcome, or a short product walkthrough showing the core workflow—into the hero area.

You should ask which URLs must not regress in conversion, which messages are still true after the last product launch, which pages act as sales-enablement assets, and what can ship in phase one without blocking the rest. This checklist should be run at kickoff, not at the end of QA.

Phase one should prioritize the highest-traffic templates—homepage, product, pricing, and one proof page—while leaving secondary pages on the old system. This staged rollout is less glamorous than a big-bang launch but makes it easier to defend and adjust if performance dips.

The article recommends shipping the homepage, product page, pricing page, and one proof page in the first phase. These templates carry the most traffic and core conversion paths, so validating the new pattern there matters most.