How to Build a Design System Documentation Site with Zeroheight

By following this guide, you will have a fully published design system documentation site built in Zeroheight, connected to your Figma library, and structured so developers and designers can navigate it without asking anyone for help. The setup takes roughly three to four hours for an existing component library or one to two hours for a new project starting from scratch.

What You'll Build

• A live Zeroheight documentation site connected directly to your Figma component library via the Zeroheight Figma plugin
• Organised pages covering foundations, components, patterns, and usage guidelines
• Embedded Figma frames alongside code snippets so designers and developers see the same source of truth
• A component status table so teams can see what is production-ready at a glance
• A shareable public or password-protected URL your whole organisation can bookmark

Prerequisites

• A Figma account with an existing component library (Figma version 116 or later works with all features below)
• A Zeroheight account — the Starter plan is free and sufficient for teams under five; the Pro plan at roughly $149 per month per editor adds version history and private pages
• The Zeroheight plugin installed from the Figma Community (search "Zeroheight", published by Zeroheight Ltd)
• Basic familiarity with Figma components and auto layout
• Node.js 20+ if you plan to use the Zeroheight API to automate token syncing later

Step 1: Create Your Zeroheight Styleguide

Log in to Zeroheight and click New styleguide. Give it a name that matches your product or brand. This becomes the root of your documentation site. Zeroheight refers to each documentation site as a styleguide, regardless of how many components it ends up containing.

Choose your visibility setting now, before you start adding content. Public means anyone with the link can read it. Password-protected is common for client-facing agencies and teams in regulated industries such as healthcare and finance. You can change this setting later, but deciding early prevents accidental exposure of unreleased work.

What if I already have a Notion or Confluence design system page?

Zeroheight does not import from Notion or Confluence. Use your existing pages as a content outline, then rebuild the written guidelines directly in Zeroheight. The migration usually takes two to three hours for a mid-sized system with ten to twenty components.

Step 2: Connect Your Figma Library

Open your Figma component library file. Run the Zeroheight plugin from the Plugins menu. The plugin will prompt you to select which Zeroheight styleguide to connect. Select the one you just created.

The plugin creates a secure link between the two tools. It does not copy your Figma file. It streams live embed URLs so any update you make in Figma appears in Zeroheight automatically after a manual sync or a page refresh.

Why does the connection step matter?

Without a live Figma connection, documentation becomes stale within weeks. Teams at Australian SaaS companies running separate Figma files and Notion docs frequently report that their documentation falls behind by one to two major component updates before anyone notices. The live link removes that drift.

After connecting, go back to Zeroheight and click Sync from Figma under Settings. You should see your Figma pages listed. Select the pages that contain production-ready components only. Syncing work-in-progress pages creates confusion for developers reading the docs.

Step 3: Set Up Your Page Structure

A documentation site without clear structure is just a list of components. Use this hierarchy as your starting point.

• Getting Started: what the design system is, how to install tokens or libraries, who maintains it
• Foundations: colour, typography, spacing, grid, elevation, motion
• Components: one page per component
• Patterns: multi-component compositions like forms, empty states, and data tables
• Resources: links to Figma files, GitHub repos, Storybook, and changelog

In Zeroheight, click the + button in the left sidebar to add pages. Drag pages to reorder them. Group related pages into sections using the section divider option.

Should I create one page per component or group components together?

One page per component is the approach used by design systems at companies like Atlassian, IBM Carbon, and Shopify Polaris. It makes linking from code comments to specific documentation pages straightforward. Group components only when they are conceptually inseparable, such as radio buttons and radio groups.

Step 4: Build a Foundation Page

Start with your colour foundation page. This is the most-referenced page in any design system documentation site, so getting the structure right early pays off.

In the Zeroheight editor, click Add block and choose Figma embed. Select the colour palette frame from your Figma file. Set the embed height so all swatches are visible without scrolling inside the embed.

Below the embed, add a Table block. Columns should include: Token Name, Hex Value, Usage, and Accessibility (WCAG AA or AAA pass/fail). For example:

Token Name      | Hex      | Usage           | WCAG AA
----------------|----------|-----------------|--------
color-brand-500 | #2563EB  | Primary action  | Pass
color-brand-300 | #93C5FD  | Decorative only | Fail on white

Adding the WCAG column here does two things. It stops developers from using low-contrast colours in error. It also gives your team a quick audit reference without opening a separate tool. Colour contrast failures account for roughly 30% of accessibility issues found in WCAG audits across digital products, according to the WebAIM Million 2025 report.

