Introduction

When a founder says “we need a redesign,” they could mean any of these:

• “Make it look modern so we don’t look cheap.”

• “Fix the confusing parts that are killing activation.”

• “The whole thing is misaligned with the market.”

• “We have a user story — build the product from scratch.”

Those are four different jobs. With different risks. Different deliverables. Different price tags.

NN/g makes the same point bluntly: sometimes a redesign is a purely visual reskin, and other times it’s serious work on information architecture, taxonomy, content, and usability — and either way it must be grounded in user data with clear success measures.

Let’s make this practical.

What this really is

A redesign is a system change. You’re modifying:

• Perception (trust, modernity, brand)

• Comprehension (do users understand what this is?)

• Actionability (can users complete key tasks fast?)

• Market fit (is this the right promise for the right audience?)

Also: redesign has a hidden tax — change cost. New UI breaks habit memory. “Fresh” can be worse simply because it’s unfamiliar.

That’s why big changes should be intentional, measured, and often incremental.

The 4 Levels of Redesign (and how to choose)

Level 1. Visual Refresh (UI facelift/reskin)

What it is: Modernize look & feel while keeping the product’s logic mostly intact.

When it’s the right move:

• The product works, but looks dated.

• You’re losing trust in sales calls because the UI feels “old.”

• You need a consistent design language across screens.

What you’re actually changing:

• Typography scale, spacing system, color tokens, component styles

• UI consistency, states, and visual hierarchy

• Brand alignment (without changing what the product is)

What you’re NOT changing (usually):

• Core workflows

• Navigation structure

• Information architecture logic

• Positioning/messaging strategy

Deliverables that matter:

• Updated UI kit + component library (buttons, inputs, tables, empty states)

• A “before/after” pattern map (what changes globally vs per-module)

• Implementation notes for dev (states, spacing rules, interactions)

Common mistake: Expecting a visual refresh to fix churn, activation, or conversion by itself. Visual design can strongly affect usability and perception, but it’s not a substitute for UX architecture.

Best practice: Keep familiarity where it protects productivity. “Fresh” shouldn’t mean “different for no reason.”

Level 2. Targeted UX Improvements (fix friction, keep the product)

What it is: You keep the core structure, but you redesign specific flows that are bleeding money.

Think: onboarding > activation, invite team, create first project, billing upgrade, export, permissions, etc.

When it’s the right move:

• You can point to a few obvious problems:

  • users get stuck in onboarding

  • misclicks/errors happen repeatedly

  • key actions are hard to find

• Support tickets repeat the same “how do I…?” questions.

How the work runs (evidence > fix):

• Heuristic evaluation + expert review to surface predictable failures

• If you have analytics: use it to find where; use recordings/interviews to learn why

• If you don’t: heuristics and workflow inspection still produce high-signal hypotheses

NN/g notes heuristic evaluations work best with multiple evaluators (often 3–5) because a single person will miss issues.

Deliverables that matter:

• A prioritized friction backlog (impact × frequency × confidence)

• Flow redesigns (before/after) with edge cases

• Updated UI patterns needed to support the fixes

Common mistake: Fixing symptoms with tooltips instead of rebuilding the decision path.

Level 3. Strategic Redesign (architecture + market alignment)

What it is: Not “make it nicer.” It’s “we’re not winning — rebuild the system.”

Here you’re solving higher-order problems:

• confused positioning

• wrong information hierarchy

• wrong workflow structure

• wrong mental model

• product doesn’t match how buyers operate

  
  

When it’s the right move:

• Activation is weak, and the team isn’t sure why.

• Sales says “leads don’t get it.”

• Competitors win despite worse features.

• The UI isn’t the problem — the structure is.

What expands at this level:

• Information architecture and taxonomy work (especially for large B2B products and content-heavy sites)

• Stronger research selection (you pick methods based on what you need to learn)

• Clear success metrics and measurement plan (NN/g: redesign must have goals and measures)

Strategic lenses that help (when used correctly):

• JTBD/personas to nail who you’re building for and why

• Blue Ocean ERRC (Eliminate/Reduce/Raise/Create) to redesign value — not just UI

Deliverables that matter:

• Messaging hierarchy + value proposition map (what’s primary, what’s proof)

• New IA/sitemap + navigation logic

• End-to-end journey + key flow architecture

• Prototype + usability validation plan

• Design system foundation (so the rebuild is implementable)

Common mistake: Doing a strategic redesign as a “big bang” UI launch with no migration plan. Big change is risky; incremental releases are often safer unless you’re forced into an overhaul.

Level 4. 0 to 1 Build (from user story to product)

What it is: You’re not redesigning. You’re designing a product that doesn’t exist.

When it’s the right move:

• You have a founder narrative + market hypothesis.

• No analytics exist because there is no product.

• You need an MVP that’s coherent and testable.

How it works in reality:

• You build hypotheses, not “final UX.”

• You use competitive/market evidence to reduce uncertainty.

• You choose research methods based on what you’re trying to de-risk.

• You keep the scope brutally controlled.

Optional frameworks (use carefully):

