Design System — Diana Kuzachenko
← All cases

Enterprise B2BDesign systemWiki & handoff

Growing a design system at an early stage

Joined when the base existed but did not cover new modules: added components, documented rules in an internal wiki — handoff became more predictable for engineering.

Component catalog: tokens, sidebar navigation, and live previews

Situation

The design system existed before I joined: base components and tokens were in place, but the product line grew faster than the library.

New dashboards, tables, forms, and configurators needed elements and states missing from Figma and wiki. My task was to evolve the system for real screens — not rebuild from zero — and make handoff and design QA predictable.

Task

The system could not keep up with the product:

Library gapsNew modules needed components and states not yet in Figma.
Unstructured wikiUsage rules, states, hierarchy, and handoff notes were not in one source.
Handoff via chatEngineering kept asking the same questions about spacing, states, themes, and behavior.
Light / dark driftComponents and states were documented unevenly across themes.
Design QA by memoryImplementation checks relied on team experience, not a document and checklist.

Make the system practical for new product modules: close component gaps, document usage and states in wiki, sync light/dark themes, move handoff from chat to a clear process, and use library + wiki as the basis for design QA.

Action

Audited the library and live screens, extended Figma components, documented rules in wiki, aligned with engineering, and packaged the same rules into an AI-readable HTML kit for new prototypes.

  1. Audited Figma library and new screens: where consistency broke, which states were missing, which handoff questions repeated.
  2. Extended the library with components and variants for operational UI: buttons, fields, status pills, dense tables, panels, form elements.
  3. Documented components in internal wiki: anatomy, usage rules, states, hierarchy, light/dark examples, handoff notes.
  4. Aligned rules with engineering and used wiki + library for design QA before module releases.
  5. Packaged the same rules into a portable HTML/CSS kit with an AI-readable component catalog — the team’s default for new clickable prototypes.

How new patterns enter the system

  1. Find a repeating UI pattern or gap on new screens.
  2. Check whether an existing component can be extended instead of creating a new one.
  3. Describe variants, states, and behavior.
  4. Add light/dark examples.
  5. Update wiki: when to use, constraints, how to hand off to development.
  6. Verify implementation via design QA checklist.

Figma library extension

20+ components and variants for dashboards, forms, dense tables, panels, status UI; documented states.

Input field variants from the live component catalog

Wiki as source of truth

Component descriptions, states, usage rules, light/dark examples, handoff notes in wiki.

Wiki page: anatomy, usage, states, handoff

Light / dark themes

Synced examples and state behavior for both themes; checked new screens for consistency.

Light / dark: same component, states

Design QA by system

New screens checked against Figma library and wiki; gaps logged by component, state, spacing, theme.

Design QA checklist

AI-assisted prototype library

Alongside Figma and wiki, I built a portable HTML/CSS component library from the same UI Kit rules — a machine-readable catalog, design tokens, layout patterns, and agent instructions so AI assistants assemble screens from documented classes, not ad hoc markup.

The kit includes a visual component catalog for designers and an AI contract (component snippets, variants, states). Designers on the team now use it to build new clickable HTML prototypes — faster and consistent with the system, without redrawing UI from scratch each time.

  • 31 components with variants in a machine-readable catalog linked to shared CSS
  • Tokens, layout recipes, and AGENTS rules for Cursor and other AI tools
  • Preview catalog to check light/dark and states before prototyping
  • Default workflow for new designer-led HTML mockups in the team
Button variants in the kit — hierarchy, sizes, icons, states
Layout recipe: dense table row with checklist and HTML snippet for AI
JSON mapping tab — machine-readable contract for AI-assisted layout

Result

20+ UI Kit components in wiki; 5 wiki sections for components, themes, and handoff; ~2× fewer dev handoff questions; 5 product modules shipped on UI Kit 1.1; design QA became predictable.

Built an AI-assisted HTML/CSS prototype kit from the same rules: 31 components, shared tokens, visual catalog, and agent instructions. Designers now use it as the default way to assemble new clickable mockups — aligned with Figma and wiki, without rebuilding UI each time.

20+Components / variants

Added for dashboards, forms, tables, panels, status UI.

2Themes documented

Light and dark — rules and examples for both.

5Product modules

Used updated library and wiki guidance.

~2×Fewer dev handoff questions

After wiki and component rules became the default reference for engineering handoff.

NDA

Anonymized case without product, client, production UI, or internal documentation. The system existed before I joined; my contribution is early-stage growth: new components, wiki, themes, handoff, and design QA.

Next case Get in touch