My Works
Torus Design System
The design system wasn't broken. The system of using it was.
Role
Product Designer
Timeline
Sep – Dec 2025
Tools
Figma · Notion
Impact
11 Components
WCAG AA
The Problem
The ask was accessibility. The real problem was trust.
THE BRIEF
Make the design system accessible. Two months. Go.
WHAT I FOUND
The accessibility failures were real. But they weren't the root problem.
After auditing the production environment against the existing Figma library, I found something more fundamental: the design system wasn't being used. Engineers were building their own components on the fly. Designers couldn't agree on which pattern to use. The library existed — but it had no authority.
Fixing accessibility on top of a system nobody trusted would only create compliant components that nobody used.
The real problem was adoption. Accessibility was a symptom.
Before
The Diagnostics
Five failures. One root cause.
01
Incoherent Variants
Components built ad hoc, with no shared visual logic.
02
Pattern Duplication
The same interaction pattern existed in three different forms.
03
Semantic Conflicts
Buttons used as links. Links styled as butons. No rules.
04
A11Y Failures
No keyboard navigation. No ARIA labels. No focus states.
The Decision
I chose to fix the foundation first.
Accessibility was the ask. But I made a call: if the system itself wasn't trusted or used, compliant components would just become compliant noise.
I expanded the scope — without being asked to. Instead of patching the existing library, I rebuilt it from the ground up: complete interaction states, usage guidelines, semantic rules, and accessibility specs embedded directly into each component.
The risk was real. Two months is not a lot of time to rebuild a system. I prioritized ruthlessly — 11 components that covered the highest-impact patterns across the platform, nothing more.
This wasn't just a design decision. It was a bet that a system people could understand and trust would do more for accessibility than any audit ever could.
The System
A system that teaches itself.
Every component ships with its own instructions. Developers don't need to ask. Designers don't need to guess.
01
The Framework
Every component in Torus is documented across three layers: usage, specs, accessibility.
This structure isn't cosmetic. It's a contract between design and engineering.
02
Semantic Foundation
Buttons trigger actions. Links navigate pages. These aren't style choices — they're structural rules. Before Torus, both were used interchangeably. I established a strict semantic distinction and documented exactly when to use each — with visual examples built into the component itself.
03
Accessibility Architecture
Accessibility in Torus isn't a checklist. It's embedded into the component spec itself. Color contrast ratios, keyboard tab order, and ARIA labels are defined at the component level — not added after the fact.
04
Interaction States
A component without states isn't a component. It's a sketch. Every element in Torus ships with Default, Hover, Focus, Pressed, and Disabled states — the complete set needed for keyboard and assistive technology users.
05
Self-Documenting
The documentation lives inside the component. Usage rules, logic notes, and accessibility specs are embedded directly in Figma's component panel — so the system works without a meeting, a Slack message, or a handoff doc.
The Impact
11 components. Zero guesswork. Adopted in 8 weeks.
11
Foundation components built and fully documented
WCAG AA
100% coverage across all 11 components
10+
Designers and engineers adopted the system
8 weeks
From audit to delivered system
Jessica Fortunato
Senior UX Designer, OLI
Heather
Senior UX Designer/Accessibility Mentor, OLI
Reflection
What I'd do differently.
This project taught me that a design system's biggest challenge isn't technical — it's organizational. Building components is the easy part. Building something other people will actually follow is the real work.
If I had more time, I would have tested the system itself — watching designers and engineers use my documentation to build something new, without asking me a single question. That's the real measure of whether a design system works.
I also would have gone further on the engineering side. The accessibility specs I documented were designed to map directly to code — but I didn't have the bandwidth to validate that handoff with the dev team. Connecting Torus to a Storybook implementation would have been the next step.
