Engineering

Design System Spec Prompt — Components, States, and Accessibility

Turn UI requirements and component needs into a design-system spec: a component inventory with states, variants, responsive behavior, accessibility requirements, microcopy rules, and developer handoff notes.

Open in Markdown Output Builder

Overview

A UI built screen by screen fragments into one-off buttons and inconsistent spacing. This prompt specifies the component system instead: from the product's UI context and component needs it produces a design-system specification — design principles, a component inventory, each component's states and variants, responsive behavior, accessibility requirements, content and microcopy rules, token guidance, interaction patterns, do/do-not examples, and the notes a developer needs to implement it. It is a structured textual spec, honestly scoped: it does not write CSS or component code, generate visual mockups or Figma files, review source code, or explain existing code — it is the specification those activities work from. It covers the states, variants, and accessibility that generic technical documentation leaves out.

How to use this resource

Inventory before styling

A component inventory with a single responsibility each comes before any visual decision, so the system stays coherent.
Specify the hard parts

States, variants, responsive behavior, and accessibility — the places consistency breaks — are specified per component.
Hand off, don't hand-wave

Microcopy rules, token guidance, and implementation notes give a developer a spec to build from, with open questions named.

Why This Works

Most UI inconsistency lives in undefined states and variants — specifying them up front is what a design system is for
Building accessibility into the spec is far cheaper than retrofitting it after components ship
Token guidance and interaction patterns keep every page feeling like the same product as the UI grows

Best for

Planning reusable UI components and a design system
Creating component specs before implementation
Aligning states, variants, accessibility, and microcopy rules
Preparing a UI handoff for developers

Not for

Writing actual CSS or component code
Generating visual mockups or Figma files
Reviewing source code — that's the Code Review tools
Explaining existing code — that's Code Explanation
General technical documentation — that's the Technical Documentation prompt

Use cases

Specifying a reusable component system before any UI is built
Defining states, variants, and accessibility for a button, form, and modal set
Preparing a design-system handoff a developer can implement from

FAQ

Will this design system prompt give me actual CSS or token values I can paste in?

It gives TOKEN GUIDANCE, the categories to define (color, spacing, type, radius, elevation) and how components consume them, not final values unless you provided them. A rule explicitly refuses to write CSS, component code, or token values that weren't provided. The markdown-output-builder returns a textual spec; a developer implements the code and values from the IMPLEMENTATION HANDOFF NOTES.

How does the spec handle design decisions I haven't settled yet?

Unresolved decisions go into section 12, OPEN QUESTIONS, rather than the model silently picking one. For inputs you lack you write "not specified" and the constraint is noted instead of guessed. COMPONENT STATES (default, hover, focus, active, disabled, loading, error, empty) is still specified per component, so ambiguity stays isolated to what you flagged, which you resolve before building.

How does this cover what a general technical documentation prompt leaves out?

The per-component hard parts: COMPONENT STATES, VARIANTS & RESPONSIVE BEHAVIOR, and ACCESSIBILITY REQUIREMENTS (keyboard interaction, focus order, ARIA roles, contrast, target sizes), the places consistency breaks that generic docs skip. It adds DO / DO-NOT EXAMPLES for the highest-risk components. It is a textual spec from markdown-output-builder, not a code review or a visual mockup.

Customize This Resource

Opens this setup in Markdown Output Builder. Generate to get the full markdown prompt — then adjust the sections, table rules, and consistency level.

Open in Markdown Output Builder

Inputs you need

Have these details ready before you copy or open the template.

The product type and the platforms or devices it targets
The shared UI elements and interaction patterns across screens
Brand, accessibility, or framework constraints
Any existing tokens, component library, or visual direction
The tone of the product experience

Prompt Template

Copy it as-is, or use Open in Markdown Output Builder to load it pre-filled and customize it with your own context.

DESIGN SYSTEM / COMPONENT SPEC

You are specifying a reusable UI component system. Work from the UI context and component needs given — do not invent product features or screens. This produces a textual design-system specification, not CSS, not component code, and not a visual mockup.

Paste the product UI context:
[What the product is, the platforms/devices it targets, and the screens or surfaces it has]

Paste the component needs:
[The UI elements and patterns the screens share — buttons, forms, cards, tables, nav, modals, etc.]

Paste any existing constraints:
[Brand or framework constraints, accessibility target (e.g. WCAG AA), existing tokens or component library — write "not specified" for any you lack]

Paste the desired tone for microcopy:
[e.g. plain and direct, friendly, formal — plus any banned words]

