Why do redesigns often perform worse before they perform better?

Redesigns often dip before they climb because a redesign breaks the familiarity existing users built up, and even an objectively better design imposes a relearning cost that drags performance down at first. The improvement is real, but it is not free on day one: users who knew exactly where everything was now have to find it again, and that friction shows up as slower task completion, more hesitation, and a drop in the engagement metrics that depend on fluent, automatic use. The gains arrive once people adapt to the new design, so the early dip is the cost of change being paid, not evidence that the change was wrong.

The mechanism is that experienced users do not read an interface the way a new user does, they run it from memory. After enough use, the locations of things, the sequence of steps, the meaning of each control become automatic, and the user navigates by habit rather than by looking. A redesign, however much better its new arrangement, invalidates that habit. The button that lived in the top right for two years now lives somewhere else, the flow that took four remembered taps now takes a different path, and the user who could move without thinking suddenly has to think again. That thinking is the relearning cost, and it makes even a genuinely faster, clearer design feel slower and more frustrating in the first encounters, because for the established user the old design’s worst feature, its familiarity, was also its greatest strength. The dip is the gap between losing the old automatic fluency and building the new one.

A designer sees this in the shape of the metrics after launch. A team rebuilds a cluttered dashboard into something cleaner and genuinely more efficient, and in the first weeks support tickets rise, time-on-task for routine actions goes up, and longtime users complain the new version is worse even though every individual task now takes fewer steps. What the numbers are recording is not a failed redesign but a population of expert users demoted to novices overnight, hunting for things they used to find blind. Give it a few weeks of real use and the same metrics cross back over and keep climbing past the old baseline, because now users have rebuilt their fluency on a better foundation. The teams that panic at the dip and revert never reach the second half of the curve; the teams that expected it ride through to the payoff that was there all along.

Where this breaks down is that not every dip is the relearning cost, and the mechanism is not a license to ignore a redesign that is actually worse. A temporary dip that recovers and surpasses the old baseline is the normal cost of change; a dip that does not recover, or that traces to a real regression, a broken flow, a removed feature people needed, worse accessibility, is the redesign failing and telling you so. The way to tell them apart is to watch the trajectory and the cause: relearning cost fades as the same users get more exposure, while a genuine problem persists and often shows up as a specific, repeatable complaint rather than diffuse unfamiliarity. Expecting a dip is not the same as excusing every dip.

Before you launch a redesign, plan for the dip so you do not misread it. Set the baseline you are comparing against, decide in advance how long you will let users adapt before judging the result, and watch whether the curve recovers and the complaints fade or whether they harden into specific regressions. Ease the relearning where you can with guidance and continuity, then hold your nerve through the temporary drop rather than reverting at the first bad week. Treat the early dip as the price of change being paid, distinguish it from a real failure by its trajectory, and give a better design the time it needs to become familiar before you decide whether it worked.