Redesigning a digital product is surgery, not make-up. A product that is three years old carries user data, search rankings, internal workflows and customer expectations with it; if those do not reach the table, a "fresh look" simply renews the problem. Digital product redesign at PBDP starts with a diagnosis: what is actually broken, where the root cause sits, and what the cheapest credible repair is. Only then do we decide — sometimes a re-architecture is enough, sometimes a rebuild, always with a migration plan that does not lose traffic, revenue or user habit along the way.

Redesign, re-architecture and optimisation are different jobs

Optimisation improves the same screen: button copy, field order, speed. Re-architecture changes the structure because users' mental models do not match it, and that work begins with information architecture. Full redesign changes interface, content and usually technology as well. Misdiagnosing which job you have is the costliest mistake in this field: many projects that arrive labelled "redesign" are solved by restructuring and a handful of functional fixes, while products soothed with a new colour scheme sit back in our path a year later. Our first session is dedicated to separating the three, after reading user research and analysis and a technical audit.

Signals that redesign has become serious

Six symptoms carry most of what we have seen over the years: support answers the same question twice a day; abandonment clusters at one specific step of a form; sales sends screenshots because the interface cannot explain itself; every new feature has to be built "a bit differently" because there is no system; mobile is a second-class citizen; and engineering asks for time on every change because they fear breaking what exists. Three of the six means the problem is not cosmetic, and a rebuild of the web and mobile interface has to be paired with a technical decision.

What you receive

• A diagnostic report: findings backed by evidence — analytics, user recordings and a technical review — each with its root cause.
• A scope decision: re-architecture, partial redesign or rebuild, with the reasoning, timeline and price of each option.
• Migration plan: the complete old-to-new URL map, redirects, structured-data preservation and the release sequence.
• New structure and screens: designed around observed behaviour and revised conversion paths.
• A product design system: so release two and three get cheaper, built as part of design system creation.
• Proof before launch: old and new compared with real users through usability testing.
• Post-launch monitoring: weekly traffic, conversion and error reports until the new version demonstrates stability.

The process, step by step

1. Three-sided audit: user experience, technical health and SEO content collected in one review.
2. Problem and metric definition: every pain point becomes a number so success can be proved at the end.
3. Strategic decision: scope chosen by comparing the three options and the risk attached to each.
4. Design and test: structure, key screens and a prototype, tested with users and corrected before code.
5. Build and migrate: implementation, content and data migration, plus speed and performance optimisation on the new build.
6. Staged launch: progressive rollout or a staging domain, close monitoring and a rehearsed rollback.

How a redesign avoids burning your existing assets

The value of a three-year-old product sits in invisible assets: inbound links, pages that rank, historical analytics data and the queries people used to find you. A redesign that ignores them discovers the traffic cliff six months later and commissions a second project. Protecting those assets takes four moves: a complete URL map with server-level 301 handling, preserving or improving structured data through technical SEO, keeping analytics events identical before and after launch, and staging the release so a rollback stays fast. Teams that build these four safety cages on day one treat redesign as managed risk rather than a gamble.

Frequently asked questions

How much of the existing work survives a redesign?

More than most people expect. Content and data are assets, and a page that does its job should not be rewritten just to look new. We sort every page into keep, revise or delete, and make that call from traffic, conversion and answer quality — not from how the meeting feels.

How long and how expensive is it?

Eight to fourteen weeks is typical for a mid-sized product, and cost follows the diagnosed scope rather than our preference. The diagnostic report gives you three priced options so the decision stays yours; comparable projects are in our project archive.

Can we redesign without any downtime?

Yes. The new version is built and tested on a staging environment, then switched on progressively for part of the traffic. No page becomes unreachable during the process, and if anything looks wrong, rolling back to the previous version takes minutes.

If your product has aged and your users have noticed, talk to PBDP. Before any contract we will report the current state and the options in writing.