01
Establish what is load-bearing
Which parts people rely on daily, which are legacy, and which nobody has opened in two years.
Improve
Modernise it without starting over.
A redesign should be an act of editing, not demolition. Most dated products have a solid core and years of accumulated exceptions on top. The work is separating the two, and resisting the urge to rebuild things that were already fine.
Why it matters
The short version.
The strongest instinct in a redesign is to change everything, and it is usually the wrong one. Your existing users have built habits around the current product. Every habit you break costs goodwill, and you have a limited amount of it. Spend it on the things that are genuinely broken, not on the things that are merely old.
The audit that precedes the work is what separates editing from demolition. It establishes what is load-bearing — used daily, relied upon, quietly holding a process together — from what is legacy nobody has opened in two years. That distinction is invisible from the inside, because familiarity makes everything look equally important.
Staged rollout is the other half. Handing a customer base an unfamiliar product one Monday morning generates a support spike and a wave of resentment that a phased release largely avoids. Slower is usually cheaper here.
Every habit you break costs goodwill, and you have a limited amount of it.
Is this you?
You probably need this if…
- It works, but it embarrasses you in a sales demo
- It was designed before phones mattered and it shows
- Years of additions have made the navigation incoherent
- You are losing deals to competitors who look more modern
What's involved
The actual work.
No two engagements are identical, but this is the shape of it.
02
Interface redesign
A current visual language and a navigation structure that reflects how the product is used now.
03
Staged rollout
Section by section where possible, so users are not handed an unfamiliar product one Monday morning.
04
Bring accessibility up to standard
Older products usually fail badly here, and it is often the cheapest part to put right.
What goes wrong
Mistakes worth
avoiding.
Named plainly, because most of them are easier to avoid than to undo.
-
Changing things that were working
A redesign is not an opportunity to revisit every decision. If users are not struggling with it and it is not holding the product back, leave it alone.
-
Redesigning for the team, not the users
Internal fatigue with a design is not evidence that users are struggling with it. Your team looks at it all day; they do not.
-
Big-bang launches
One switch-over date concentrates every problem into a single terrible week. Staged release spreads the risk and lets you stop if something is wrong.
How it runs
Start to finish.
Each phase ends in something you can open, click or read.
-
01
Audit
What you have, what is used, what hurts.
-
02
Redesign
The new direction applied to your real screens and real data.
-
03
Rebuild in stages
Highest-impact areas first, so value arrives early.
-
04
Migrate users
With warning, help and a way back if something was missed.
Deliverables
What you walk
away with.
Yours to keep, whatever happens next.
A modernised, responsive, accessible product
A staged rollout plan rather than a big-bang switch
Design files and source code you own
A record of what changed and why
Questions
Worth asking.
Anything else — email hello@haddon.software and a human replies the same business day.
Not if we do it properly. Familiar things should stay where they are; we change what is genuinely broken and leave working habits intact. Change for its own sake is the fastest way to lose goodwill.
Often yes. Plenty of redesigns are a new interface over the same solid data layer, which is considerably cheaper. The audit tells us whether that is your situation.
Start with an audit and you will have a defensible answer instead of a preference. We will show you the reasoning either way.
Yes, and that is usually how it goes. We sequence it so each stage is independently shippable, which means feature work continues alongside rather than freezing for months — a freeze is a hard thing to explain to customers.
We would rather find that out from ten users in a test than from ten thousand after launch, which is what the prototype testing is for. For larger changes we keep a way back available during rollout so a bad reaction is recoverable rather than a crisis.
Related
You might also need…
Want to talk it through?
The first call is free, runs about thirty minutes, and you'll get a straight answer about whether we're the right fit — including when we're not.