Design System Guidelines Tool by the Institute of Digital Marketing New Zealand. A free, browser-based working tool in three parts. Part one writes a component guideline page covering purpose, when to use it, when not to use it, anatomy, variants and states, behaviour, content guidance including te reo Maori and market differences, a WCAG 2.2 accessibility record, compliance and risk sign-off, related components, source of truth links and a changelog, with a completeness meter and Markdown export. Part two audits which components already have usable guidance, which are missing accessibility documentation, and which are the highest priority to write, with CSV export. Part three defines the documentation governance model across intake, triage, draft, review, publish and deprecate, along with decision rights and a definition of done.
Every component needs a page.
Most design systems never write one.
Teams ship components and Figma libraries, then nobody records when to use a modal instead of a drawer. So teams guess, fork the system, and the whole thing quietly decays. This is the tool that fixes the written layer — write a page, audit what already exists, and agree how guidance changes hands.
What guidance already exists
Fill this in before proposing anything. It turns an offer to help into a piece of evidence, and it gives you the baseline you will measure the next ninety days against.
| Component or pattern | Guidance | Accessibility | Compliance copy | Last updated | Owner | Biggest problem it causes | Priority | Remove row |
|---|
// Scroll the table sideways to reach every column
How guidance changes hands
Writing the pages is the visible half of the job. This is the half that stops you becoming the only person who writes anything. Name a person against every stage, then get it agreed out loud.
Decision rights
Ambiguity here is what turns a documentation owner into a documentation scribe. Get a name in every box.
Definition of done
The real winThe single highest-leverage change available to you: make documentation a condition of shipping, owned by whoever builds the component. Your job becomes the standard and the system, not every word in it.
Owning the written layer of a design system is one of the clearest routes into a product design role from an adjacent one — it teaches you the entire system and every team that touches it. It is the same discipline we build in our UX and product design certification.
Institute of Digital Marketing New Zealand · id.ac.nz