---
title: "How Long Does a Product Redesign Take? Timelines for Apps and Web Platforms"
subtitle: "Screen count is the number most teams start with when estimating a product redesign timeline. It’s usually the wrong one to plan around."
author: "Sparklin Innovations"
date: 1970-01-21
categories: ["Design", "Design", "Strategy", "Guide"]
excerpt: "Screen count is the number most teams start with when estimating a product redesign timeline. It’s usually the wrong one to plan around."
url: https://sparklin.com/blog/product-redesign-timeline
---

![pointer](https://res.cloudinary.com/dsmmrjzql/image/upload/f_webp,w_600,q_auto:good/docstorage/foresight_test/callout-pointer.png) 

TL;DR:

Based on the way we structure redesign programs at Sparklin, a product redesign can take anywhere from 10 to 32 weeks. A focused product may take 10–14 weeks, a multi-platform product 18–28 weeks, and a complex enterprise platform 20–32 weeks or longer. These estimates cover product strategy, UX research, UX design, UI design, validation and engineering handoff. Development, QA and release planning require a separate estimate, although implementation can begin while later design modules are still in progress.

“How many screens are there?” is often one of the first questions asked when estimating a product redesign. It provides an initial sense of scale, but roles, journeys, product states and approval requirements also affect the timeline. 

Screen count is useful for getting to a rough range, but it doesn't tell you how difficult a redesign will be. A product with 50 screens can contain several user roles, permissions and exception states. Another product may have 150 screens built from a small set of repeatable patterns. The second product can be faster to redesign, even though it has three times the screen count.

**A better way to estimate a redesign is by its decision complexity:** how many product and experience decisions need to be made, and how interconnected those decisions are.

At Sparklin, we estimate redesigns using six factors: critical journeys, user roles, product decisions, states and exceptions, platform count and approval structure. Screen count is considered within that context.

A 50-screen consumer product with three user roles and a compliance review may take longer than a 100-screen commerce app with one role and one decision-maker.

We saw this on a recent commerce-platform redesign spanning app, mobile web and desktop web. The number of screens was only part of the estimate; the way journeys carried across three platforms, and where their behaviour needed to differ, had a much greater effect on how we structured the work.

## Timeline at a Glance

| **Product scope**                     | **Indicative size** | **Typical complexity**                                   | **Design timeline** |
| ------------------------------------- | ------------------- | -------------------------------------------------------- | ------------------- |
| Focused product                       | \~50 screens        | Few roles, established product logic, limited exceptions | 10–14 weeks         |
| Enterprise platform                   | \~250 screens       | Multiple roles, permissions, workflows and edge cases    | 20–32+ weeks        |
| Native app + mobile web + desktop web | Varies              | Shared journeys with platform-specific behaviors         | 18–28 weeks         |

## What Actually Determines a Product Redesign Timeline?

Two things tend to determine where a redesign lands within these ranges. The first is the complexity of the product itself: its roles, workflows, exceptions and unresolved business rules. The second is how quickly the team can actually make decisions.

We've worked on complex products that moved quickly because the right people were available every week. We've also seen relatively contained redesigns lose days at a time waiting for feedback to be consolidated. Adding more designers doesn't solve the second problem.

| **Factor**          | **Lower complexity**           | **Higher complexity**                       | **Primarily affects**       |
| ------------------- | ------------------------------ | ------------------------------------------- | --------------------------- |
| Critical journeys   | Few independent journeys       | Many interconnected workflows               | Decision complexity         |
| User roles          | One primary user               | Customers, admins, operators, managers      | Decision complexity         |
| Product decisions   | Core logic established         | Fundamental behavior unresolved             | Decision complexity         |
| States & exceptions | Primarily happy paths          | Permissions, errors, edge cases, compliance | Decision complexity         |
| Platforms           | One platform                   | App + mobile web + desktop                  | Decision complexity         |
| Approval structure  | One accountable decision-maker | Multiple stakeholder groups                 | Influences decision latency |

The first five largely describe the complexity of the product. The sixth describes the organization's ability to resolve that complexity.

Research readiness and the state of the design system matter too. If users are already accessible, product data is available and there's a mature component system to work from, we can usually move faster. Recruiting specialist users or establishing a design system from scratch adds time.

## What "Product Redesign" Covers

A redesign begins by examining the current product, the problems users encounter and the outcomes the business wants to improve. The work may then include information architecture, wireframes, visual design, design-system development, usability validation and engineering handoff. One of the clearest differences between a UI refresh and a product redesign is how many existing product decisions need to be reopened.

A UI refresh generally retains the existing product structure and flows and may take 4–8 weeks. A redesign also examines the product’s structure, journeys and behavior, which is why the work may take 10–32 weeks or longer.

The formal redesign timeline usually runs through validated engineering handoff. Design support should continue during implementation QA, but the estimate itself, and the number a client plans around, covers strategy and design work. Development, technical QA and release planning are estimated separately, though on larger projects development can start on approved modules while design continues on later ones.

If a 14-week estimate covers design through handoff, development and QA still need to be scheduled. The two workstreams can overlap. They should still be estimated separately so the launch plan accounts for both.

This article covers digital products: apps, SaaS platforms and enterprise software. If you're planning a marketing site rather than a product, our [website redesign timeline](https://sparklin.com/blog/website-redesign-process-a-stepbystep-guide-for-modern-websites) article covers content, CMS and launch planning specifically for that context; the two processes overlap less than the names suggest.

## The Six Phases of a Product Redesign Timeline

We organise most redesign programmes into six phases: discovery, information architecture, wireframes, UI design, validation and handoff. In practice, several of these phases run in parallel. UI work can begin once the first priority journeys are approved, while validation can take place as later journeys are still being designed.

| **Phase**                  | **Typical duration**                   |
| -------------------------- | -------------------------------------- |
| Discovery and research     | 2–5 weeks                              |
| Information architecture   | 1–3 weeks                              |
| Wireframes and prototyping | 3–8 weeks                              |
| UI and design system       | 4–12 weeks                             |
| Validation                 | 1–3 weeks per round, often overlapping |
| Engineering handoff        | 1–3 weeks, followed by ongoing support |

Note: These durations should not be added together. Information architecture, wireframing, UI, validation and engineering handoff often overlap.

Work can move downstream once the decisions behind it are sufficiently resolved. UI can begin on approved critical journeys while secondary journeys are still being wireframed. The design system can develop alongside the first UI module. Engineering can review important interactions before the final handoff.

**Discovery can take two to five weeks.** The timeline may extend when user recruitment, analytics access or stakeholder interviews have not been arranged in advance.

If participants have been recruited and the required product data is available, research can begin immediately. A two-week discovery phase may extend to five weeks when stakeholders have different views of the problem or responsibility for participant recruitment is unclear. Research may reveal that the issue described in the brief has an earlier or different cause. For example, onboarding drop-off can begin before sign-up if users reach the product without a clear understanding of its value. By the end of discovery, the team should have agreed on the priority journeys, the problems to address and the boundaries of the redesign.

**Information architecture takes one to three weeks to establish.** It continues to evolve as flows are wireframed and tested. Finalizing it before the main flows have been explored and tested can lead to revisions during wireframing.

**Wireframes and prototypes take three to eight weeks.** The estimate depends on the number of distinct journeys, decisions and product states being designed. Repeated screens built from the same pattern add less effort than new workflows or exception states.

**UI design and the design system take four to twelve weeks.** UI can start once the first critical wireframe flows are approved; it doesn't need to wait for every wireframe. Building the design system alongside the first module creates reusable components and interaction patterns for the modules that follow.

**Validation runs one to three weeks per round**, often overlapping with later design work. It should examine whether users understand and can complete the priority journeys.   
  
When the schedule is shortened, validation is sometimes reduced to save time. Complex, unfamiliar or high-risk journeys often benefit most from testing before development begins.

We don't treat handoff as the point where engineering sees the work for the first time. Important interactions are usually discussed during wireframing and feasibility reviews, so the final handoff is mostly about resolving detail rather than introducing major product behavior.

On a recent commerce platform covering a native app, mobile web and desktop web, we used the app as the reference platform. UI began for approved journeys while wireframes for later modules were still being resolved. This allowed engineering discussions to begin earlier without locking unresolved product decisions prematurely.

## Product Redesign Timeline Examples by Scope

**A 50-screen product**, with one platform, one or two roles and five to eight critical journeys, typically runs 10–14 weeks: two weeks of audit and scope, wireframes overlapping into UI design from around week three, two rounds of validation, and handoff by week 10–14\. A consumer app with onboarding, home, discovery, checkout, profile and support journeys fits this shape.

**A 250-screen enterprise platform**, with multiple roles, interdependent workflows and legacy constraints, typically runs 20–32 weeks, and should rarely be designed as one uninterrupted batch. For work of this scale, we usually divide the product into modules, validate the riskiest workflows first, and release approved work progressively to engineering rather than waiting for all 250 screens to be finished.

**Enterprise platforms rarely become complex because of their happy paths.**

The complexity sits in permissions, exceptions, historical behavior and tasks that move between departments. This is why enterprise redesign estimates should be based on workflows, roles and states before screen count. One interface may need to behave differently for several roles, permission levels or stages of the same process.

**A multi-platform product**, spanning a native app, mobile web and desktop web, typically runs 18–28 weeks. Three platforms don't mean three separate redesigns. Research, product logic and much of the design system can be shared. But we don't treat the other platforms as resized versions of the first one: navigation, information density and touch versus pointer behavior can change the experience substantially, and flows such as checkout or authentication sometimes need platform-specific handling.

We usually establish one platform, often the app, as the reference implementation. Mobile and desktop web are then adapted from the shared logic and design system, which is what keeps the total closer to 18–28 weeks than to three separate projects stacked end to end.

## What Delays a Redesign

"It's only a small change" is often the sentence that reopens the scope. The screen may be small; the logic behind it rarely is.

Beyond scope creep, the recurring causes are a review group with no single accountable decision-maker, research that starts before participants are actually recruited, and content or product logic that arrives after wireframes are built around placeholder assumptions. Edge cases pushed to handoff instead of resolved during design tend to resurface as engineering blockers rather than design decisions. We've also seen projects lose more time waiting for consolidated feedback than producing the next design iteration. Asynchronous comments from five stakeholders, gathered separately, take longer to resolve than one structured review.

## How to Shorten a Product Redesign Timeline

A shorter timeline depends largely on how quickly the team can make and confirm decisions. One accountable owner, consolidated feedback and reviews completed within a day or two can save several weeks over the course of a redesign.

Sequencing also matters. Priority journeys can move into UI and engineering review while UX work continues on later modules. Starting the design system with the first approved module makes each subsequent module faster, while progressive handoff allows development to begin before the full product is designed.

Engineering should be involved during wireframing so that feasibility constraints surface before handoff. This reduces the risk of flows being reopened after visual design is complete.

Research and validation are harder to compress when the product contains genuinely uncertain or high-risk journeys. A short usability round during design can surface problems while they’re still relatively easy to change, rather than during development or after launch.

## Product Redesign Timeline FAQs

### Can UX and UI happen at the same time?

Yes, once a priority flow has approved structural direction. Waiting for every wireframe before starting UI work is rarely necessary.

### Does the redesign timeline include development?

Usually not, unless it's contracted as a combined design-and-development programme. The design timeline runs through validated handoff; implementation support continues from there.

### How long should user research take?

Typically two to five weeks, largely driven by recruitment. Existing customers who've already agreed to be contacted can be scheduled quickly; recruiting a new panel, especially for a niche or enterprise audience, is usually what stretches this phase toward the longer end.

### How many rounds of usability testing does a redesign need?

For high-risk or high-usage journeys, we generally plan two rounds: one to identify the main problems and another to verify the revised flow. A contained, well-understood journey may need only one round.

### Can a redesign be done in eight weeks?

A contained product or single journey can be, if scope, users, data and decision-makers are all readily available. A complex platform shouldn't be forced into that window.

### Should all 250 screens be redesigned before development starts?

No. Progressive, module-based handoff generally reduces risk and keeps engineering from sitting idle.

## Planning a Redesign?

Most teams that come to us with a hard launch date have already picked it before scoping the design work, which is workable as long as there's enough runway behind it. As a rough guide, four to eight months between kicking off a redesign and shipping it gives discovery, validation, engineering estimation, development and QA enough room to happen without everything compressing at the end. Enterprise and regulated products usually need the longer end of that range.

Planning a product redesign? Share your current product, target launch date, platforms and what you know about the main user roles and journeys. We'll help you work out the decision complexity, realistic scope, sequence and design timeline.

If you're earlier in the process and weighing whether to redesign at all, [ten signs your product needs a redesign](https://sparklin.com/blog/signs-your-product-needs-ux-redesign) and [how to choose a UX design agency](https://sparklin.com/blog/ux-design-agency-selection-guide) are good next reads.