Design
Design translates the product model into an experience people can use. It does not begin from empty pixels: actors, activities, objects, actions, permissions, and business rules constrain what each surface must make possible.
The experience pass
Section titled “The experience pass”When a project enters Design, modelARch derives an experience blueprint. It proposes:
- surfaces for distinct audiences;
- the shell and navigation for each persona;
- views and their purpose;
- primary and contextual actions;
- transitions and multi-step flows;
- view patterns appropriate to the data and work;
- gaps where a product decision is still missing.
The blueprint is an authored model artifact with provenance. It is not generated JSX and it is not merely a screenshot.
Design at two scales
Section titled “Design at two scales”Product experience
Section titled “Product experience”Experience decisions answer:
- Where does each actor begin?
- What information is primary in their current context?
- Which action should be obvious, contextual, or hidden?
- Which transitions preserve orientation?
- How do empty, loading, denied, and failure states behave?
Visual system
Section titled “Visual system”Brand and design-system decisions answer:
- What typography, color, radius, elevation, density, and motion express the product?
- Which component treatments remain consistent across views?
- Which decisions vary by surface or persona?
Visual tokens live in the model so preview and generated code can consume the same values.
Derived defaults and explicit overrides
Section titled “Derived defaults and explicit overrides”modelARch may derive a reasonable view pattern from semantics: a collection query suggests a list; chronological events suggest a timeline; aggregate metrics suggest a dashboard. Derived choices must remain inspectable.
Use an explicit override when the product needs a different composition. The override becomes intent in the model—it is not a manual edit to generated layout code.
Staleness
Section titled “Staleness”An experience blueprint is derived from a model fingerprint. If a relevant model change occurs, modelARch can classify the blueprint as stale and rerun only the affected scope. This avoids pretending a previously approved design still represents a changed product.
What to review
Section titled “What to review”Before generating, inspect the experience as each actor:
- Can they find their primary task?
- Do they see only the data their access scope allows?
- Are destructive or irreversible actions clear?
- Are business rejections explained in product language?
- Do mobile and narrow layouts preserve the journey?
- Are specialized workflows represented by an appropriate pattern rather than generic CRUD?
Continue with Experience blueprint, Views and patterns, or Generate.