Design workflow

DynUI does not ask designers to hand control to a model. Designers still own the components, variants, tokens, density, hierarchy, and brand system. The new work is making placement intent explicit enough that the app can compose from it safely.

Think of the design task as defining a vocabulary and the rules of the room.

1. Choose the surface and design objective

Start with one surface and one product objective. Examples:

• a fitness activity detail page that should emphasize performance, recovery, or social motivation;
• a news home screen that should balance local, breaking, and analysis modules;
• a SaaS dashboard that should emphasize monitoring, setup, or review workflows.

Write the objective as a design question: “What should this screen help this kind of user do first?”

2. Define audiences with product and data partners

Audience labels should be understandable in critique and measurable in product data. Avoid cute names that only make sense inside a pitch deck.

For each audience, define:

• intent: what the user is trying to accomplish;
• evidence: behavior signals that suggest this audience;
• risks: how this personalization could be wrong or annoying;
• fallback: what the user sees when confidence is low.

For the fitness example, durable labels might be performance, recovery, and social. The design review should focus on the user intent behind each label, not the label itself.

3. Design the neutral baseline

The neutral state is not an afterthought. It is the screen for new users, low-confidence profiles, and users without personalization consent.

Design it as a first-class baseline:

• no audience-specific assumptions;
• no sensitive inference;
• no empty modules;
• clear defaults for missing data;
• enough value that declining personalization still feels acceptable.

DynUI enforces this path: without personalization consent, audience-restricted components are rejected and generation produces neutral output.

4. Annotate components

Each component in the vocabulary needs a behavioral contract. In Figma, this can live in a fenced dynui block in the component description:

```dynui
{
  "id": "recovery-score-card",
  "category": "insight",
  "description": "Shows recovery readiness and why it changed.",
  "surfaces": ["activity-detail"],
  "audience": ["recovery", "performance"],
  "priority": 80
}
```

Translate each field into design-review language:

Field	Design question
surfaces	Where is this component allowed to appear?
audience	Who is this genuinely useful for?
priority	What wins when space is tight?
variants	Which visual or density choices are valid?
data	What data must exist before this can render?
slots	What can this component contain?
contract.accessibility	What must remain true across variants?

The annotation is not busywork. It is the design spec becoming executable.

5. Set surface constraints

Surface-level rules keep generated screens recognizable. Useful constraints include:

• components that must never be hidden;
• components pinned to the top or bottom;
• maximum modules above the fold;
• allowed categories for each slot;
• density limits;
• required neutral components;
• experiment gates for components still under review.

If a generated screen feels off-brand, the fix should usually be a better component contract or surface constraint, not a prompt tweak.

6. Review generated states

Design review should include generated output, not just component specs. Review at least:

• neutral baseline;
• each primary audience;
• low-confidence or mixed-audience profile;
• missing optional data;
• missing required data;
• no-consent profile;
• each active experiment assignment;
• small and large device contexts.

Ask whether the screen still has a clear hierarchy, whether the first viewport matches the user intent, and whether the system made any assumption the product should not make.

7. Approve manifest diffs

Treat manifest changes like changes to the design system. A diff should answer:

• Which components were added, removed, deprecated, or changed?
• Did required data change?
• Did audience eligibility change?
• Did a component become available on a new surface?
• Did an experiment gate change?
• Does the renderer already support the change?

Breaking diffs should require explicit approval from design and engineering.

8. Keep a design QA matrix

Maintain a small matrix for the surface:

State	Designer checks
Neutral	No targeting, no sensitive assumptions, useful default
Primary audiences	Intent and hierarchy match the audience
No consent	Only neutral components appear
Missing data	Empty states are intentional
Experiments	Treatment is reviewable and attributable
Small screens	Priority and density still hold

This turns personalization from hidden logic into reviewable design work.

Team ownership

Design owns component intent, neutral baseline, constraints, and visual QA. Engineering owns renderer compatibility, validation, data binding, and runtime failure behavior. Product owns the surface goal and rollout. Data or growth teams own signal definitions and experiment interpretation. Legal or privacy partners own consent language and sensitive-data policy.

The healthy workflow is collaborative, but the artifact under review is concrete: the manifest and the generated screens it allows.