Before you redesign a SaaS product
A redesign is the most expensive way to fix a product that nobody has looked at closely. Most of the value comes from the work before the first new screen. This is what we do first, and what you can prepare before you talk to a studio.
Say what is actually wrong
“It looks outdated” is a symptom. Before anything else, write down where the product loses people: the step where trials stop, the screen support explains most often, the task that takes three clicks too many. If you have analytics or session recordings, they usually point to the same few places.
When we came back to Aimgod, nine years after the first version, the visual style was the smallest problem. The real work was structure: every task, habit and goal had to connect to the one question the product exists for. Is my time going where I want it to go?
Research the job, then the screens
Talk to the people who use the product and watch them do the main task. For Spillsjakk, the chess tournament platform of the Norwegian Chess Federation, that task was running a tournament for pupils and students from start to finish. We built the work around it: target audience, goals, a story map, a site map and user flows for every step an arbiter takes.
A story map is worth the time. It shows the whole journey on one wall, and gaps that are invisible screen by screen become obvious.
Fix the flows before the visuals
Most redesigns that disappoint are new skins on old flows. Draw the shortest path for each key task first, cut the steps that exist for historical reasons and put the information people need on the screen where they need it. Only then move to interface design. In Spillsjakk this meant one screen per tournament with players, pairings, games and results within reach.
Rewrite the copy with the design
Interface text is part of the design. Labels, empty states, error messages and hints decide whether a screen explains itself. We write and edit copy along with the layouts, in the language your users speak. A redesign is also the moment to remove internal names that leaked into the product.
Build a system, not a set of screens
A redesign that is delivered as 80 static screens starts to fall apart the first week a developer adds a new one. Deliver a design system with it: tokens for color, type and spacing, components with their states, and rules for layout. For Aimgod that meant 17 type sizes and 6 weights, from small chart labels to large headlines, all documented as tokens. For Spillsjakk the system covers more than 150 screens in light and dark themes.
Plan the release
Decide early whether the redesign ships at once or in parts, how existing users will meet the new interface and what you will measure after launch. Prototype the riskiest flows and test them with real users before development starts. It is the cheapest moment to change your mind.
What to prepare before you call a studio
- Access to analytics, recordings or support tickets, even rough ones.
- Two or three users who would agree to a short call.
- The list of tasks your product exists for, in order of importance.
- Your current design files and the codebase stack, whatever state they are in.
- What success looks like six months after launch.
With these, the first conversation is about your product, not about process. If you are planning a redesign, see how we work on SaaS product design or tell us about the project.
