Redesigning Software Your Staff Already Depend On
A redesign approach for software already in daily use, where the risk is disruption rather than a blank page. GullySystem audits what exists, keeps what works, and releases change in stages your team can absorb.
What a Software Redesign Involves
Redesigning live software is a different exercise from designing something new. Staff and customers already know its quirks, some of which are worth keeping, and the work has to change the screens without breaking the muscle memory built around them.
- Starts with an audit of the current product, not a blank page
- Covers deciding what genuinely needs to change and what should deliberately stay the same
- Includes planning how the change is released, not only what it looks like once finished
- Suited to software that works but has grown inconsistent, dated, or costly to keep extending
Why Redesigns Fail When Treated Like New Builds
A redesign run like a fresh project usually creates a second set of problems on top of the first.
Every Screen Changes on the Same Release Day
The whole interface looks different on Monday morning, training and support calls spike together, and the redesign gets blamed for problems it had nothing to do with.
What's Actually Wrong Was Never Written Down
The redesign starts from 'it looks dated' rather than from the specific screens generating the most calls and mistakes, so the effort goes where it's least needed.
Muscle Memory Gets Thrown Away for No Reason
A button moves purely for the sake of moving it, and staff who could operate the old screen without looking now have to hunt for the new position.
Years of Data Don't Map Onto the New Structure
Existing records were built around the old screens' assumptions, and nobody planned how they'd translate into the new ones until migration was already underway and already a problem.
Staff Are Told About It, Not Asked
The redesign is approved by management and shown to staff only at launch, so the first real feedback from the people who use it daily arrives after it's already built.
How We Approach a Redesign
The goal is targeted improvement, not a wholesale replacement dressed up as one.
Audit Before Anything Else
We review the current screens alongside support tickets and complaint patterns, and rank problems by how much they actually cost you, rather than by how outdated they look.
Keep What Staff Already Rely On
Existing patterns stay unless there's a specific reason to change them — familiarity is worth something, and it's cheaper to keep than to rebuild.
Stage the Release
Change is released by module or by user group rather than all at once, so any one release is small enough to support properly and learn from.
Plan the Data Migration Alongside the Screens
How existing records map onto the new structure is worked out during design, not discovered as a technical problem after the screens are already approved.
Run New Screens Past Real Users Before Wide Release
The redesigned screens are put in front of the people who'll actually use them, and adjusted, before they reach everyone.
What a Redesign Engagement Produces
The output is a plan you can execute in pieces, not a single big-bang release.
- A ranked list of what's actually broken, based on real usage and complaint patterns rather than opinion
- A clear decision on what changes and what deliberately stays the same, agreed with you before design starts
- A release sequence worked out with your operations team, not imposed on them
- Before-and-after screens for the changes that matter most, so the difference is concrete rather than described
What Shapes a Redesign
Two redesigns of similar-sized products can require very different amounts of work.
- How much of the product is genuinely in scope, versus a handful of specific problem screens
- Whether the underlying data structure has to change as well, or only the screens built on top of it
- How many user groups need their own staged rollout and their own training
- How much institutional knowledge — shortcuts, workarounds, informal naming — needs to be deliberately preserved
- Whether this is a visual refresh or a change to how the software actually behaves
Redesign as Part of Our Wider Practice
A redesign draws on the same discovery, journey and prototyping work as any new product, applied with more care for what already exists.
Frequently asked questions
Do you redesign the whole product at once, or in stages?
In stages, ranked by what's actually causing the most trouble. We agree the order with your operations team so each release lands somewhere your staff can absorb it, rather than releasing every screen changed on the same day.
Will our staff have to relearn everything?
No, not deliberately. We keep the patterns your staff already operate by unless there's a specific reason to change them, and we flag any change that will genuinely require retraining so it's a decision you make knowingly, not a surprise on release day.
What happens to our existing data during a redesign?
Migration is planned alongside the screen redesign, not after it. We work out during design how existing records map onto any new structure, so it isn't discovered as a technical problem once the new screens are already approved.
What drives the cost of a software redesign?
How much of the product is in scope, whether the underlying data structure changes as well as the screens, and how many user groups need their own staged rollout and support plan. A targeted redesign of the worst screens costs far less than a full rebuild dressed up as a refresh.
How do you decide what to fix first?
We audit the current screens against support tickets and complaint patterns, and rank problems by what they're actually costing you — mistakes, workarounds, calls to the office — rather than by which screens simply look the oldest.
Can you redesign only the worst screens without touching the rest of the product?
Yes, and that's often the more sensible engagement. A targeted redesign of the screens generating the most friction is a contained piece of work, and the rest of the product is left exactly as your staff already know it.
What do you need from us to start a redesign?
Access to the current software, any support tickets or complaint records you have, time with a handful of staff who use the screens daily, and one decision-maker who can approve the ranked list of what gets fixed first.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private