Design System to Documentation
Drafting component documentation from code, which handles the mechanical parts and not the judgement.
Definition
Given component source and tokens, a model can draft API tables, state descriptions and usage examples. The parts requiring judgement, particularly when not to use a component, still need a human.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
Reach for this when
- Documenting a large existing library.
- Keeping API documentation current.
- Producing a first draft for a reviewer to edit.
Common mistakes
- Publishing generated usage guidance.
- Accessibility claims taken from code rather than testing.
- Documentation that describes the API but not the decisions.
What to generate and what to write
- Generate: prop tables, type signatures, default values, state enumerations, code examples.
- Generate as a draft: the one-line description, and accessibility notes derived from the implementation.
- Write yourself: when to use and when not to use, with the named alternative.
- Write yourself: the content guidance, which depends on your voice.
- Write yourself: known limitations and the reasoning behind API decisions.
Local chart
AI·007 · Region XII · Grid G6
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Related concept
Connected closely enough to change how you apply this.
- UI to Accessibility AuditAI·005 · AI workflow
- Component API DesignSYS·002 · Design system
- Design System DocumentationSYS·003 · Design system
- Design TokensSYS·001 · Design system
- Visual StatesFND·053 · UI foundation
Nearby in the Atlas
Adjacent territory, found through shared tags rather than a stated link.