About Keen

Keen.com is a high-traffic marketplace that connects users with spiritual advisors for live phone and chat sessions. The platform’s value depends on the trust between users and the advisors they choose, and the product organization is structured into pods (growth, acquisition, research) that work independently and occasionally collaborate.

Before Clarity

Keen’s pod structure produced fragmentation as a side effect. Growth, acquisition, and research worked on different priorities at different speeds, and each pod made its own design decisions without a shared source of truth to anchor them. Over time, the gaps compounded.

In practice, designers had no published library to pull from. Some maintained personal “Design System” files, others copy-pasted from older project files. Most started from scratch. Front-end engineers had built informal reusable patterns, so the product looked more consistent in code than in design.

Pages on the same product looked similar or different depending on who designed them. Alignment varied, text sizes were hard-coded, and accessibility wasn’t part of the conversation. There was no path to onboard a new designer into existing patterns, because there were no patterns.

How The Work Came To Me

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.

A System That Could Not Depend On Me

Because I couldn’t be the full-time owner of every decision, Clarity had to be designed for distributed contribution from day one. Documentation had to be thorough enough that other designers could ship into the system without my supervision. The system was built to scale without me as the bottleneck.

I trained designers across the team to contribute, including a graphic designer ramping into UI/UX. About 70% of the team had never worked with a design system before, which meant the documentation and governance 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.

Building On Shared Foundations

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 abstraction shallow on purpose, so the system stayed teachable and contributors could design freely without learning a deep hierarchy first.

Tokens As The Source Of Truth

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.

Absorbing The Rebrand

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’s foundation was token-based, the rebrand could move through the system instead of being rebuilt piece by piece. Updating tokens at the foundation propagated the new brand across every component that inherited from them.

Legacy engineering pushed to keep the old branding until the legacy code was deprecated, but we didn’t allow it. The system held to one standard across the product.

When Typography Needed Research

The rebrand introduced new typography from marketing’s asset specs, which didn’t translate cleanly at system scale. I proposed alternative sizes that worked across the product. Leadership chose to ship marketing’s sizes anyway, and users started flagging readability issues.

I scoped the research to validate the sizing decision and a Senior UX Designer on the team ran it. The study used a mixed A/B comparison so participants couldn’t lazy-pick a single side, and the findings supported the sizes I had originally proposed. The system was corrected to the validated scale, and typography became a token-level decision tied to research, not stakeholder preference.

Outcomes

• 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.

• Visual accessibility was held to WCAG 2.1 AA from the foundation up, with token-level contrast validation built into the architecture.

What I learned

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 it enforces, 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 hasn't been designed yet.