IC Product Designer + System Owner
Role
Sole designer on the system. Strategy, tokens, components, and rollout.
Timeline
About two weeks to build the system and align both products’ front ends.
Foundation
Chakra UI as the base, extended with custom and AI-native components.
Impact at a glance
faster design-to-dev cycle
releases with consistent UI
products on the system, one in stealth
WCAG 2.1 compliant
A founding design system that aligned two products before either shipped, and now shapes a third being built in stealth.
What I owned
UX audit, tokens, component API, accessibility, docs, and rollout across products.
What I didn’t
Backend, engineering implementation, and product scope.
Context
I joined as the first designer while engineering was building both products in parallel. Neither had shipped, and they were already heading in different directions with no shared foundation.
Parallel builds
Engineering was building both at the same time, with no shared base.
No source of truth
No shared tokens, patterns, or naming between them.
Comms gap
Every handoff meant translating a design into someone else’s components.
Audit
Before designing anything, I inventoried every component engineering had already built across both products.
button variants in the wild
type styles across products
one-off color values
Foundations
Tokens did more than enforce consistency. They became the shared language between design and engineering: one source of truth both sides could build from.
Color tokens
Every color starts as a raw hex value. That hex becomes a global token, the global token becomes a semantic token named for the job it does, and the component is built from that semantic token. Change the hex once and every element using it updates.
#1D5346
Raw value
green/600
Global token
success
Semantic token
Success
Component
Type scale
Spacing · 8px base
Components
I structured the system with atomic design: tokens compose into components, and components into full UI segments, so every product draws from one foundation.
Atomic structure
Semantic color tokens, the type scale, spacing values, and icons. The smallest building blocks, all mapped to Chakra’s theme.
Reusable form fields, button sets, and label-and-input pairs, built by restyling Chakra primitives to llmda’s brand.
Larger segments like cards, nav bars, and data-dense tables, composed to fit each product’s needs.
Usage dos and don’ts, accessibility notes, and responsive rules for every component.
Component library
AI-native patterns
Agent states
Components for what the agent is doing right now: drafting, checking sources, waiting on a person, or done.
Verification & sources
Every claim traces back to the source file it came from, so engineers can verify the work instead of trusting it.
Prompt prediction
Suggested next prompts, so people aren’t left staring at an empty input.
Adoption & handoff
I shipped the system into the repo using Figma-to-Cursor over MCP, so tokens and components landed in code directly instead of being reinterpreted from a spec.
Handoff
Tokens and components moved as code, not as a spec someone had to rebuild by hand.
Tokens
Design and engineering used the same token names, so one word meant one exact value.
Adoption
Both front ends were migrated onto the system, so new screens start from it instead of from scratch.
Reflections & trade-offs
The tradeoff
I pushed to delay one release by two weeks to build the system and align both front ends. That delay is why the team now ships every week with consistent UI.
The Chakra bet
Building on Chakra let me move fast, and custom components covered what it couldn’t.
What’s next
The system is already the foundation for a new product being built now.