Summoning-aware defaults
A summoning-aware default is the state of a screen, menu, or prompt at the moment the user opens it, chosen to fit what the product can already tell about the user's situation rather than serving whatever the product would generally want to surface.
Definition
An affordance's default state on arrival should reflect what the summoning context implies about the route-step the user is on.
Defaults are a choice
An affordance is a participant in a route — summoned at a moment, for a reason. When it loads, it loads in some configuration, and that default state is one of its choices. The choice can be informed by the summoning context, or indifferent to it.
The summoning context is often densely specified by signals the offering can detect: account state, time-of-day, GPS location, recent activity, active reservations, items in flight. Where those signals point at a single step, the affordance has the inputs to default in a way that fits the moment. Where it ignores them and presents its baseline state regardless, it's failing encounter-moment adequacy through unstated indifference — the user gets treated as if they showed up cold rather than as if they showed up for something specific.
Selfish defaults
The common failure mode is affordance-sequencing run on offering-internal logic rather than the user's path logic. A high-value adjacent prompt gets surfaced because it's high-value to the company, even when the user's route-step is plainly something else. The failure isn't about predatory intent or dark patterns — the company has to capture margin somewhere, and adjacent-value prompts are part of how that happens. The failure is sequencing those prompts by offering-as-object logic when the summoning context was available to inform a different default.
The user-side consequence is scent-loss. The user was navigating by scent; the affordance arrived with offering-sequenced defaults; the scent fragmented; the hopscotch broke. They navigate around the default to find what fits their state, or route out of the offering entirely.
The operational test
For any affordance being designed, ask: why was I summoned here? If the question has detectable answers and the defaults don't reflect them, the affordance is failing summoning-aware adequacy. The test applies at every scope — re-entry into the offering, navigation between sub-workflows, inline interface elements, search results, list views. Re-entry is the most common observable failure site, because it happens at high frequency and the offering already knows the user's state, but the principle is general.
Example
A guest with an active reservation, at the property address, around check-in time, opens an AirBnB-style app. The home screen shows "Want to be a host?" The summoning context is densely specified — active reservation, time-of-day, GPS location — all pointing at a single route-step: find the entry pin and get into the unit. The signals were detectable; the defaults didn't reflect them. The summoning-aware default at that moment is the entry pin, the check-in instructions, the host's phone number — surfaced without the user having to navigate to find them.