AI Nexus Design System

Why it needed rebuilding

A design system is only useful if people trust it enough to reach for it. Ours had stopped earning that trust. As Simplifai expanded its AI automation platforms and planned new products, the existing library had become harder to use than to work around:

• Inconsistent designs made it difficult to keep products coherent with each other.
• Too many unused variants cluttered the library, so finding the right component took longer than drawing a new one.
• Legacy files from different designers were hard to maintain, because each had followed its own conventions.

Patching wasn’t enough. The system needed a full overhaul.

Goals

• Scalability: a future-proof foundation that could adapt as products evolved.
• Consistency: one visual language across all products, aligned with the updated brand guidelines.
• Efficiency: less friction in both design and development.
• Usability: easy to understand, implement, and maintain, for designers and developers alike.

My role

I worked on the revamp as part of the design team, rebuilding foundations and components and writing usage guidelines so both designers and developers could adopt the system with confidence.

The approach: building it atom by atom

I structured the system using atomic design, so every piece is built from smaller, already-defined pieces. That’s what makes it scalable: change a token once and every button, badge, and toast that uses it updates with it.

1. Foundations — tokens: color, type, spacing, grid, icons
2. Atoms — the smallest usable UI pieces: buttons, badges, inputs, checkboxes, radios, avatars, spinners
3. Molecules — atoms combined into a single job: form fields, chips, breadcrumbs, tooltips, toasts, avatar groups
4. Organisms — larger, self-contained sections: dropdowns, accordions, lists, empty states
5. Templates and pages — organisms assembled into real product screens

---

1. Foundations

Color

Nine palettes, each with five tints, and each tied to a clear role so designers pick colors by meaning, not by eye:

• Primary (deep indigo): main brand color, for primary actions and key highlights
• Secondary (violet): supports the primary, often for secondary actions
• Neutral / Panel, White, Gray: backgrounds, containers, borders, disabled states, and subtle text
• Neutral / Yellow: warnings and attention-grabbing elements
• Success, Warning, Error: semantic feedback, from positive outcomes to issues needing immediate action
• Status / New: a supplementary palette for charts and data visualization

Typography

Two typefaces with distinct jobs:

• Grenette Pro is the display face, used for headings. It adds warmth and humanity to an otherwise calm, minimal visual language.
• ABC Diatype is the workhorse, used everywhere else. It’s clean, professional, and highly readable at small sizes.

The scale is defined per use (headings, titles, buttons, badges, links, and body in regular and bold), each with a fixed size and line height, from 56/64 display headings down to 8/12 tiny badges.

Grid and spacing

Everything sits on a 4-point grid: spacing, sizing, and alignment all use multiples of 4px. That gives the UI a consistent rhythm, keeps layouts proportional across devices, renders crisply on pixel-density screens, and maps directly to spacing tokens, so handoff doesn’t depend on eyeballing.

• Desktop (1280–1920px): 12 columns, 40px margins, 20px gutters
• Mobile (320–480px): 4 columns, 16px margins, 16px gutters

Icons

Rather than drawing a custom set, we adopted the open-source Phosphor library for its clean, functional style. The system includes 115+ icons, each available at 16, 24, 32, and 40px, and each chosen to be strictly functional and legible at small sizes.

---

2. Atoms

Buttons

Buttons are the most-used atom, and also where the old library had the most sprawl. The new set is a clear matrix instead of an ad hoc collection:

• 7 variants: primary, primary outline, primary text-only, secondary, secondary text-only, error, and error text-only
• 6 content types: text only, icon before, icon after, icon only, icon only (bold), and icon with indicator
• 5 states: rest, hover, pressed, selected, and disabled

Every combination follows the same rules, so a developer who has built one button can predict all of them.

Badges

Badges communicate status at a glance: new, checked, completed, failed, and neutral. Each comes in four sizes (tiny to large), for both light and dark themes, using the semantic color tokens so status colors mean the same thing everywhere.

Other atoms

Inputs, checkboxes, radio buttons, avatars, and spinners complete the set. Each is built on the same tokens, so they share spacing, color, and type.

---

3. Molecules

Atoms combine into components that each do one job:

• Form field: label, input, and helper or error message, with default, filled, focused, and error states
• Chip: a label with an optional leading icon and a remove action
• Breadcrumb: icon and label links with separators, showing where the user is
• Tooltip and toast: short contextual messages, from on-hover hints to toast notifications in neutral, informational, positive, warning, and negative types
• Avatar group: stacked avatars with overflow handling and activity indicators

4. Organisms

Molecules come together into larger, self-contained sections:

• Dropdown: option menus with grouping and scrolling, used for things like picking an email integration
• Accordion: expandable sections that keep dense content scannable
• List: tabular data with sorting and pagination
• Empty state: icon, message, and guidance for when there’s nothing to show yet, such as an empty notifications panel

---

Documentation that answers the next question

A component library only helps if people use each component correctly. So every component got a guideline page with the same structure:

• Brief: what it is and when to use it
• Live usage: where it appears in a real product
• Types: every available variant
• Layout: placement and spacing rules, with do’s and don’ts
• Behavior: how it responds to interaction
• Content: how to write labels and messages for it

We documented accordions, avatars, badges, breadcrumbs, buttons, dropdowns, lists, radio buttons, spinners, toasts, and tooltips this way.

Keeping it lean

The old system got bloated because anything could be added and nothing was removed. We changed that with two rules:

• Regular release notes. Every one to two months, developers got notes on what had been added, changed, or removed, so design and code stayed in sync.
• A bar for new components. New components or variants were added only after evaluating whether they were truly needed, with the reasoning documented.

What I learned

• Scale comes from structure, not size. A small, well-organized set of reusable parts supports growth better than a big library.
• Guidelines drive adoption. Clear documentation made the system easy to understand and use correctly.
• Build it with developers, not for them. Working with engineering throughout was what made implementation smooth.

The system is a living product, and it keeps evolving as product needs change.