Design System Component Spec
Published · Updated
Specify it once, properly, so engineering does not have to guess.
Tags: Design, Technical, Product
Prompt template
# Component spec **The component** - What it is: [text: Name] - Where it appears: [textarea: The contexts and screens it shows up in] - What it holds: [textarea: Text, icons, counts, and what varies] **Variants and states** - Variants needed: [textarea: Sizes, styles, emphasis levels] - States to cover: [multi: Default, Hover, Focus, Active, Disabled, Loading, Error, Selected, Empty] **System context** - Existing tokens: [textarea: Spacing scale, colour tokens, type scale] - Related components: [textarea: What it sits beside or replaces] - Platform: [dropdown: Web, iOS, Android, Cross-platform] **Content** - Real content range: [textarea: Shortest and longest values you have actually seen] - Localisation: [textarea: Languages, since length expands] Specify anatomy, every variant and state, spacing and sizing against the token scale, and responsive behaviour. Content rules matter as much as visuals here: maximum lengths, what happens on overflow, what happens when an optional element is absent, and what a very long unbroken string does to the layout. Accessibility: role, keyboard behaviour, focus handling, and what gets announced. Then the part that actually prevents misuse: when to reach for this component and when to use a different one. End with the open questions someone needs to decide before build.