Return:
1. PRODUCT UI CONTEXT — the surfaces and platforms the system must serve, summarized.
2. DESIGN PRINCIPLES — the few rules that keep the system coherent as it grows.
3. COMPONENT INVENTORY — every shared component, one line each, with its single responsibility.
4. COMPONENT STATES — per component, the states it must define (default, hover, focus, active, disabled, loading, error, empty).
5. VARIANTS & RESPONSIVE BEHAVIOR — the variants (size, emphasis, layout) and how each component adapts across breakpoints.
6. ACCESSIBILITY REQUIREMENTS — keyboard interaction, focus order, ARIA roles/labels, contrast, and target sizes, per component where it matters.
7. CONTENT & MICROCOPY RULES — labels, button text, error and empty-state copy conventions, in the given tone.
8. TOKEN GUIDANCE — the token categories to define (color, spacing, type, radius, elevation) and how components consume them (guidance, not final values unless provided).
9. INTERACTION PATTERNS — the shared behaviors (validation, navigation, disclosure, feedback) components follow consistently.
10. DO / DO-NOT EXAMPLES — for the highest-risk components, a correct use and a common misuse.
11. IMPLEMENTATION HANDOFF NOTES — what a developer needs to build it: dependencies, order, and the decisions that are expensive to change later.
12. OPEN QUESTIONS — the specification gaps and ambiguities to resolve before building.

Rules:
- Specify states, variants, and accessibility for every interactive component — these are where consistency breaks.
- Do not write CSS, component code, or token values that weren't provided — give guidance, not implementation.
- Do not claim to produce a visual mockup or a Figma file — this is a textual spec.
- Put unresolved design decisions in Open Questions rather than picking one silently.

More resources from Markdown Output Builder

Resource

Markdown Output Prompt — Lock the Document Structure

The contract that stops AI documents from restructuring themselves: a pinned section skeleton, forced tables, and strict consistency rules.

Prompt Engineering

Resource

README Prompt Template

Overview, Installation, Usage, Examples, Configuration — the README skeleton with required, runnable code examples.

Engineering

Resource

API Documentation Prompt

Overview, Authentication, Endpoints, Error Handling, Rate Limits — endpoint docs in an identical structure, with parameter tables and runnable examples forced.

Engineering

Resources that pair well

Resource

Executive Summary Prompt

Summary, Why It Matters, What Happens Next — the executive summary contract for readers who will never open the source.

Operations

Resource

Force JSON Output from AI

Stop getting 'Sure, here is the JSON…' — the output-contract pattern that forces models to return only parseable JSON: schema, example, and a strict rule block.

Prompt Engineering

Resource

Fix Invalid JSON from AI

The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.

Engineering

Related tools

Tool

Markdown Output Builder

Build prompts that produce documents in a fixed structure — headings, sections, and tables.

Structured Output

Projects that use this resource

Project

Build a Company Website with AI

The full path to a business website that holds together — plan the content, structure the site, design the components, write the page copy, then ship it as one coherent whole.

5 stages Websites

Project

Build a Booking System with AI

The full path to a booking and reservation system — model resources, availability, and reservations, design the booking API, set customer accounts, wire calendar and notification integrations, design the UI, review security, then ship.

8 stages Business Systems

Project

Build an Inventory Management System with AI

The full path to an inventory management system — model products, stock, locations, and movements, design the inventory API, set roles, plan supplier and POS integrations, design the UI, review data-integrity risks, then ship.

8 stages Business Systems

Project

Build an Internal Admin Panel with AI

The full path to an internal admin panel — model the operational data it manages, design the management API, define RBAC and admin permissions, design the tables and forms, review risky admin actions, then ship to trusted internal users.

7 stages Business Systems

Project

Build a Marketplace with AI

The full path to a two-sided platform — define the buyer-and-seller requirements, model the data, design the API, build roles and permissions, wire integrations, design the UI, then test, secure, and ship it.

10 stages Software Development

Project

Build a CRM with AI

The full path to a CRM that fits your sales process — define the contacts, deals, and pipeline, model the data that ties them together, then build the roles, integrations, and pipeline UI, and ship.

9 stages Business Systems

Project

Build an E-commerce Store with AI

The full path to a store you own end to end — model the catalog and orders, design the storefront and checkout, add customer accounts and payments, then secure it, test it, and ship.

10 stages Commerce

Workflows that use this resource

Workflow

AI UI & Component Design Workflow

Structure a UI so it stays consistent as it grows — inventory the screens, break them into reusable components, specify the component system and its rules, then review the structure for drift.

4 steps 40–70 minutes

Tip: Save time by exploring related resources and tools that integrate with this resource.