HZN Design System — Daniel Wu

Background & Challenge

Our delivery process used to be “PM writes the spec → designer draws mockups → engineer rebuilds it,” and something got lost at every handoff. Worse, every color or spacing change had to be made three times over — in the mockups, the spec, and the code.

The root cause was not that the mockups lacked detail; it was that the three roles never shared a single source. So I planned the HZN Design System: every design variable lives in one tokens.json, component styles share one SCSS codebase, and both PMs and engineers consume that same source directly. Change one file, and all three sides update together.

Design Decisions

tokens.json syncs to SCSS and CSS through a build script, giving designers, PMs, and engineers one shared source.

The HZN design system component library page: a categorized index of 40 components on the left, with form inputs, buttons, tags, and their various states on the right — The component library: 40 shared components across forms, data display, navigation, and feedback — each with SCSS, HTML examples, and a 'when not to use this' note.

Design decision

PM vibecoding: check boxes to build a prompt, then the AI reads the repo and generates the prototype

PMs walk through a five-step prompt builder, copy the prompt with one click, and paste it into an AI tool that can read the repo. The prompt hard-codes an instruction for the AI to read the component cheatsheet first, so the generated HTML prototype lands inside the right shell and matches the company’s visual language automatically — no designer “polish pass” required. The division of labor is drawn clearly: the first page is for validating an idea, and PMs handle it themselves; adding further pages means rewriting existing shell configuration, which stays designer-led. The cost is that PMs have to learn one AI tool — a deliberate trade-off that puts the complexity on the right shoulders.

Step five of the HZN prompt builder, an interaction-behavior checklist, with a side panel previewing the assembled prompt in real time and offering one-click copy — A PM completes the five-step prompt builder and copies the prompt; an AI tool then reads the repo and generates an HTML prototype already wrapped in the correct shell.

Outcome & Reflections

The tokens, component library, layout shells, prototyping workflow, and Theme Studio are all in place; the next step is running the full process on a real project. The effect compresses into one sentence: change one token and all three roles stay in sync — PMs stop waiting on designers, designers stop chasing engineers, and engineers stop guessing at design intent.

I also repositioned Figma: it receives tokens one-way only, serving the exploration and communication phase before any code exists. Once something is in code, the code is the only master copy — there is no reverse mirroring to breed a second source of truth.

Looking back, the most valuable part of this project was the process of making architecture decisions in collaboration with AI. Whether tokens should be split into two tiers, why the cheatsheet is the AI’s single source of truth, why the AI is asked to “read the repo itself” instead of having rules pasted into the chat — every decision was settled through back-and-forth debate with AI. A design system is fundamentally its rules and boundaries, not the look of its components; articulating those rules clearly enough that neither the AI nor any of the three roles can misread them is this system’s real deliverable.