What about dark mode tokens?

If your system supports dark mode, add a second table block on the same page with the dark mode mappings. Use a heading like Dark Mode Overrides to separate the two tables visually. This prevents the common mistake of treating dark mode as a separate system rather than a token swap layer.

Step 5: Build a Component Page

Pick your most-used component first. For most product teams, that is the Button component. A complete Button page in Zeroheight should include these blocks in order:

1. Overview paragraph: one to two sentences describing what the component is and when to use it
2. Figma embed: all variants visible (primary, secondary, destructive, disabled, loading)
3. Usage guidelines: Do and Don't blocks using Zeroheight's built-in Do/Don't block type
4. Props table: list every prop, its type, default value, and description
5. Code snippet: the exact import and usage code from your component library
6. Accessibility notes: keyboard behaviour, ARIA roles, focus management
7. Status badge: a custom badge block showing whether the component is Stable, Beta, or Deprecated

A practical code snippet block for a React component looks like this:

import { Button } from '@your-org/ui';

// Primary action
<Button variant="primary" onClick={handleSubmit}>
  Save changes
</Button>

// Destructive action with confirmation
<Button variant="destructive" disabled={isLoading}>
  Delete account
</Button>

Zeroheight supports syntax highlighting for JavaScript, TypeScript, CSS, Swift, Kotlin, and several other languages. Select the language from the code block settings so the highlight applies correctly.

Step 6: Add a Component Status Table

A component status table on your Getting Started or Components landing page gives developers an instant overview of what they can use in production. Teams at Singapore-based product companies working across multiple squads report that a status table reduces "is this component ready?" Slack questions by more than half.

Create a table with these columns: Component, Design, Code, Accessibility, Notes. Use emoji or short text labels (Stable, Beta, Deprecated, Planned) for the status columns.

Component   | Design   | Code     | Accessibility | Notes
------------|----------|----------|---------------|---------------------------
Button      | Stable   | Stable   | Stable        | Includes loading state
Modal       | Stable   | Beta     | In progress   | Focus trap pending
DatePicker  | Beta     | Planned  | Planned       | Q4 roadmap

Update this table every time you publish a component change. Treat it the same way a development team treats a changelog.

Step 7: Configure Navigation and Global Settings

In Zeroheight, go to Settings > Navigation. Set your logo, brand colour for the sidebar accent, and default font. These settings apply site-wide. Matching the documentation site's visual identity to your product builds trust with new team members and external stakeholders reviewing the system.

Enable Search in the navigation settings. Zeroheight's built-in search indexes all text blocks on every page. A developer searching for "focus trap" or "z-index" should land on the right page within two keystrokes.

When should you password-protect the documentation site?

Password-protect when the documentation contains unreleased component designs, proprietary brand assets, or client-specific patterns. Make the site public when your team wants external contributors, open-source consumers, or job applicants to review the system. Many teams at Canadian and US-based agencies use a public documentation site as a portfolio signal during hiring.

Step 8: Publish and Share

Click Publish in the top right corner of the Zeroheight editor. Zeroheight generates a URL in the format https://zeroheight.com/your-styleguide-name. You can also configure a custom domain on the Pro plan, for example design.yourcompany.com, by adding a CNAME record in your DNS settings pointing to Zeroheight's servers.

Share the URL with your engineering team, your product managers, and your QA team. Pin it in your design channel in Slack or Teams. Add it to your project README files. The goal is to make the documentation the first place people check, not the last.

If you are working with a design or development partner, a published Zeroheight site significantly reduces briefing time. At Lenka Studio, sharing a client's Zeroheight documentation site at the start of a project typically cuts the component audit phase by one to two days, because the source of truth is already structured and accessible.

Frequently Asked Questions

Next Steps

Once your Zeroheight site is live, the next priorities are connecting your design token pipeline so token updates propagate automatically, adding a changelog page so teams can track what changed and when, and running a team walkthrough session so engineers and designers know how to navigate the documentation site.

If you are also building or refining your brand identity as part of this process, it is worth running a quick check on how your brand is performing before committing design decisions to a system. The free brand health score assessment from Lenka Studio gives you a structured starting point for understanding where your brand stands before you scale it into a full design system.

If your team needs help structuring a design system from the component library stage through to documentation and developer handoff, the team at Lenka Studio works with SMBs and product teams across Australia, Singapore, Canada, and the US to build systems that are actually used. Get in touch to talk through your project.