Consistency has to survive version changes; churn costs cognitive-disability users more

What it is

Names, places, and routes already learned inside a product are what the next release can delete. Cross-version consistency cost: frequent redesign is not novelty for people with cognitive disabilities—it zeroes learning they already paid for. They take longer to build the habit; after a “brand-new navigation,” many cannot build it a second time, and they stop.

How the current version keeps same-name-same-place, and how it keeps a navigation map alive, are the earlier leaves. This one asks only along the time axis: from this version to the next, are those cues still there, and who pays when they are cut.

Why it happens

Procedural memory turns action into a sequence that need not be spoken. Once the interface reroutes, the old sequence hits empty space or the wrong object, and language is a poor patch. The old layout also presses on memory of the new one as proactive interference; the more often you change, the harder the latest version is to keep. Typical users can relearn in a session. People with cognitive disabilities often need far more repetition, and sometimes never finish a second mapping.

The asymmetry follows: a redesign that ships because mean task time dipped slightly almost cannot see the people who had turned the product into habit. For them, wiping the habit is loss of function, not a visual refresh. A reskin that keeps slots and order is cheap; reshuffling the information architecture is expensive.

Studying it

Run the same returning users (including people with cognitive disabilities) through top tasks before and after the release. Compare whether they can finish without retraining, not first-time success of new users. Behavioural markers: reaching toward the old place, searching the old name, asking support for “the entry that used to be there.”

Independent variables: skin versus IA change, a dual-run of the old navigation, a plain-language change note. Dependent variables: change in returning users’ top-task success, reaches toward old locations, churn in a window after the release.

Do not let an A/B of users who never saw the old version stand in for return cost. New users have no map to have broken.

Where it stops holding

Security- and regulation-forced restructures still have to happen; the migration cost does not vanish, it has to be paid: redirects, a dual-run, an explanation. People on their first use have no old map, so the release does not add a cross-version cost for them—though it can still hurt people mid-learning. An A/B that randomises nav order per visit manufactures a small redesign on every session, more scattered and harder to habitise than a periodic big change. A product that has stopped shipping has no iteration cost; a live product asks this question on every release.

Applying it

• Treat primary navigation, primary action names, and their slots as breaking changes. They must not be swapped “while we are here.” If they must change, migrate; do not cut over overnight.
• For a large change, dual-run the old entry for a period, or offer the previous layout; say in plain language what moved from where to where.
• Verify: after ship, returning users (prefer a cognitive-disability panel) complete the top tasks they already knew, with no demo. Reaching toward old places or searching old names means the migration did not finish. A drop in that group’s completion must not be offset by new-user conversion.

Related

• Same group: J4.11.1 Same function, same name and place, lowers learning cost · J4.11.2 Predictable navigation lets users form a stable mental map · J4.11.3 Unexpected context changes break the user's plan
• Nearby: A6.09 Procedural memory and automatisation · A6.16 Proactive and retroactive interference · G1.11 Extensibility and evolution of IA · G2.10 Stability costs of personalised navigation
• Search terms: cross-version consistency cost · redesign · procedural memory · proactive interference