Keelworks: Design System
Enterprise SaaS · B2B
KeelWorks runs an internal design system shared across 3 teams, each building a separate product, to keep everything visually and functionally consistent.
But by the time I got involved, nothing was governed and reused. Teams just rebuilt what they couldn't find.
I pushed to convert it into a token-based system: one shared source of truth that every component, in every team, would trace back to.
The system existed. Nobody could find it.
Across 3 teams, components were duplicated, naming conventions varied by team, and design-to-development handoff was slow and inconsistent.
Rather than search for a component that might already exist, teams simply rebuilt it, compounding inconsistency across the platform with every new duplicate.
Same intent, filed under different names, built several times
One source, not three versions
Instead of patching individual components, I rebuilt the system at the root: tokens first, everything else inherited from them. A single source of truth: token-based, documented, and built to be found.
Reduced duplicate design tickets across the 3 teams and improved ease of finding components.
With no dedicated team or time, I chose speed and adoption over purity
Rather than rebuild every component from zero, I extended the existing internal KeelWorks library and set one rule to keep scope honest: a component only got added if 2 or more teams actually needed it.
One token, not one hardcoded value. Repoint it, everything updates
Setting up a solid token structure
The system was built white-label from the start, to serve all 3 teams. KeelCompass is the first brand running on it, the architecture is ready for the next.
To fix duplication, I set up tokens. Every property that used to be hardcoded per team (color, type, spacing, radius, elevation, icons) now lives in three layers instead of one flat value:
• Primitive: raw values
• Semantic: meaning-based tokens
• Component: specific overrides when needed
One token, different brand. Swap the mode, not the file
Iconography
Icons had the same duplication problem as everything else, inconsistent style, no shared grid. I rebuilt them on a single 24px frame with a 20px live area and consistent keyline construction, so every icon shares the same proportions and stroke logic instead of being redrawn per team.
Accessibility
Color tokens are set to pass WCAG AA and AAA contrast, interactive elements meet a 44px minimum touch target, and destructive actions follow a consistent, safer pattern.
Every atom traces back to the same source
A team no longer builds its own version of a component. It inherits one, automatically consistent with everyone else's, built on the tokens defined in Foundations.
Composed, not duplicated
Components are built from the same governed atoms. A feature built today inherits consistency automatically, each piece already knows how to handle its own states.
Documentation alone wasn’t enough to drive adoption
Everything is documented, but documentation didn't get 3 teams to actually change how they worked, pushing did:
• Flagging non-system components in design reviews across all 3 teams
• Weekly adoption updates in the team channel
• Direct walkthroughs with the frontend team.
What started as uncomfortable became the default.
Shipping faster with less friction
Delivery slowed briefly as teams adjusted, then sped up past baseline. QA and alignment effort dropped too, most inconsistencies were caught upfront instead of in review, and other teams took notice.
• Duplicate design tickets dropped across the 3 teams once the system shipped.
• In a follow-up survey, teams rated ease of finding components 4.5/5, the exact problem the system was built to solve.
Key Learnings
• Building the system taught me tokens. Shipping it taught me change management.
• The hardest bug wasn't in Figma, it was getting people to trust something new enough to stop working around it.
