Design Systems
Building an agency’s first design system.
- Designed to serve both designers and developers across multiple client brands.
- Enabled a full-site external dev build from the Figma file alone, with no team-context handoff needed
- First design system at the agency, built solo while delivering active client work
- 32 components organized using the Atomic Design methodology
- Full documentation embedded in the Figma file for every component and system rule
Problem
The agency had no design system.
Every project started from scratch. The same patterns were rebuilt every time, and every handoff started over. Three problems compounded:
No shared baseline for client edits
Client revision requests had no consistent design to edit from. Every change touched a different version of the same pattern.
No shared standards across designers
Designers using each other’s files could not predict structure or naming. Inheriting a project meant relearning it.
No handoff structure for developers
The existing Figma file was built for prototyping, with components broken up to support live interactions. Developers had to reverse-engineer the design every time, which slowed implementation and introduced errors.
The root cause was structural. The team was treating every project as a one-off. The cost compounded with every new client.
Approach
Functional for designers and developers
I treated this as a systems problem with two audiences. Designers needed flexibility to absorb client brand variation. Developers needed legibility to build from the file without translation. I built the system to serve both.
I organized the system using the Atomic Design methodology, structuring components from atoms through pages. I built the system in parallel with active client work, so it had to be useful immediately, not after months of foundational setup.
System
Foundations and Tokens
I built the system on tokenized foundations: color, typography, and spacing on an 8px base. Tokens were structured so each client brand could swap the surface layer without rebuilding the structure underneath.
Color used a role-based naming convention: primary, secondary, tertiary, and three accents. Typography used five heading levels (H1 through H5), each with style variants (default, special, small, medium, large) and text-transform options.
Per-client flexibility: Color and type tokens swapped per client. Spacing and structural tokens stayed constant across all builds.
Component reuse: Some components were reskinned through token changes alone. Others were rebuilt when a client’s brand required structural differences.
Outcome: A foundation that absorbed brand variation without rebuilding the system underneath.
Components
What I built
I built 32 components, designed for reuse across multiple client brands. The highest-impact ones, used on every site, were the hero, navigation, footer, buttons, forms, gallery, and accordion.
Variants, not duplication
Each component used Figma variants to absorb state and style variation. The button was the clearest example. Instead of building separate components for every size, style, and state, I built one component with variables for size, fill, label, and state. The library scaled instead of expanding into near-duplicates.
State documentation
I documented hover, focus, disabled, and error states for buttons, the gallery, and the accordion. Other components used the same patterns but were not formally specced.
Content flexibility
Content limits were left to designer judgment rather than enforced in the components. The system traded strict guardrails for client-brand flexibility, which the agency context required.
Outcome: A component library that handled multiple client brands without component sprawl
Results
The system enabled the agency to scale
The external developer engagement proved the most important outcome: the system enabled the agency to scale capacity without adding internal headcount. Before, every project required the in-house team. After, the system made clean external handoff possible.
The system handled brand variation across multiple client projects without rebuilding. The token structure made client swaps fast and the component library scaled instead of duplicating.
By the time I completed my engagement, the system stood as the agency’s documented foundation for design and development work.
Handoff
Designed for developer handoff
I designed the system for developers from the start, not as an afterthought. The existing Figma file at the agency had been built for prototyping, with components broken up to support live interactions, which left the file unusable for handoff. I built the new system so it could serve both purposes: clean enough to develop from, structured enough to prototype with.
File structure and conventions
I followed the Atomic Design methodology, organizing components from atoms (text, color, spacing) through molecules (buttons, inputs, forms), organisms (header, hero, testimonial slider), templates, and pages. Layer and frame names followed consistent conventions. Auto layout was used throughout. Every page had a status flag (In Design, Internal Review, Client Review, Ready for Dev, In Development, Blocked, Prototype) so anyone opening the file knew at a glance what they were looking at.
ReadMe files
Each component had a ReadMe inside the Figma file covering specs, interaction behavior, naming conventions, and usage guidelines. I also wrote system-wide ReadMes for the master template, the design system overview, breakpoints (mobile, tablet, desktop), and the spacing scale (1rem = 16px base). Developers did not need to ask how a component should behave. The answer was already in the file.
The proof point
In April 2025, the agency hired an external developer to build a full client site. He had no prior team context. I sent him the Figma file. He shipped the full site on a $2,000 USD fixed contract, working from April to July. The system made the handoff work without my involvement.
Outcome: A design system that made design output legible enough for any developer, internal or external, to build from without hand-holding.