• Retention loops like Hooked can be relevant for recurring workflows (trigger → action → reward → investment), but only if it maps to real value, not engagement tricks.

Deliverables that matter:

• Product definition (users, jobs, success criteria)

• MVP scope + feature boundaries

• Flow architecture + edge-case map

• UI kit + specs dev can build

• Instrumentation plan (what you’ll measure from day one)

Common mistake: Treating 0→1 like “design a few screens.” It’s decisions, not pixels.

Website vs Product: what changes (and what breaks)

Websites have one extra landmine: SEO.

Website redesign isn’t only UX. SEO happens before the first click, usability after. Both must be good.

And if you change URLs, structure, or domains, you’re in migration territory. Google explicitly documents how to move a site with URL changes while minimizing negative impact, including redirects and careful planning.

So the “depth levels” apply to websites too, but Level 3 work usually includes:

• content hierarchy + sitemap

• keeping or intentionally changing URL structures

• redirect mapping if URLs change

• safeguarding high-performing pages

Why the deeper levels cost more (the honest answer)

Price scales with:

• Uncertainty (how much must be discovered vs executed)

• Number of decisions (IA, positioning, flows, permissions, pricing UX)

• Risk management (migration strategy, rollout plan, keeping familiarity)

• Deliverables for build (systems, specs, edge cases, states)

A reskin is mostly execution.

A strategic redesign is investigation + architecture + execution.

A 0 to 1 build is architecture under uncertainty.

Metrics & instrumentation (what success looks like by level)

Level 1 (Visual refresh):

• Higher perceived trust in sales demos

• Improved readability, fewer UI inconsistencies

• Lower “this feels outdated” objections

Level 2 (Targeted UX):

• Funnel step lift (activation, invite completion, first key action)

• Reduced error rates and support tickets

• Faster time-to-task completion

Level 3 (Strategic):

• Improved “message clarity” conversion

• Better lead quality (right ICP self-selects)

• Retention lift tied to clearer workflows + value delivery

Level 4 (0 to 1):

• First activation in real usage

• Clear evidence that users reach the intended value moment

• Learnings that reshape MVP scope fast

  
  

Our angle

We treat redesign as a risk-managed product change:

• clarify which level you actually need,

• anchor it to measurable outcomes,

• keep familiarity where it protects adoption,

• and produce deliverables that dev can implement without interpretation.

Case from our practice

Last yea,r we had a founder come in saying, “We just need a redesign — the product works, it just looks dated.” Two calls later, it became obvious he wasn’t asking for visuals. He was trying to change the business model inside the interface: new roles, new onboarding, new pricing logic, new “main workflow,” and a totally different promise on the homepage. The previous agency had told him it was a “simple redesign,” then started ripping up flows mid-project, and he felt scammed — but the real issue was that nobody had named the level of change upfront, so expectations and budget were set for a facelift while the scope was drifting into rebuild territory.

We froze it on purpose. Not in a dramatic way — just the adult move: we defined three lanes and picked one. Refresh meant UI consistency + hierarchy + component clean-up + a couple high-friction screens, without touching the product’s core logic. Redesign meant targeted UX changes to critical paths that were already measured and understood. Rebuild meant re-architecting the mental model (roles, permissions, flows), which is basically a controlled product rewrite that has to be validated after launch. Once we framed it like that, the conversation got honest fast: he didn’t have rebuild budget, he didn’t have time for post-launch iteration, and he didn’t have enough internal alignment to change the product’s foundation without creating a civil war in his team.

In contrast, we’d just finished a project with a large, healthy SaaS where the team thought they needed a rebuild, but the truth was the opposite: their foundations were solid, they had direct access to users, and their analytics actually told them where things broke. We did a refresh + targeted redesign: tightened the dashboard hierarchy, cleaned up a few messy tables and states, rebuilt a couple onboarding moments, and delivered a coherent UI kit that dev could implement without improvisation. The key was that their team could verify everything with real users quickly, so we didn’t have to invent a grand new theory — we just made the product calmer, faster to read, and harder to break.

The takeaway is simple: founders don’t get burned because “agencies are bad” — they get burned because nobody defines whether this is a refresh, a redesign, or a rebuild, and each one requires a different level of involvement, decision-making, and validation. If you treat a rebuild like a reskin, you’ll either blow the budget or ship something unverified that breaks habit memory. But if you choose the right level and lock the lane early, design becomes a growth lever instead of an expensive guessing game. (Client and project details anonymized.)

Sources

1. Radical Redesign or Incremental Change? — Nielsen Norman Group

2. Fresh vs. Familiar: How Aggressively to Redesign — Nielsen Norman Group

3. Refine, Remodel, Rebuild: 3 Strategies for Experience Improvement — Nielsen Norman Group

4. Improvement Score Due to a Redesign (measuring before/after) — Nielsen Norman Group

5. Taxonomy 101: Definition, Best Practices, and How It Complements Other IA Work — Nielsen Norman Group

6. The Difference Between Information Architecture (IA) and Navigation — Nielsen Norman Group

7. How to move a site with URL changes (redirects + migration planning) — Google Search Central

8. Users Hate Change (change aversion after redesigns) — Nielsen Norman Group (Video)