Clarity: Keen's First Design System
Built Keen's first design system, ensured consistency at scale across teams, survived a company rebrand, and reduced handoff time.
Keen.com is a high-traffic marketplace that connects users with spiritual advisors for live phone and chat sessions. The product organization is structured into pods, growth, acquisition, and research, that work independently and occasionally collaborate.
Read Keen: Leading Without the Title for the story on growth design and informal team leadership.
More consistent in code than in design.
Keen's pod structure created fragmentation as teams made independent design decisions without a shared source of truth.
Designers had no published library to work from. Some relied on personal files, others copied from previous projects, and many started from scratch. Meanwhile, front-end engineers had established reusable patterns, making the product more consistent in code, yet pages looked different depending on who designed them.
Alignment was inconsistent, text styles were hard-coded, accessibility wasn't part of the conversation, and new designers had to discover patterns on their own.
If designers need someone to explain how to use the system, the system itself isn't doing enough work.
Hired for growth. Asked to lead the system.
I joined Keen as a senior designer in the growth pod. A few months in, the UX Director approached me about leading a parallel initiative: building a centralized design system the company had never had. He pulled me into the work because of my design systems experience, which I'd flagged in my interview.
I proposed the approach: audit the existing components, audit accessibility, and build the foundation from the ground up using atomic principles. The mandate was confirmed, but with a real constraint attached. I would lead the system while continuing to ship growth work in parallel.
Built for distributed contribution from day one.
Because I couldn't be the full-time owner of every decision, documentation had to be thorough enough for designers to contribute without constant guidance.
I trained designers across the team, including a graphic designer transitioning into UI/UX. About 70% of the team had never worked with a design system before, which meant the documentation had to teach as well as enforce: shared naming conventions, weekly reviews with engineering, and embedded usage notes in Figma.
Contributors proposed components through Figma branches, with publish access reserved to me. The system was built to scale without me as the bottleneck.
I kept component library simple on purpose, so contributors could focus on designing instead of learning a complex system.
Atomic Design, capped at organisms.
Material 2 was the team's chosen visual framework, and engineering and design aligned on it from the start. We agreed on shared naming conventions across Figma and Storybook so handoff stayed straightforward.
Inside that, I structured Clarity using Atomic Design, capped at atoms, molecules, and organisms. I kept the component library simple on purpose, so the system stayed teachable and contributors could design.
The system adapted. The standards stayed.
Tokens for color, spacing, and typography were the system's source of truth. Components inherited from tokens, which meant a change at the foundation could propagate everywhere without rebuilding individual components. The token layer was where the system's flexibility lived.
Visual accessibility was held to WCAG 2.1 AA from the start: contrast ratios validated at the token layer, focus and hover states designed in, sizing and hierarchy built to be readable across devices. Engineering owned the code-side accessibility: semantic markup, keyboard navigation, screen reader behavior. Each layer had a clear owner.
Rebranded without rebuilding.
Mid-build, the company committed to a full rebrand led by an external agency. The brand work ran long, which left engineering and design less time to apply it across the product.
Because Clarity was built on a token foundation, the new brand could be applied through the system rather than component by component.
Legacy engineering pushed to keep the old branding until the legacy code was deprecated. We didn't allow it. The system held to a single standard across the product.
Marketing's pick shipped. Research changed it.
The rebrand introduced typography from marketing's asset specs that didn't translate cleanly at system scale. I proposed alternative sizes that worked across the product, but leadership chose to ship marketing's version.
Users soon began reporting readability issues. I scoped the research and a Senior UX Designer on the team ran it. The findings supported the sizing scale I had originally proposed.
The system was updated to the validated scale, and typography became a research-backed decision, not a stakeholder preference.
Jessi set up the foundational elements of the Design System and streamlined design operations, creating experiences that supported expansion and personalization. She also contributed to the UX Center of Excellence by coaching others.
Andrei Cabanban, Director of User Experience Design
- 40% reduction in handoff time between design and engineering, measured by the UX Director
- 90% reduction in duplicate components across the product, measured by the UX Director
- The system absorbed a full company rebrand without rebuilding components
- Adopted across the product's growth, acquisition, and research pods, with designers contributing components through Figma branches
- Mentored a graphic designer who grew into a junior UX designer contributing independently to the system
- Visual accessibility held to WCAG 2.1 AA from the foundation up, with token-level contrast validation built into the architecture
Clarity taught me that governance is the work, not the rules. Standards are easy to write. Getting them adopted by a team that's never worked with a design system is the actual work, and it has to happen through the system, not alongside it.
If most of the team is new to systems work, the documentation has to teach as well as enforce, the contributor model has to lower the barrier to participation, and the rules have to be visible inside the artifacts people use every day.
A system that requires explanation to be used correctly has not been designed yet.
