AUI Design System

Overview

Toshiba has a handful of web-based administration products: retail management, device configuration, security monitoring, store operations. The thing is, they were all designed in isolation. Every product had its own button styles, its own table patterns, its own way of handling modals. Developers were rebuilding the same components from scratch every time a new project kicked off, and the user experience across the suite felt disconnected.

I led the creation of the AUI (Administration UI) Design System. It's a unified component library in Figma that acts as the single source of truth for all of Toshiba's web-based admin products. The goal was pretty straightforward: make things consistent, speed up delivery, and get accessibility right across the board.

The Problem

Before the design system, every new feature or product meant starting from zero. No shared components, no shared patterns. It created a bunch of problems that just kept stacking up:

• Designers were spending 30–40% of their time recreating basic UI elements instead of actually solving user problems
• Developers would get inconsistent specs. The same "data table" looked and behaved differently depending on which product you were looking at
• Accessibility was always something we'd "get to later." No standardized contrast ratios, no focus states, no keyboard navigation patterns
• Onboarding new designers or developers took weeks because there was nothing to point them to

Building the Foundation

I started by auditing every existing admin product and cataloging every unique component variant I could find. The results were pretty eye-opening: 14 different button styles, 8 table patterns, and 6 modal implementations. Most of them were doing the same thing with slight visual differences.

From there, I built out the system architecture:

• Design Tokens: Color, typography, spacing, elevation, and border-radius tokens that define the visual language. Every component references tokens instead of hard-coded values, so when something needs to change, it changes everywhere at once.
• Core Components: Buttons, inputs, selects, checkboxes, radio buttons, toggles, tooltips, badges, and tags. All built with variant properties for size, state, and type.
• Pattern Components: Data tables with sorting/filtering/pagination, modals and dialogs, side panels, navigation bars, breadcrumbs, steppers, tabs, and card layouts.
• Chart Components: Bar charts, line charts, donut charts, and KPI cards. A lot of this came out of the Security Suite dashboard work and was standardized so any reporting product could use them.

Accessibility First

One thing I was really intentional about was building accessibility in from the start rather than trying to bolt it on later. Every component meets WCAG 2.1 AA standards out of the box:

• Minimum 4.5:1 contrast ratios for all text, validated across light and dark surface contexts
• Visible focus indicators on every interactive element for keyboard navigation
• ARIA labeling guidance documented alongside each component
• No status is conveyed by color alone. There's always a secondary indicator

Adoption & Governance

You can build the most beautiful design system in the world, but if nobody uses it, it doesn't matter. Getting adoption right was just as important as getting the components right:

• Any designer can propose new components or variants through a lightweight review process. It's not gatekept
• Every component has documentation covering usage guidelines, do's and don'ts, and developer handoff specs
• Regular syncs with front-end developers to make sure Figma components actually mapped to what they were building
• Version-controlled releases so teams could upgrade on their own schedule without breaking what they already shipped

Results

Here's where we landed:

• Design-to-development handoff time dropped by about 60%. Developers get consistent, spec-ready components now
• 4 products are built on the shared system: Security Suite, Administration Panel, Store Operations, and Device Management
• New designer onboarding went from weeks to days. The library basically documents itself
• Accessibility compliance across all products using the system, which means no more scrambling to fix things after the fact
• The library grew to 120+ components with variants covering pretty much everything an admin UI needs