As of 13 August 2026, AI can create a UI component library.

What to actually do

1. Hand it to a person

   The route this page recommends

   A person who owns the outcome does this end to end, worth it when the failure is dear.

2. Use a tool built for this

   Second choice

3. Do it yourself

   The distant third

   A chat interface, power-user skill, and roughly 1 hour until you can act on the result.

   How to actually do it

   1. Open the product repository or a new workspace and write down the framework, language, styling approach, browser support and build commands.
   2. Gather the brand guidelines, existing design files, content examples, accessibility target and the list of components and states the product actually needs.
   3. Paste those details into the prompt, replacing every bracketed slot, and ask the model to produce the library structure, tokens, components, documentation and tests.
   4. Create the proposed folder structure in the repository and paste each generated file into the matching location, asking the model to resolve import or type errors without changing the agreed behaviour.
   5. Run the project locally and render every component state at the required viewport sizes, comparing colours, typography, spacing, content lengths and interaction behaviour with the design source.
   6. Use keyboard-only navigation and an accessibility checker to test focus order, labels, semantics, contrast and error messages, then ask the model to fix each recorded failure.
   7. Ask a designer or front-end colleague to inspect the library for naming, visual consistency, responsive behaviour and maintainability before merging it into the product.

   Prompt

   Create a maintainable UI component library for [product or team] using [framework and language] with [styling approach].
   
   Requirements:
   - Visual direction: [brand colours, typography, spacing, shape and interaction principles]
   - Components: [list the components]
   - Supported states: [hover, focus, active, disabled, loading, error, empty and other required states]
   - Responsive behaviour: [breakpoints or layout rules]
   - Accessibility target: WCAG [level if known], including keyboard use, visible focus, semantic HTML, labels, error messaging and sufficient contrast
   - Design tokens: define reusable tokens for colour, type, spacing, sizing, borders, shadows and motion
   - Content examples: [realistic example labels, text lengths and data]
   - Technical constraints: [browser support, package structure, dependencies, testing and build requirements]
   
   Produce:
   1. A proposed library structure and naming convention.
   2. The design tokens.
   3. The component implementations in separate, reusable files.
   4. Examples showing every important state and responsive variation.
   5. Usage documentation with do and do not guidance.
   6. Tests for rendering, keyboard interaction and the main states.
   7. A list of assumptions, unresolved decisions and risks.
   
   Do not invent product requirements. Mark missing information as an assumption and keep the implementation easy to change. Prefer simple, composable components over one large abstraction. Include complete code for the agreed scope, and explain where I must supply assets or project-specific configuration.

   Open it prefilled in ChatGPT or Claude, or copy it into Gemini, which takes no prefill link.