--- title: "SaaS Product Redesign Without a Rewrite | Utkarsh Panwar" description: "A SaaS product redesign in three passes: fix the flows that cost tickets and drop-off, consolidate UI patterns, then refresh visuals. No big-bang relaunch." url: https://www.utkarshdesign.com/services/product-redesign author: Utkarsh Dhairya Panwar updated: 2026-10-08 --- # SaaS product redesign, in three passes Service · Updated 8 Oct 2026 **I redesign live SaaS products in three passes instead of one big relaunch: first the flows that cause support tickets and drop-off, then the scattered UI patterns, then the visual refresh. Each pass ships on its own, so users get fixes within weeks and never relearn everything at once.** ## Why big-bang redesigns stall The usual plan is to redesign everything in Figma, then rebuild. Six months later the new design is half built, the old product has kept changing underneath it, and the team maintains two UIs. When it finally ships, users who had learned the old one get a new one all at once. I split a redesign by what each change pays back. Fixing a broken flow pays back within weeks. Consolidating patterns pays back in how fast the team ships. A new visual layer mostly helps the product sell, which matters, but it's the least urgent of the three. ## Pass one: the flows that cost money Start where support tickets and funnel drop-off point. These fixes are usually small (a rule shown at the wrong moment, an error with no next step), and they can ship without waiting for a new design system. At FamPay, people found out too late that one-time-use vouchers lost their leftover value after a partial spend. The fix put a "One time use only" pill right above the Buy Now button, with a confirmation before payment and a reminder at redemption. Nothing else in the app had to change for it to ship. ![FamPay Amazon voucher purchase screen with two callouts pointing to the 'One time use only' pill and to the Buy Now button directly below it](https://www.utkarshdesign.com/images/9XwbHNQY3ezQHalJV3hcxoZC2M.webp) _A redesign at the scale of one pill, placed where the decision happens._ In B2B products the same pass usually lands on setup. At CodeAnt the self-hosted setup was a long docs page with numbered steps and embedded screenshots of another product. I turned it into a step-by-step flow with a short video for each platform, part of the onboarding work in the trial-to-paid guide. ![Before: CodeAnt docs page for self-hosted Azure DevOps pull request review, with sidebar navigation, numbered setup steps and an embedded Azure screenshot](https://www.utkarshdesign.com/images/vSEIhJhnwDQQxTA3aEd7PUqnTio.webp) _Before: setup as a docs page the user had to follow in another tab._ ![After: redesigned CodeAnt self-hosted setup screen with a Configure Application Details video on the left and a GitLab URL, Client ID and Client Secret form on the right](https://www.utkarshdesign.com/images/codeant-self-hosted-after.webp) _After: one step at a time, with the video for that platform beside the form._ ## Pass two: one system instead of eighteen versions Products that grew fast tend to have four kinds of table, three modals and a different empty state on every page. Each one was reasonable when it shipped. Together they make every new screen a debate. At CodeAnt AI I pulled 18+ recurring UI patterns into one system while the product kept shipping, because a tool used every week can't stop for a design freeze. I wrote up how that system was built, and what it did to design turnaround, in my guide to design systems for startups. - Inventory first: screenshot every table, modal, empty state and filter bar in the product and put them side by side. - Pick one winner per pattern: the version that handles the most states, which is rarely the newest. - Migrate screens as engineers touch them for other work, rather than in one big ticket. ## Pass three: the visual refresh Once flows work and patterns are shared, a visual refresh is mostly a change of tokens and components: type, colour, spacing, icons. It can roll out in days instead of months, because the system does the work. Doing it first, on top of inconsistent patterns, means repainting every variant by hand. This is also the right time to bring the product in line with the website and brand, so a buyer who clicks from your homepage into a trial sees the same product they were sold. ## Deliverables and timing 1. **Weeks 1 to 2: audit**: Walk every core flow, read tickets and funnel data, inventory UI patterns. Output: a ranked list of flow fixes and a pattern map. 2. **Weeks 3 to 6: flow fixes**: Redesign the top flows, test the riskiest with users, hand off to engineering in shippable slices. 3. **Weeks 5 to 10: system**: Consolidate components in Figma, overlapping with pass one. Engineers migrate screens as they touch them. 4. **Final weeks: refresh**: New visual tokens applied through the system, then a check of the built product against the files. Timings are for a mid-sized B2B product with one team shipping. A small product can do all three passes in about six weeks; a large one may only need pass one from me while your designers take the rest. ## When this approach doesn't fit If you're changing what the product is (a new audience or a different core job), incremental passes are the wrong tool and you need a rethink from the flows up. If the product is about to be rebuilt in a new stack anyway, design the new version once. And if only the marketing site looks dated, what you want is a website redesign. [The CodeAnt AI case study](https://www.utkarshdesign.com/work/codeant-ai): Onboarding, dashboards and the design system, redesigned while the product kept growing. To start, email work@utkarshdesign.com with a product login if you can share one and the two screens your support team hears about most. ## Questions people ask ### How long does a SaaS product redesign take? For a mid-sized product, about ten to twelve weeks across all three passes, with fixes shipping from around week four. Smaller products can be done in about six weeks. ### Will users have to relearn the product? Much less than with a relaunch. Flow fixes and pattern changes arrive a few screens at a time, so each change is small enough to notice without retraining. ### Do I need a design system before redesigning? No. The system comes out of the redesign in pass two, built from the patterns your product already uses. ### Should I redesign the product or rebuild it from scratch? Redesign in passes if the product's core job and audience stay the same. Rebuild only if you're changing what the product is, or the engineering team is moving to a new stack anyway. ### Do you work with in-house designers? Yes. A common split is that I lead the audit and pass one, and your designers take over the system migration. ## Sources 1. [Fresh vs. Familiar: How Aggressively to Redesign](https://www.nngroup.com/articles/fresh-vs-familiar-aggressive-redesign/), Nielsen Norman Group 2. [Radical Redesign or Incremental Change?](https://www.nngroup.com/articles/radical-incremental-redesign/), Nielsen Norman Group ## Start a project Tell me what you're building and where it's stuck: [book a 30-minute call](https://cal.com/utkarsh-design/30min), email [work@utkarshdesign.com](mailto:work@utkarshdesign.com) or [send a brief](https://www.utkarshdesign.com/contact). ## Related - [SaaS product and dashboard designer](https://www.utkarshdesign.com/services/saas-product-design) - [SaaS dashboard design for managers and contributors](https://www.utkarshdesign.com/guides/saas-dashboard-design) - [How we doubled trial-to-paid at CodeAnt](https://www.utkarshdesign.com/guides/how-we-doubled-trial-to-paid) - [How to audit UI inconsistency with a UI inventory](https://www.utkarshdesign.com/guides/ui-consistency-audit) --- Utkarsh Dhairya Panwar, Founding Product Designer and Design Engineer (IIT Roorkee; Founding Designer at CodeAnt AI, YC W24). Email: work@utkarshdesign.com · Book a call: https://cal.com/utkarsh-design/30min · Hire: https://www.utkarshdesign.com/hire · About: https://www.utkarshdesign.com/llms.txt