Construction time
Construction time is the stretch when the team is building and designing the offering: writing the onboarding flows, deciding which features show up where, settling how a user will move through the product. No particular user is present yet, so the team works from general knowledge of its users, building for the wants and sticking points most people share in a given situation.
Definition
Construction time is the period when the team builds the offering — theorizing intent categories, building affordances, externalizing route-expertise — before any individual user arrives, when the only knowledge available is route-knowledge aggregated across many users rather than any one user's moment-specific situation.
What the team knows at construction time
At construction time the team has overall route-knowledge: what the path looks like across many users, the typical decision criteria at each step, which affordances serve most intents. What it lacks is moment-knowledge — what a specific user is trying to do right now, how much energy they have, what context is in play for them at this step.
The user generates that second kind of knowledge at runtime, during their actual pursuit, and the team can't reach it from construction time because it doesn't exist yet when the team is building. This isn't a research gap the team can close with more user interviews. Aggregate route-knowledge and individual moment-knowledge differ in kind; no quantity of the first turns into the second.
Preparing affordances for runtime
Construction-time work prepares affordances for the user to integrate at runtime. It can't perform the user's runtime activity for them. The team externalizes its route-expertise into affordances — the work of figuring out the route, done once and embedded in the product — and the user integrates those affordances into their own traversal when they arrive.
Designs fail when they try to do runtime work at construction time: a setup wizard that commits the user to a single guessed intent, an onboarding sequence engineered to manufacture motivation, a flow built to produce the user's progress for them. The user produces their progress at runtime; construction-time work can prepare for it but can't supply it. Felt agency is the design criterion that follows — the path has to leave room for the user's runtime knowledge.
This cuts against the assumption that more construction-time work yields better outcomes. Better-shaped construction-time work does — work that prepares affordances for integration. More work of the wrong shape, engineering states the user has to produce on their own, makes outcomes worse rather than better.
Example
A team building a project-management tool designs its onboarding at construction time: a five-step setup wizard — create a workspace, invite teammates, create a project, add tasks, set a deadline. Across thousands of signups that sequence is the common route to first value, and as an aggregate the team has it right.
An individual signing up might be a solo user evaluating the tool for personal use, with no team to invite and no shared deadline to set. Only that user knows this, and only at runtime, sitting in the flow. A wizard built entirely on the construction-time aggregate can't see the mismatch; it routes the solo user through invite-your-team anyway. The construction-time knowledge was correct on average and wrong for this user — the gap construction-time work can prepare for but can't close on its own.