Redesign your product interface when its structure stops working, not when it stops looking new. The test is plain. People can't finish the tasks they came for, and small fixes have stopped moving your numbers. If you can't show either, you're likely looking at a taste problem, and taste problems are cheap to fix without a rebuild. That's the short answer to when to redesign your SaaS UI.
The most common wrong reason is that the product looks dated. Nielsen Norman Group has argued for years that asking for a fresh design tends to start a project with the wrong goals. Your team sees the product for thousands of hours. Jakob Nielsen's estimate, written about websites, is that loyal customers often spend under five hours a year on one. You get bored of the interface long before your customers do. Boredom is not a finding.
What counts is damage you can measure. Churn that clusters in onboarding. Support tickets asking how to do things the product is supposed to make obvious. New features that ship and then sit unused because nobody finds them. Those are the symptoms worth acting on. They have other causes too, like pricing, bugs or selling to the wrong customer, so read them as a reason to look closely, not as proof the interface needs rebuilding.
Hoa Loranger, also at Nielsen Norman Group, lists four situations where a major overhaul is justified. Gradual fixes have run out of impact, so each tweak buys less than the last. The underlying technology can't support a critical journey, mobile being the usual example. Years of patches have left the structure incoherent, and people can't complete their tasks. Or your analytics show problems so widespread that incremental fixes can't reach an acceptable conversion rate. Nielsen's own example was Microsoft Office, whose interface architecture was 17 years old by 2000 and was finally rebuilt for Office 2007.
Notice what's missing from that list: fashion. Loranger's default is blunt. Never make radical changes when minimal adjustments will suffice. Drastic changes jar users, carry business risk and can break something critical. Your heaviest users pay most, because their daily routines are exactly what a redesign disrupts.
Before you commit budget, spend a day or two watching real people use what you have now, then read the analytics next to what you saw. Loranger's point is that solid numbers keep a team focused on the right problems and end the political arguments. Be wary, too, of advice from anyone who sells redesigns and has never told a client to leave the interface alone. Ask what result would make them recommend doing less.
If the evidence does point to a rebuild, test the new version against the old one instead of announcing it. Nielsen Norman Group suggests iterating through at least three versions, because some metrics dip in the middle versions before they recover. Expect complaints at launch as well. Users dislike change, and complaints alone don't prove the redesign was wrong. They do mean you should plan for them: a support note, a short period where people can find the old route, and someone watching the numbers in week one.
The practical next step is an outside review of your product against those four conditions. It's a short piece of work, and it tells you whether you need a refresh, a set of targeted fixes or a real rebuild before anyone spends a month on the wrong one. If you want that review, send us the product and the metrics that worry you, and we'll say honestly which of the three it is.