- Role
- Co-lead designer, with two senior designers
- Timeline
- Ongoing since January 2026
- Team
- 3 designers, 4 front-end engineers
- Tools
- Figma
- Storybook
- Tokens Studio
- Notion
Impact
- documented components in Figma and code
- 48
- of core components meet WCAG 2.2 AA contrast
- 100%
- less time from handoff to build, as estimated by our engineers
- 40%
01
The problem
When I joined Crewline, the app had eleven shades of gray, seven button styles and three different date pickers. Every designer kept their own Figma library, and engineers rebuilt the same components in slightly different ways.
The inconsistency was more than cosmetic. Accessibility issues were scattered across the product, and every new feature took longer than it should because nothing could be reused with confidence.
02
What I did
We began with an audit. I screenshotted every screen in the mobile app and the manager dashboard and grouped the elements on a giant FigJam board. Seeing 23 versions of a list row side by side made the case for a system faster than any presentation could.
From there, I worked with two senior designers to define tokens for color, type, spacing and radius, then rebuilt our most used components on top of them. We paired with engineers every week, so each Figma component had a matching coded component in Storybook with the same name and the same options.
I owned accessibility for the core set: contrast checks on every token pair, visible focus states for every interactive element and touch targets of at least 44 by 44 points.
03
The solution
Tokens first
Every color, size and spacing value comes from a named token, so a change in one place updates Figma and code together. Dark mode, which had been planned for “next quarter” for two years, became a token swap.
Documentation people actually read
Each component page answers three questions: when to use it, when not to, and what it looks like in a real Crewline screen. Examples beat long lists of rules.
A way to contribute
Anyone can propose a new component through a short template. We review proposals every Friday, which keeps the system growing with the product instead of becoming a bottleneck.
04
What I learned
A design system is a product with its own users. Our engineers were those users, and the system only gained traction once we started treating their feedback like any other user research.
I also learned that consistency is a social problem as much as a visual one. The most valuable thing we built was not a component but the Friday review, where designers and engineers make decisions together.