The cost of changing architecture rises with inbound links, bookmarks, and settled mental models
Aliases: IA change cost · path inertia · accumulated coordinates
What it is
On launch day, changing the tree mostly costs design and engineering. The longer it lives, the more external search listings, mailed URLs, bookmarks, support scripts, training, and spatial memory wrap around the old paths. Change cost rises with accumulation: merging Reports into Finance is a nav edit at three months and a site-wide break-and-relearn event at three years. The cost is not whether the new tree is good. It is how many systems have treated the old coordinates as fact.
Accumulation is a by-product of success. An architecture that can be found gets remembered and cited, and therefore gets harder to change. That does not void the reason to change; it moves the budget from “draw a new tree” to “migrate the old world.”
Why it happens
Every inbound link, every bookmark, every muscle memory that “Reports is third” is a vote for the current coordinates. Votes cannot be recalled. A new tree updates only the nav it controls; votes for old coordinates still arrive; if arrival is a 404 or a different object, trust is settled at site level. Mental-model accumulation is harder than URLs: URLs can redirect; remembered places only fade or must be forcibly relearned. So “change the label, keep the path” is often cheaper than changing path and label together, even if the new label is slightly worse.
External listings lag, so both coordinate sets coexist during migration and people conclude there are two sites. The lag is itself part of the accumulation.
Studying it
Treat accumulations as inputs to the change plan, not as surprises after launch.
- Paradigms: before change, inventory inbound links, bookmarks if available, internal doc citations, old class names in search logs; experimentally compare label-only change, tree change with 301s, and tree change with no redirects, on tasks and trust. Longitudinally, watch hits on old paths decay after release.
- Independent variables: site age and traffic, inbound-link count, whether old place memory is kept (position stable, name changed).
- Dependent variables: broken-link arrivals, misclicks from old mental models, support tickets asking where things went, time for completion to recover to pre-change levels.
- Methodological note: lab new users cannot show accumulation cost. Recruit veterans; use real bookmarks and query words. A short A/B can show the new tree looking better; return visits show the relearning curve.
Where it stops holding
Unreleased or internal alpha has almost no accumulation; change cost is near zero, so correct it early rather than postponing the decision into a high-accumulation period. A legally forced rename (brand, legal entity) must happen regardless of accumulation, but the budget has to add migration in proportion to accumulation, not in proportion to the design file. Personalized, logged-in structures accumulate less in search engines and still accumulate in personal spatial memory; do not watch inbound-link count alone.
Applying it
- Before changing architecture, produce an accumulation list: top inbound URLs, old class words in on-site search, paths in training and scripts, frequent entrances of returning users.
- If the path can stay, keep it. When it cannot, put redirects and a dual-name parallel period in the same plan; do not ship only the new nav.
- Watch completion recovery on veterans separately. Do not let a new-user tree test stand in.
- Verify four weeks after release: hits on old URLs and old class queries should go to the new object, not to 404. If completion rises only for new users and falls for veterans, cost was underestimated: finish the migration before restyling the new tree.
Related
- Within the group: G1.11.1 A taxonomy should leave room for future content, not fill up around what is known today · G1.11.2 Premature classes for tiny sets lose meaning as content grows · G1.11.4 Structural changes need redirects so old paths do not break · G1.11.5 Governance decides who may add or merge classes, or the taxonomy inflates without order · G1.11.6 Imbalanced class use is a signal to restructure; do not rely on intuition alone
- Adjacent: G1.07 Content inventory and audit · G4.02 Deep linking · G2.07 Navigation consistency
- Search terms:
information architecture change cost·legacy URLs·spatial memory
Cards in the same group
- G1.11.1A taxonomy should leave room for future content, not fill up around what is known today
- G1.11.2Premature classes for tiny sets lose meaning as content grows
- G1.11.4Structural changes need redirects so old paths do not break
- G1.11.5Governance decides who may add or merge classes, or the taxonomy inflates without order
- G1.11.6Imbalanced class use is a signal to restructure; do not rely on intuition alone