The design system that ships itself.
How the ZenDocs design system became a machine-readable AI skill: one encoded source of truth that any teammate, or any AI tool, builds on-system with. The 14-surface redesign and this portfolio are both outputs of it.
Counts are verifiable from the artifacts on this site: the redesigned surfaces appear in the ZenDocs case study, and this page itself renders on the system's tokens. Org-wide adoption metrics are internal and not yet published.
- The move: the design system stopped being documentation and became an executable skill: tokens, component specs, page patterns, and interaction rules encoded so AI tooling produces on-system output by default.
- The proof: 14 interactive ZenDocs surfaces prototyped in days rather than weeks, and this portfolio, running on the same encoded system.
- The honest part: a skill is only as good as its governance; what is measured, what is not yet, and what breaks without an owner.
Design systems decay as documentation.
Every design system I have built or inherited had the same failure mode: the artifact was documentation, and documentation is passive. It waits to be read, it drifts from production, and every handoff is a retelling. The Part I audit of ZenDocs found exactly this: an off-token primary blue running in production was the highest-severity visual finding. The system existed; the surfaces had stopped listening to it.
AI tooling changes the failure mode. If the tools that generate interfaces can read the system directly, the system stops being a reference and becomes a constraint. The question was how to encode it so that output is on-system by default rather than by discipline.
The system, written for two readers.
The skill is the ZenDocs design system condensed into a structured, machine-readable document with four layers: foundations (type scale, color tokens, radii, shadows, the glass recipe, spacing rails, motion), component specs (buttons, inputs, navbar, cards, modals, the TOC rail), page-level patterns (the tool funnel order, directory structure, form landings), and interaction rules that travel with everything built on it.
A short excerpt, verbatim:
### Glass (signature effect) - Recipe: background: rgba(242,242,242,0.62) + backdrop-filter: blur(25px) - Used for: nav dropdown panels, mobile menu sheet, modal backdrops ## 4. Interaction rules - Every overlay closes on outside click and Escape - Active/selected state = blue text/border + soft blue fill - Buttons that aren't wired show a toast rather than doing nothing - Copy tone: plain, benefit-led, sentence case; no exclamation marks
The last layer matters most. Encoding copy tone and interaction behavior next to color means voice and behavior cannot drift independently of the visuals, which is where most systems quietly die.
One loop: govern the source, generate the surfaces.
Two products you can inspect right now.
Fourteen interactive surfaces, from the home to the PDF editor, prototyped in code in days rather than weeks, every one on-token. The full walkthrough is in the ZenDocs case study.
The site you are reading runs on the same encoded system: same tokens, same interaction rules, same copy tone. The unwired-button toast rule from the skill file is live in the ELIAS Studio reconstruction.
Two UX engineers on my team build design work in code against the skill; I direct and sign off their output, so review happens against the system, not against taste.
The audit finding that motivated the encoding (an off-token primary blue in production) is now structurally hard to reintroduce: tooling that reads the skill does not know the wrong blue exists.
What this is not, yet.
Adoption is qualitative for now. The skill is used across the org, but I have not yet published time-saved or consistency metrics with clean baselines. The next revision ships with instrumentation: surfaces audited per quarter, token-violation counts, time from brief to on-system prototype.
A skill without a governor rots like documentation does. Encoding does not remove the ownership problem, it concentrates it. The system stays healthy because sign-off still runs through a person; the skill just makes the approved decision the cheapest one to reproduce.
It constrains; it does not decide. The skill guarantees on-system output. It does not choose what to build or whether the funnel framing is right. That remains design judgment, which is the part I am actually hired for.