CASE STUDY
Volt Design System
From one heavy master file to a tokenized design system the EOS One team can actually find things in.
ROLE
Product Designer
TEAM
Design manager, contract designer, and me as system owner
PLATFORM
EOS One web app, all breakpoints
TIMELINE
2 Months
OUTCOME
Built Volt, EOS’s first design system, from a tokenized component library and per-feature Figma files. Design-to-dev handoff time dropped 40%.
01
Overview
As the newest designer on a team of three, I pitched a new way to organize our Figma work. That reorganization turned a loose page of components into Volt: tokens, components, patterns and guidelines for EOS One, built from an audit and shipped one feature at a time.
02
Problem
Every screen from past features and brainstorms lived in one giant, heavy Figma file, next to a page of library components from that period. Nothing kept the product consistent: there were no type patterns, and the same intent showed up in many shades, like three different reds in one simple flow.
As the product evolved and more designers joined, inconsistencies in layout, interaction patterns, and visual styles created friction for users and slowed the team. Developers were often rebuilding similar components from scratch. We needed a shared system that would bring clarity to the experience, streamline design-to-dev handoff, and help new designers ramp up quickly.
The team had components. It didn’t have a system.
03
Approach
Organize files by verticals
One heavy master file became light files per vertical, with a page per feature: the flow, a prototype, the components used, and the linked tickets. Designers and engineers, new or not, can now find everything connected to a feature in one place.
Files, pages and cover, before and after
How the EOS One Figma structure changed
Files: one per vertical
Before · one file
The whole product in one file
After · a file per vertical
Seven product files + the Volt Design System
Pages: grouped by the work they hold
Before · EOS One screens
Six pages · default layer names
After · Dashboard file
Thumbnail • Delivery • Discovery
After · continued
Exploration • Feedback • Working files • Archive
Cover: the same start for every flow
First frame of every story/feature/ticket/task
[Name of flow or story here]
User Story #??
Mark up Screens
Prototype
Miro Board Link
Designer:
[Name Here]
What the cover points to
User Story
Context and ticket link
Mark up Screens
Review
Prototype
Interaction
Miro Board Link
Board
Designer
Owner
Placeholders stay in brackets until a flow is filled in.
Detach the library.
Pulled the component page out of the master file, organized it and tokenized it. That became Volt.
Naming the system: Volt
The idea in three beats
How the name came together
The bulb was already there
The EOS logo is a light bulb, and the product already uses it for tooltips and the Learn about EOS documentation.
What would fuel it?
After some brainstorming, the question became what powers that bulb, in the same way a design system would fill the EOS ecosystem.
Volt
The energy that lights the bulb. Shared with the team as the name of the design system.
Approved, then built
All stakeholders approved the name, and the Volt library was created with it in mind from the first component.
The idea in three beats
EOS One logo
The EOS bulb
Volt,
what fuels it
Audit before fixing.
Logged every inconsistency: 25 colors mapped by use, and 16 text styles that resolved to only 10 font specs.
Audit before fixing
Real screens reviewed and logged first
Reviewing the real screens
Create Meeting · notes pinned
Reviewer notes, in the reviewer's words
H1 Font
Page title
Select Attendee
Dropdown field
Just have an icon here
Search field
Change Icon + Text Invite new
Invite action
Repeat Meeting?
Schedule field
Also flagged on the same page
Why so many different font-styles here?
Logged first: colors and text styles
25 colors mapped by use
Three reds for one intent
Typography audit, styles to specs
16 text styles resolved to 10 font specs
Five styles, one spec: Open Sans Bold 14
One audit across many real screens
Task modals
Create Meeting modals
Meeting History
Ship in increments.
Ship in increments
Fixes folded into the features they touched
Status badges for handoff
Grid and layout, six breakpoints
Grid table
Spacing
Old login
New login
04
Key decisions
DECISION 1
One naming convention for every color.
Every color became a token named --eos-color-[type]-[shade]-[color], grouped as Primary, Secondary, Accessible, System and Additional. The three reds each got one job: error toasts, accessible contrast and avatar backgrounds.
One naming convention for every color
Key decision 1
Standard, from the colors page
--eos-color-[type]-[shade]-[color]Example:--eos-color-primary-orange--eos-color-primary-dark-blueFive groups
Primary2Secondary11Accessible4System5Additional3 + 3 gradientsVolt colors page
Primary
Secondary
Accessible
System
Additional
The three reds each got one job: secondary-red for error toasts, accessible-red for contrast, secondary-light-red for avatar backgrounds.
DECISION 2
Fewer type styles, named by role.
Sixteen styles resolved to only ten font specs, and five of them were the same Open Sans Bold 14. I proposed eleven roles instead: H1 to H7, Body, Body Bold, Button caps and Caption.
Fewer type styles, named by role
Key decision 2
Old styles on the left, new roles on the right
Became
An earlier draft of the set
16 styles became 10 specs
Five of them were the same Open Sans Bold 14, so they collapsed into Body Bold.
11 roles
DECISION 3
Accessibility as a rule, not a review.
Colors that failed WCAG AA contrast came out of the system, like the gray once used for placeholder text in input boxes. An Accessible group gives designers contrast safe options by default.
Accessibility as a rule, not a review
Key decision 3
Accessible group, from the colors page
Accessible
--eos-color-accessible-red--eos-color-accessible-green--eos-color-accessible-yellow--eos-color-accessible-burntButton text test, from the buttons page
The first is the existing button. The next two changed text or fill until they passed.
05
Outcome
Live in Figma
Volt holds foundations, components, patterns and guidelines, plus page specific components for Meetings, Settings and Dashboard widgets.
Built into handoff
Status, notes and link components inside Figma show engineers what is ready, what changed and where the ticket lives.
Results
- Streamlined Cross-Functional Handoff: Cut the design-to-dev handoff timeline by 40%, aligning product and engineering teams around standardized components and clear technical specs.
- Amplified Engineering Confidence: Minimized ambiguity and downstream code rework by introducing predictable, accessible design systems that empowered developers to ship faster.
- Elevated UX Cohesion: Addressed fragmented interface patterns with a unified design system, directly resolving user-reported usability friction and creating a seamless product experience.
06
Leadership
DIRECTION
Pitched a new way of working.
As the newest designer, I proposed splitting the master file and linking every feature page to its prototype and tickets.
FOUNDATION
Built the system from the audit up.
Turned an audit of colors, type and icons into tokens, components and guidelines the team could build on.
TRUST
Made handoff self explanatory.
Added status, notes and link components so engineers could see what was ready without asking. "Love how it keeps everything organized and I know exactly what I need to focus on for my week!”
NEXT CASE STUDY
© 2026 Joao Medeiros