Building a Token-Driven Cookie Consent System for a US Startup
Overview
I worked at Monks as a Senior Product Designer supporting a US-based privacy startup that was building a configurable cookie-consent platform for SaaS companies.
Their product was not a simple banner. It was a white-label consent engine where each customer could configure:
Colors
Fonts
Logos
Legal text
Consent categories
All of this was controlled through their own platform and rendered dynamically on client websites.
My responsibility was to design:
The cookie banner
The preferences modal
And, most importantly, the token-based system that connected design and engineering.
The Challenge
The engineering team had already defined a token-driven theming system.
Every client brand would be expressed through:
Color tokens
Typography tokens
Spacing and radius tokens
The UI was not allowed to use fixed colors, fonts or layouts.
Everything had to come from tokens.
So the challenge was not “design a banner”.
It was: How do you design a fully brand-agnostic UI that can be skinned by any customer through tokens, without breaking usability or accessibility?
My Role
I worked as the bridge between:
Product and legal requirements
The engineering token system
And the actual UI components
I was responsible for:
Translating the dev team’s tokens into Figma variables
Designing the banner and preferences modal
Creating a token-mapped component library
Using AI tools (Figma Make and Cursor with Figma MCP) to generate, validate and evolve the first working versions of the components
Designing the Token Architecture in Figma
Instead of starting with visual design, I started with token mapping.
The engineering team already had:
Brand tokens (colors, fonts, spacing)
Semantic tokens (background, text, action, border, etc)
I recreated this structure in Figma using Variables:
Base tokens
Raw values for:
Color palettes
Font families
Sizes
Spacing
Border radius
These were never used directly by components.
Semantic tokens
Things like:
surface.canvas
surface.elevated
text.primary
text.secondary
action.primary.background
action.primary.text
These represented meaning, not style.
Component tokens
Mappings like:
cookie.banner.background
cookie.modal.surface
cookie.button.primary.background
cookie.toggle.active
Each component only referenced these semantic tokens.
This meant any customer brand could change the entire UI by changing token values.
Designing the Banner and Preferences Modal
With the token system in place, I designed two main surfaces:
Cookie Banner
A compact UI that:
Displays legal copy
Shows consent actions
Respects brand colors and fonts
Works with very long or very short text
Preferences Modal
A more complex surface that:
Lists all consent categories
Allows toggling each category
Displays legal descriptions
Works across different layouts and screen sizes
Because everything was token-driven, both surfaces could adapt to:
High-contrast brands
Minimal brands
Dense or light typography
Different logo shapes
Without changing a single component.
Using AI to Prototype a Real Product
To avoid static mockups, I used:
Figma Make
Cursor connected to Figma via MCP
This allowed me to:
Generate initial component structures
Create interactive banner and modal behavior
Simulate real states (open, closed, preferences, toggles, hover, etc)
Rapidly iterate based on engineering feedback
This served two purposes:
Validation: product and legal teams could see how the system behaved
Implementation guidance: engineers could understand how components were supposed to work in real life
It effectively became a design-side implementation of the product.
Outcome
At the end of the project, the startup had:
A fully token-driven cookie banner
A configurable preferences modal
A design system that mirrored their engineering architecture
AI-generated prototypes that matched how the real product would behave
The result was not just a UI, but a scalable privacy interface platform.