Flexibility must not sacrifice the default path
Aliases: default path · flexible configuration · primary workflow · restore defaults
What it is
Flexible configuration, expert bypasses, and personalized workspaces must rest on a clear default path — the shared flow that new users, temporary roles, recovery situations, and cross-team handoff can rely on. Flexibility must not make functionality exist only after someone customizes it. This card is the shared constraint on the previous two (accelerators, customization): it does not describe how to grant flexibility but where flexibility is not allowed to reach; the three cards together form the complete rule.
Why it happens
The default path carries more than "a novice's first use." It also underwrites four less obvious roles: support staff describe steps against the default path, not against any individual's private configuration; automated tests and acceptance criteria are typically written for the default path; and when engineers troubleshoot an outage, their first move is to check whether the default path is affected, not to reconstruct every user's personalized state one by one. If every entry point can be removed, terminology swapped freely, and layout recombined without limit, all four dependencies fail at once: the system becomes a black box to novices, support can no longer describe steps in one shared vocabulary, and documentation and automation lose a stable object to reference. Flexibility should therefore layer views, shortcuts, and rules on top of shared objects and actions, rather than replace the underlying semantics — a layer can always be stripped back to the default, a replacement cannot.
Where it stops holding
Defaults are not permanently fixed either. Products should update them as tasks evolve, but that update needs versioning, a migration path, and a change notice — otherwise "updating the default" itself becomes a hidden breaking change. Security contexts may lock the default and forbid personalization for a given role for compliance reasons, but that restriction must be explained to users, or it gets reported as a product defect. For a team that has already built a highly mature internal process, forcing everyone back onto one shared default can actually reduce efficiency; the better fix is a team-level template that becomes that team's "new default," rather than a forced choice between the personal setting and the global one.
Applying it
- Explicitly define which public objects, core actions, permission model, and minimum information structure are non-removable, and write it as an internal checklist the team can verify against, rather than leaving the judgment to individual feel.
- Allow hiding, reordering, or acceleration, but never let the main flow lose its entry point; "restore defaults" must be reachable in one action, not require manually undoing every customization.
- Write documentation, training, test cases, and support scripts against the default path, listing customization-driven differences as a separate addendum, so the primary documentation does not fork with every personalization.
- How to check: run the full core-task checklist on a brand-new account with all customization disabled to confirm the shared path is complete on its own, then compare against a heavily customized account to verify both reach the same correct outcome.