Brief a product interface
Produce a buildable interface specification grounded in an accepted product flow. Do not render or
invent product behavior unless the user separately asks for implementation.
Prove the source flow
Identify the flow, platforms, surfaces, nodes, decisions, and states this brief implements. If no
usable flow exists, return to map-user-flow.
Every screen, component, state, and action must trace to a flow node, edge, native platform
requirement, or explicit product decision. Do not add speculative dashboards or settings.
Define the interface system
Specify:
- screen/surface inventory and source-flow trace;
- reusable component names, jobs, content, and variants;
- layout hierarchy and responsive/native behavior;
- existing semantic color, type, spacing, radius, motion, and focus tokens;
- default, hover, focus, pressed, disabled, selected, loading, success, warning, and error states;
- empty, permission, offline, interruption, and recovery treatment;
- keyboard, assistive-technology, contrast, reduced-motion, and target-size requirements.
When project tokens are missing, define semantic roles that must be mapped before implementation.
Do not invent arbitrary raw values or silently create a new brand system.
Make the handoff testable
For every screen, state what the user understands, can do, and sees after the action. Name content
requirements, truncation/overflow, validation, persistence, analytics events when requested, and
platform-native boundaries.
Deliver
Return:
- outcome and source-flow trace;
- screen inventory;
- component system;
- token application map;
- per-screen layout and content hierarchy;
- interactions and complete state coverage;
- accessibility requirements;
- implementation order and test cases;
- explicit non-goals and unresolved decisions.
Finish with acceptance criteria a designer and engineer can review without reconstructing the product
logic.
1---2name: brief-product-ui3description: Turn an approved product flow into an implementation-ready UI brief. Use for screen inventory, reusable components, design-token application, interaction and system states, accessibility, and build handoff. Not for marketing landing pages or brand identity.4---56# Brief a product interface78Produce a buildable interface specification grounded in an accepted product flow. Do not render or9invent product behavior unless the user separately asks for implementation.1011## Prove the source flow1213Identify the flow, platforms, surfaces, nodes, decisions, and states this brief implements. If no14usable flow exists, return to `map-user-flow`.1516Every screen, component, state, and action must trace to a flow node, edge, native platform17requirement, or explicit product decision. Do not add speculative dashboards or settings.1819## Define the interface system2021Specify:2223- screen/surface inventory and source-flow trace;24- reusable component names, jobs, content, and variants;25- layout hierarchy and responsive/native behavior;26- existing semantic color, type, spacing, radius, motion, and focus tokens;27- default, hover, focus, pressed, disabled, selected, loading, success, warning, and error states;28- empty, permission, offline, interruption, and recovery treatment;29- keyboard, assistive-technology, contrast, reduced-motion, and target-size requirements.3031When project tokens are missing, define semantic roles that must be mapped before implementation.32Do not invent arbitrary raw values or silently create a new brand system.3334## Make the handoff testable3536For every screen, state what the user understands, can do, and sees after the action. Name content37requirements, truncation/overflow, validation, persistence, analytics events when requested, and38platform-native boundaries.3940## Deliver4142Return:43441. outcome and source-flow trace;452. screen inventory;463. component system;474. token application map;485. per-screen layout and content hierarchy;496. interactions and complete state coverage;507. accessibility requirements;518. implementation order and test cases;529. explicit non-goals and unresolved decisions.5354Finish with acceptance criteria a designer and engineer can review without reconstructing the product55logic.56