Experience blueprint
The experience blueprint is the bridge between the domain model and generated screens. It describes which surfaces exist, who they serve, which views matter, and how people move through them.
Inputs
Section titled “Inputs”The blueprint derives from:
- human actors, their goals, pains, and product role;
- activities and user stories;
- objects, queries, commands, and access scopes;
- processes and their ordered steps;
- public and authenticated surfaces;
- brand and layout intent.
Because it is derived from real model semantics, a patient and an operator can receive different homes, navigation, density, and available actions without duplicating the domain.
Outputs
Section titled “Outputs”A blueprint can declare:
- persona shell and landing view;
- ordered navigation;
- view purpose and target data;
- primary and contextual actions;
- transitions, labels, and visibility;
- specialized storefront or workflow choices;
- gaps that require a product decision.
It also records provenance: which choices were proposed, approved, or explicitly overridden.
Currentness
Section titled “Currentness”The blueprint is stamped against a model fingerprint. Changes to actors, actions, queries, access, or structure can make all or part of it stale.
Staleness is not an error. It is an honest signal that a derived experience no longer fully explains the current model. Rerun the relevant scope, review the delta, and approve the new intent.
Baseline and exceptions
Section titled “Baseline and exceptions”Most views should be derived from common semantics. Use an explicit view override only for a real product exception. Overrides identify a target persona and screen, then declare a structured composition; they do not contain arbitrary component code.
Review questions
Section titled “Review questions”- Does every persona have a clear home?
- Is navigation ordered around actual activities?
- Are commands exposed only where their permissions and scope allow?
- Are read questions represented by purpose-built views?
- Do cross-screen transitions preserve process context?
- Are public surfaces intentionally separated from authenticated ones?
- Are gaps visible instead of filled with generic CRUD?
The blueprint becomes valuable when it can explain why each generated view exists. Continue with Views and patterns.