Giving a growing design system one direction
While at Columbia Business School, I joined BetterHelp as a Summer Associate on the design system team. The system supports a 15+ person design team and a platform with more than 340,000 users. The team had momentum, but we needed to measure it. I saw the gap, made the case for OKRs, and led 8 designers, engineers, and product partners to align on one objective. I also built and documented 10 core components, getting the system ready for teams across BetterHelp to build with AI.
340K+
Monthly users on the platform
15+
Product designers building with the system
10
Components built and documented
8
Cross-team partners aligned
BetterHelp’s VPs believed anyone at the company should be able to build with AI, and the design system would make it possible. The design system team was moving fast. In six months, it had added 3 designers, 3 council developers, and audited more than 36 components, but no one had agreed on what success looked like. Every request felt equally urgent. With AI about to build from the system, the cost of not having a priority would only grow.
I made the case to Chris Ko, product design manager, that the team needed one shared priority before it could scale. With his support, I brought design, engineering, and product together to choose it.
I designed a workshop where the team explored the system’s biggest strengths and gaps. Then each person wrote success stories for three pillars—velocity, quality, and reliability—describing what each would look like in a teammate’s day-to-day work.
By the end of the exercise, all three pillars were covered in good ideas, but the team couldn’t chase all three. I gave everyone two votes and asked them to pick where to start.
Reliability won. I turned the team’s success stories into a draft objective and a set of signals the team could measure, from Figma-to-code parity to fewer repeated questions in Slack. Chris used them to draft the team’s first key results.
When building a component, the hardest decision was what a component should not do. I studied how designers and engineers already used it. While some of what I found were real needs, much of it was workarounds for gaps the system hadn’t filled yet.
For example, designers used our Tag component as a button. I could have made Tag flexible enough to allow it, but then users couldn’t predict what a tap would do, and designers would have two components for one job. I set a boundary: actions belong to Button. Tag became two variants, Selectable and Removable. I made calls like this across 10 components. Each option I left out made the right choice clearer for both designers and for AI tools.
By the end of the summer, the system was ready. Veronica Erick, a design systems lead, built the first draft of an internal AI tool that let anyone at BetterHelp prototype ideas with our components, no design background needed.
