Definition

Every intent-aligned affordance currently available to a user, spanning provider-built, third-party, user-brought, and substitute sources, regardless of whether the user is aware of any given one.

What's in the landscape

Four sources combine into the landscape:

• Provider-built affordances — the offering: the app, workflow, materials, integrations, and support the provider supplies.
• Third-party affordances the provider has accepted — components the provider wired into the offering but doesn't own (Google sign-in, Stripe checkout, the OAuth flow that handles authentication).
• User-brought affordances — what the user already has when they arrive: existing tools, domain knowledge, reviews they've read, social proof they trust, templates from a colleague.
• Substitute affordances — what the user reaches for when the provider's offering is inadequate at a particular step: pen-and-paper, a search-engine answer, a Stack Overflow thread when the docs fail, asking a teammate over Slack.

The user doesn't sort options by who built them — they encounter what's available and hopscotch toward whichever fits best at each step.

Intent anchors the landscape

The landscape reconstitutes when the pursuit changes. A hammer is in the landscape for nail-driving but not for paint-can-opening — nothing about the hammer changed, the pursuit did. The same logic runs in software: the email integration is in the landscape for users trying to invite teammates, not for users trying to export a report.

This is the structural distinction from the route. The landscape spans all intent-aligned affordances regardless of which route the user takes; the route is the specific trajectory the user does take. Two users with the same intent can take different routes through the same landscape, hopscotching toward different affordances at different steps.

Provider control reaches only a slice

The provider's offering is one source among four. Most of the landscape sits outside provider control, and that's true whether the provider plans for it or not — users will bring their own tools and improvise substitutes wherever the offering falls short of the moment.

The path is the provider's deliberate route-efficacious slice of the landscape. The user's actual route can include affordances well outside that slice. Designing as if the user's landscape stopped at the offering produces well-built destinations between unsupported transitions.

Example

A founder using a new analytics tool to build their first investor dashboard. Their landscape for this pursuit includes:

• The tool's dashboard builder, SQL editor, and chart library (provider-built).
• The Stripe and Google Sheets connectors the tool ships (third-party, accepted into the offering).
• The founder's own SQL knowledge, the dashboards they saw at a previous startup, the template their lead investor emailed them last week (user-brought).
• A YouTube tutorial someone made about the tool, a Stack Overflow answer about a window function, a quick Slack message to a friend who's a data analyst (substitute).

The provider built one of those four sources. The route the founder actually takes hopscotches across all four — pulling Stripe data through the connector, copying the investor's template structure, watching the tutorial when stuck on a chart config, messaging the data-analyst friend when the SQL editor's error message isn't enough to unblock them. The tool's path competes with and complements the rest.

See also

• Encounter-moment adequacy
• Path canvas
• Intent
• Reachability
• Single-elimination stakes