BLING
Building the infrastructure that lets Bling ship faster
Alongside shipping features, I built the infrastructure underneath them: color and type systems, components aligned with code, a cleaner Figma workspace, and the processes and relationships that keep the system improving.
Design system
design operations
15 → ~4
new components needed per project
~5 → ~13
times teams updated an existing component instead of building a new one (2025 → 2026)
72 → 3
button variants, now covering 2,400+ combinations
86 → 13
unrelated color swatches replaced by accessible color families
Role
Owner, end-to-end
Team
Frontend, Product, Marketing
Timeline
January 2025 - ongoing
“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
Color
The new and old color systems applied to a banner component. The old palette was built ad-hoc, color-by-color without an underlying logic. This meant applying colors from a given palette produced unpredictable results.
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 palette that keeps Bling’s vibrancy while making accessible contrast and perceptual consistency come from the structure itself, not color-by-color checks.
What I did
Chose OKLCH for the new system because it makes contrast predictable. The hard part was the tension: brighter colors make contrast harder, and in RGB, colors at the same step look wildly different in brightness. I first tried mapping the old color library into OKLCH, but there was no logic underneath it to build on. Rebuilding from scratch let me hold lightness steady across hues and push chroma as far as each one could go while still passing.
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. Then they choose the role as a variable mode (e.g. success, danger, accent, etc.) The structure itself does the governing.
Result
Reliably accessible: one rule gives every component state AA contrast, with no hand-tuning
Vibrant and consistent: colors stay close to Bling’s look, and each step reads equally bright across hues
One source of truth: 86 swatches became 13 color families, one source of truth for product and marketing, so a change made once applies everywhere
Basis for CI guidelines: Bling’s brand guidelines were built on top of the system, not the other way around
Every family follows the same roles, so one component can switch between all 13 palettes and stay accessible in each.
Typography
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.
Variable modes instead of component properties
Using variable modes, I moved from a 72-variant component-set to a 3-variant component set that can be configured into more than 2400 variants.
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,400+ combinations without detaching the component instance.
Component alignment
I started with naming alignment to reduce guesswork for design and front-end, and to start enabling AI tools to more easily work with our system.
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.
Workspace
I moved us from one large, slow file containing all of our features, to files grouped by app surface and sorted by production stage.
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.
Process
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