Customizability of shortcuts shapes long-term use
Aliases: user-pinned nav · default shortcuts
What it is
Who sits in the shortcut bay can be chosen by the product or left to the user. Customizability shapes long-term use. A fully locked default is ignored once a person’s real frequent paths diverge from the average. A fully empty bay asks people to finish “configure navigation” before they get a short-cut. Shortcuts still being tapped months later are usually “a decent default, and it can be changed”.
Why it happens
Default shortcuts come from the population’s average frequent set; an individual’s frequent set often diverges (support lives in tickets, finance in bills). If they cannot change, the slots are occupied by the wrong items, people learn to ignore the whole bay, use drops across a few weeks, and even a good location will not save it. Conversely, an empty bay fronts the configuration cost: newcomers do not yet pin, and may not know they can, so it stays empty and the short-cut never happens. A changeable default delivers the first week’s gain, then lets people who diverge swap the unfit slots.
The cost of changing also shapes use. If pin/unpin is buried in an object menu, only experts change, and for everyone else the bay is still a locked default. If a change does not sync across devices, the other machine returns them to the ignored default. Customization must also be reversible: a wrong pin must come off immediately, or people will not touch it, which is equivalent to not customizable.
Studying it
Run three queues: locked default, empty start, changeable default. Track for weeks the share of navigation clicks that hit the bay, and how many people successfully changed it at least once. Independent variables: visibility of the change entry, and whether it syncs across devices. Dependent variable: continued use of the bay, not first-day novelty clicks.
Code “I did not know I could change it” separately in interviews; it turns customizable into locked in practice.
Where it stops holding
When compliance or brand requires an entry to stay (a safety centre, an emergency contact), that one slot may lock; the rest should still change. Tiny tools with two or three destinations do not need customization. In a managed enterprise, admins may push shortcuts; the range a person can still change must be explicit, or a change overwritten by policy the next day teaches “changing does nothing”.
Applying it
- Default from population frequent paths, and put visible unpin on the shortcut item and visible pin on the target page.
- Do not make empty state a blank: say “pin what you use here” and offer one or two suggestions.
- Sync customization to other devices on the same account. Mark admin-locked slots separately.
- How to check: weeks after launch, see whether bay clicks are still above noise, and what share of people successfully changed a shortcut. Near-zero changes plus dropping use means a locked default is being ignored. If people who changed do not see it on another device, the sync gap resets long-term use.
Related
- Within the group: E5.16.1 Shortcuts let frequent functions skip the full hierarchy · E5.16.2 Pinned items must stay few, or they stop being shortcuts · E5.16.4 Duplicate pins and regular nav must stay in sync
- Adjacent: E5.14 Command Palettes · E5.18 Permission Visibility of Navigation
- Search terms:
customizable navigation·default pins·personalization