BLING
Role: Owner · Timeline: January 2025–ongoing · Worked with: frontend, product, marketing
15 → ~4
new component tickets per project (the first project, compared with the average of the 8 since)
~5 → ~13
tickets updating existing components (2025 → 2026), as teams reuse instead of rebuild
72 → 3
button variants, now covering 2,000+ combinations
86 → 13
color swatches replaced by accessible color families
“In the past every feature had completely new components with slightly different variation, and that’s something we will not do anymore.”
— Sebastian, Frontend lead · Bling
Problem
The palette had, over time, Frankenstein’ed into 86 swatches in 13 groups with no shared logic and no corporate identity to anchor them. Several had hex codes that didn’t match the colors shown. Product and marketing drifted apart, and no accessibility was built in despite Bling’s BFSG obligations.
Goal
A system where the right color is obvious and accessible contrast comes from the structure itself, not color-by-color checks.
What I did
Chose OKLCH for the new system because it makes contrast predictable. I first tried mapping the old color library into OKLCH, but there was no logic underneath it to build on.
Rebuilt it as 13 color families of 12 steps each, staying as close to Bling’s existing look as the system allowed
Replaced Figma styles with variables linked to one foundations collection, for product and marketing alike
Made picking a color paint-by-numbers: designers choose a role (background, border, text, fill), then a step within it, never a hex value. The structure itself does the governing.
Result
One source of truth for the whole company, so a color changed once changes everywhere, which ended the brand drift. Every component state passes contrast without hand-tuning, and Bling’s brand guidelines were built on top of the system rather than the other way around.
Problem
Text styles: 15 text styles, and not one line height landed on the 4px grid that keeps layouts aligned.
Source of truth: Text styles lived in App Components instead of our source of truth for foundations, Design System.
Goal
The same consistency as color, on a smaller scale.
What I did
• Rebuilt the set as three roles: display, headline and body
• Sized display and headlines on a 1.25 scale from 16px
• Calculated every line height from its font size, tighter for display and looser for body, then snapped it to the 4px grid
• Reconstructed the type styles library in our Design System file
• Used library swap to remap all bound text styles across Figma to our Design System library
Result
10 styles, every line height on the grid.
Problem
Governance: Design systems are hard to govern on the design side because designers tend to prioritize UX and UI over technical alignment. This leads to inconsistent UIs, redundant building, system bloat, messy hand-offs, and frustrated engineers.
UI flexibility: “Everything is possible” is a common refrain from our engineers. Not so from our designers. Certain component sets need to support more variants than is reasonable to create and maintain in Figma. Our button component had 72 after trimming the fat.
Goal
Build a self-governing system that enables designers to build smaller component sets the way our engineers do.
What I did
Set up variable collections and modes to handle switching between multiple component properties at once, all built on our token foundations.
Result
More flexible components built with very little guesswork in much smaller component sets that are much more closely aligned with engineering. The button went from 72 hand-built variants to 3 that can be configured into 2,000+ combinations without detaching the component instance.
Problem
Design and frontend built their component libraries separately as the team changed: 152 components in Figma and 116 in code, with mismatched names and builds. Every handoff involved guesswork.
Goal
Bring components in Figma and the code base into closer alignment
What I did
Established naming conventions with front-end
Stored all design tokens used by front-end as variables in Figma using the same naming
Used Claude to inventory both component libraries into a 218-row tracker
Started with naming alignment so the team and AI would no longer have to guess what corresponds to what
Deprecated legacy components; merged duplicates; moved single-feature ones out of the global library
Result
Most names now match. Cleanup and structural alignment are ongoing.
Problem
Bling’s Figma workspace hadn’t scaled with the company. Every feature lived in one giant file and every new build in another, both of which became slow and out of sync with what had actually shipped.
Goal
One structure that every team (product, marketing, new joiners) could navigate and trust, inside a single shared workspace, since our Figma plan doesn’t allow splitting by team.
What I did
Tried one file per feature first, which traded one problem for another: 27 files with no shared structure
Ran workshops and whiteboard sessions with everyone who uses Figma
Grouped product files by app surface, for example funnels & paywalls and financial features
Gave every file the same stages: Design → In Development → Deployed
Worked with PMs and front-end to create a new handoff procedure
Set up separate Exploration and Archive projects to keep the app project free of clutter
Result
Design and development no longer guess which state a project is in; files load faster; and PMs now have a clear overview of business-critical flows like funnels and paywalls that didn’t exist before.
Problem
Prioritization: Stakeholder buy-in is difficult for design systems and our system needed a lot of work
Maintenance: Old habits die hard. Without the right structural changes in place, all this work falls apart.
Goal
Create the right habits and infrastructure to ensure transparency, ongoing collaboration, and adherence to best practices
What I did
Dedicated 1 hour every morning solely to design system work
Worked with lead FE engineer to designate a design systems counterpart on the engineering team
Set up a weekly design system sync with said engineering counterpart
Set up a dedicated design-system-taskforce Slack channel between front-end engineers, creative stakeholders, and me
Result
Steady design system progress where none existed before and the design system becoming a consideration for all stakeholders when building.
Read next case study