Design Systems/Vertex · Studio Designer · Temeda/Cross-Career Theme

Same Discipline, Three Completely Different Starting Points

I love design systems, unreasonably so. I've built and matured them across multiple companies, each requiring a different kind of rigor, but the same belief underneath: a system is 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.

01 Approach 02 Vertex 03 Studio Designer 04 Temeda 05 Reflection
01 / Beyond Components

A system people can reason about, not just borrow from.

My front-end background means this isn't guesswork. I understand how components need to be structured to hold up in code, and how naming, hierarchy, and relationships need to be organized so a system stays legible as it grows.

In every system I've built, I've gone past just shipping components: patterns, not just components (form patterns, button-grouping patterns, modal patterns), and usage documentation that explains not just how something works but when to use it. That's the difference between a component library and an actual system people can reason about.

02 / Flagship: Figma Library & Accessibility (Vertex)

Accessible from the start, not retrofitted later.

I led the design and architecture of a scalable, WCAG-compliant Figma component library, with accessibility built in from the start, contrast, focus states, responsive behavior across devices, rather than retrofitted later. My front-end background made this more effective, since I understood not just how a component should look, but how it needed to behave and hold up in code.

Measurable impact −60% design inconsistencies & dev rework
03 / Flagship: AI-Integrated System (Studio Designer)

Prototypes fast enough to keep the conversation moving.

I brought AI tools directly into the systems workflow, using them to get prototypes functioning close to the intended flow, faster than building every state by hand. Visual variations clearly signaled fidelity level, low-fidelity versus more resolved, specifically to keep stakeholder conversations honest about what was still in flux versus what was closer to final.

Measurable impact −40% revision cycles · 200+ components documented
04 / Flagship: Building From Scratch (Temeda)

No existing system to extend, so I built one.

At 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: pulling reference patterns from other companies' style guides where it made sense, evaluating whether to adopt an existing system outright rather than build everything by hand, and being deliberate about which parts were worth building custom versus sourcing, so the result wouldn't become an unmaintainable one-off.

Measurable impact 4+ product lines supported · −20% front-end rework
Image: Storybook documentation screenshots
05 / A Recurring Pattern

The same discipline, components, patterns, documentation, accessibility, increasingly AI-assisted workflows, shows up across every one of these roles. I'm genuinely excited about where AI-assisted prototyping is heading, though I stay cautious: a fast prototype only helps if it's still tested and verified, not treated as a substitute for that step.