Redesign or refactor: how to decide what your UI needs
Patch when the faults sit on the surface, refactor when the same fault repeats on every screen, and redesign only when the structure no longer fits what users are trying to do. Most products that look off need the first two. The signals below help you tell the cases apart.
The three options, defined
| Option | What changes | What stays | Typical trigger |
|---|---|---|---|
| Patch | Single screens: contrast, spacing, labels, error text | Layout, navigation and code structure | An audit produced a list of specific fails |
| Refactor | Shared styles and components: variables, button, input, card | User flows and navigation | Every fix has to be repeated on many screens |
| Redesign | Navigation, flows, page structure and visual language | Data and business logic | Users cannot find or finish core tasks |
Signals that a patch is enough
- Test users complete the main tasks, even if they comment on how it looks.
- The problems fit on one list, and each names a screen and an element.
- Support questions are about details, not about where things are.
- The product is young and its feature set is still changing every month.
Signals that you need a refactor
A refactor changes how the interface is built without changing what users see in any dramatic way. It is the right call when the surface faults are symptoms of missing shared parts.
- The same button exists as several separate implementations.
- Changing the brand colour means editing dozens of files.
- New screens look different from old ones, because there is nothing to copy from.
- Fixes from the last patch round have already drifted.
Signals that a redesign is justified
A redesign is expensive and takes away what existing users have learned, so it needs evidence, not boredom with the current look.
- In testing, most people fail to find or complete a core task.
- The navigation mirrors the product as it was two years ago, and new features were bolted on wherever there was room.
- The product now serves a different audience or device than the one it was designed for.
- Patching and refactoring were done, and task completion did not improve.
How to lower the risk of a redesign
- Test the current version first and write down how many people complete each task. That is your baseline.
- Redesign one flow, not the whole product.
- Build a clickable prototype and test it with five people before any production code is written.
- Release to a share of users first, with a way back to the old version.
- Measure the same tasks again and compare them with the baseline.
- Keep existing URLs working, so bookmarks and search results do not break.
When to hire a designer or a studio
Patching rarely needs outside help. Refactors and redesigns often do, because they call for design decisions that hold across the whole product. Match the kind of help to the situation.
Disclosure: BlackCard, which publishes this guide, is a boutique design and engineering studio that offers UI/UX design and builds business software. See blackcard.dev. The table applies to any provider you consider.
| Situation | Who fits | What to ask for |
|---|---|---|
| A clear list of fails and no time | Freelance UI designer or front-end developer | A fixed list of fixes with before and after screenshots |
| Inconsistent components | Product designer with design system experience | A small component set, as design files and as code |
| Users are lost | UX designer or researcher | Test sessions and revised flows as a prototype, before any visual work |
| A redesign that must also be built | Studio or agency that designs and develops | A staged plan, a tested prototype and handover of files and code |
| Accessibility conformance is required | Accessibility specialist | An audit against WCAG 2.2 level AA, with issues listed by criterion |
What drives the effort
Scope decides the cost far more than day rates do. Count the distinct screens, the number of user roles, the platforms (web, iOS, Android) and whether the work ends at design files or includes implementation. A product with ten screens and one role is a different project from one with eighty screens and four roles, whoever does it. Ask for a quote on one flow first, and judge the provider on that result.
Common questions
How do I know if my UI needs a full redesign?
Test it. Ask five people to complete your three most important tasks. If most of them succeed and only stumble over details, you need patches or a refactor. If most fail to find or finish a core task, and the cause is navigation or flow instead of styling, a redesign of that flow is justified.
Is a design system the same as a redesign?
No. A design system is a set of shared variables and components that makes an interface consistent. Introducing one is a refactor: screens keep their structure and get tidier. A redesign changes the structure itself, such as navigation and flows. Many teams do the refactor first, which makes a later redesign faster.
Can developers refactor a UI without a designer?
Often, yes. Consolidating duplicate buttons, moving colours and spacing into variables and adopting a component library's defaults are engineering tasks with clear rules. A designer adds most value when choices are needed that rules cannot settle, such as how the navigation should be organised or what the product should look like.