Design Systems
One-off patterns, no shared source of truth, at every company along the way.
A documented system built or matured at each: a Figma library, an AI-integrated system, a ground-up build.
60% fewer inconsistencies (Vertex). 40% fewer revision cycles (Studio Designer). 20% less rework (Temeda).
Why This Is Its Own Story
I love design systems, unreasonably so. I’ve built and matured them across multiple organizations, and each one required a different kind of rigor, but the same underlying belief: a system isn’t just a component library, it’s shared language between design and engineering, and it only holds up if it’s documented well enough for someone else to use correctly without asking me.
Flagship 1: Figma Library & Accessibility (Vertex)
Vertex already had a design system going into this, but it needed real tweaking and updating to meet accessibility standards, not a rebuild from zero. Different product lines had different accessibility priorities, so this couldn’t be a single top-down mandate: it was led by a few of us who cared, and had to be communicated and coordinated across the whole design team rather than simply handed down. I led the design and architecture of that scalable, WCAG-compliant Figma component library, with accessibility built in from that point forward rather than retrofitted piecemeal. Design inconsistencies and downstream dev rework dropped by 60% across the teams using it.
Flagship 2: AI-Integrated System (Studio Designer)
Before this initiative, most new patterns got designed and built as one-offs: redone from scratch each time, with no single source of truth to check against first. I brought AI tools, Claude specifically, directly into fixing that, not just for prototyping, but for documenting and refining the system itself, and for training Claude on our own existing patterns so its output matched what we’d actually built rather than generic conventions. I also built a deliberate “lo-fi mode” into that process: AI-generated work defaults to looking finished, which sets the wrong expectation at an early stage, so keeping it visibly rough kept stakeholder conversations honest about what was still actually in flux.
That build-out came with real limitations too, and deciding what was worth solving now versus later mattered as much as what I built: the public marketing site, for instance, stayed on Elementor rather than getting pulled into the new system, since that wasn’t where the design-to-dev inconsistency was actually costing us. Cross-functional design revision cycles dropped by 40%, and the underlying library grew to 200+ reusable components, documented in Zeroheight and Storybook as a single source of truth.
Flagship 3: Building From Scratch (Temeda)
There was no existing system to extend. I had to get one off the ground entirely from zero, as the founding UX person on the product. That meant real build-vs-buy judgment calls: rather than build every foundational pattern by hand, I used the styleguides of established products (Uber, Google’s Material Design, IBM) as a working base, and standardized on a single external icon library rather than drawing icons from scratch, custom-drawing only the rare one the library didn’t cover. I also rolled it out slowly and deliberately, adding pieces one at a time rather than all at once, since a big-bang rollout would have been harder to keep consistent and maintained than a system that grew a little at a time. The resulting system supported 4+ distinct product lines and cut front-end rework by 20%.
Users
A design system doesn’t have just one kind of user. Engineers get speed: less time spent building something that already exists as a component. A multi-designer team gets consistency and faster design work, since nobody has to reinvent a pattern that’s already been solved. And when I’ve been the sole designer, the system has served a different purpose entirely: keeping my own thinking consistent and honest across a lot of ground, rather than reinventing the same pattern five different ways because I didn’t check first.
Reflection
I’m genuinely excited about where AI-assisted prototyping is heading, though I stay cautious about it: a fast prototype is only useful if it’s still tested and verified properly. I also feel fortunate to have a front-end development background running through all of this. It’s shaped how I think about systems from the start.