DOJ Design System — creating a shared foundation for onsistent, accesible legal tools.
I led the strategy, component architecture, and cross-team governance behind a new enterprise design system for the Executive Office for Immigration Review (EOIR). It replaced years of fragmented, one-off UI work with a single shared foundation — cutting front-end development time by 85% while meeting strict federal accessibility standards.
Impact
• Cut front-end feature delivery time by 85% — core layouts that took days now take under 30 minutes. • Reached 100% compliance with Section 508 federal accessibility standards. • Removed 90%+ of UI and code duplication across legacy and modern applications. • Built a lasting governance workflow that keeps design and engineering aligned as new features ship.
Deliverables
Agency-wide, spanning EOIR's core judicial applications and serving hundreds of immigration judges, legal staff, and engineers.
Year
2022
Role
Lead Product Designer & Design System Architect
Context — replacing fragmented judicial UI with one shared foundation
EOIR, a sub-agency of the Department of Justice, runs high-stakes removal proceedings and appeals. The internal tools judges relied on had grown inconsistent over time — different visual styles, different interaction patterns, and a mounting pile of technical debt across applications. My job was to build one design system that could scale across all of it and make development faster along the way.
Research system — auditing every pattern before designing new ones
I started with a full audit of the existing product ecosystem — hundreds of live screens across legacy and modern apps — to catalog every layout pattern, component, and interaction in use. From there, I worked directly with engineering leads and the Director to align the system with EOIR's Angular 7 architecture. I built the foundation: a 12-column grid, a 4px/8px spacing scale, accessible type and color tokens. Documentation was split into three parts — Style, Usage, and Code — so designers and engineers could each find what they needed. Then I ran velocity experiments with engineering squads to prove the system actually saved time, and set up an ongoing governance process to keep it that way.
Core breakdown — inconsistent interfaces slowed judges and engineers
Inconsistent UI patterns were adding real cognitive load for judges making life-altering decisions — and costing engineers hundreds of hours rebuilding the same components sprint after sprint. Two things became clear early on: • A component library only works if it's tied to the actual codebase. Without that, it's just documentation nobody follows. • Legal software handles dense, high-stakes information. Generic design system patterns don't always translate to that context — density and clarity have to coexist.
Design direction — accessible tokens, dense layouts, and modular components
I structured the system around a clear hierarchy — atoms, molecules, organisms, and pages — to keep everything modular and easy to extend. A 4px grid let complex legal tables stay dense without losing visual clarity. For typography, I chose Source Sans Pro and Merriweather: both meet federal accessibility ratios and read as authoritative, which matters in a judicial setting.
Outcome — a production-ready system embedded in Angular
The result was a production-ready design system built directly into EOIR's Angular 7 codebase. Every component shipped with accessibility built in — semantic ARIA tags and keyboard navigation, not bolted on after the fact. I designed a notification framework that treats irreversible actions (like deleting a judicial record) differently from routine background updates, so judges always know when something can't be undone. Engineers got a plug-and-play code sandbox that took full interface builds from days down to about 30 minutes.
A design system is a product, not a one-time deliverable — it needs an ongoing workflow behind it, not just a UI kit. Keeping components simple and modular early on prevented the sprawl that usually creeps in as new applications join. And looping engineering into requirements from day one, instead of after design was "done," removed almost all of the handoff friction we used to deal with.
