Back

/

Leena AI

Leena AI Enterprise Design System

Leena AI Enterprise Design System

Building the design backbone for an enterprise virtual assistant product

Building the design backbone for an enterprise virtual assistant product

By late 2023, Leena AI's design team had grown fast, and the product was starting to show it. Every new hire was rebuilding basic components slightly differently, dev handoff had turned into a guessing game, and turnaround time on new screens kept creeping up. I put together a small team to fix this properly, and set out to build a design system that could actually hold up an enterprise-grade virtual assistant product.

By late 2023, Leena AI's design team had grown fast, and the product was starting to show it. Every new hire was rebuilding basic components slightly differently, dev handoff had turned into a guessing game, and turnaround time on new screens kept creeping up. I put together a small team to fix this properly, and set out to build a design system that could actually hold up an enterprise-grade virtual assistant product.

ROLE

Lead Designer

Lead Designer

TEAM

2 Designers, 1 Engineer

2 Designers, 1 Engineer

DURATION

RESULTS

  • Design delivery turnaround dropped as designers assembled from a tested library instead of building from zero

  • Dev handoff got faster since engineers finally had documented specs instead of reverse-engineering each file

  • The product read as one consistent enterprise system instead of patchworked screens

  • Design delivery turnaround dropped as designers assembled from a tested library instead of building from zero

  • Dev handoff got faster since engineers finally had documented specs instead of reverse-engineering each file

  • The product read as one consistent enterprise system instead of patchworked screens

The Problem
  • TAT for design delivery was reduced from 10 days to 4 days

  • No shared library existed, so consistency depended entirely on individual memory as the team scaled

  • Dev handoff was slow because engineers had to reverse-engineer intent from scratch every time

  • Some of the product's most basic components still had real UX issues baked in

  • The product needed to look and feel like enterprise software, not an early-stage build

  • TAT for design delivery was reduced from 10 days to 4 days

  • No shared library existed, so consistency depended entirely on individual memory as the team scaled

  • Dev handoff was slow because engineers had to reverse-engineer intent from scratch every time

  • Some of the product's most basic components still had real UX issues baked in

  • The product needed to look and feel like enterprise software, not an early-stage build

How Research Shaped the Interface

01. Foundations Color styles, text styles, elevation, and a full dark mode conversion, plus a 109-icon library and a small illustration set. Getting this right first meant every component built after it inherited consistency automatically.

01. Foundations Color styles, text styles, elevation, and a full dark mode conversion, plus a 109-icon library and a small illustration set. Getting this right first meant every component built after it inherited consistency automatically.

02. Core UI Kit Buttons, dropdowns, text fields, checkboxes, chips, radio buttons, toggles, tooltips, and breadcrumbs. I paired directly with the two junior designers here so the system reflected shared decisions, not just mine.

03. Chat & Bubble System The core of what made this a virtual assistant system rather than a generic UI kit. Thirteen bubble variants and ten expanded states, covering everything from plain text replies to rich media and multi-step interactions, plus a bot switcher for multi-agent handling.

04. Application Components Modals, notifications, file upload flows, date pickers, webview headers, and a 23-variant QR and CTA component for omnichannel deployment, the pieces a real conversational product needs once it leaves the demo stage.

05. Enterprise Data Patterns A reference library of 101 table variants and 49 filter configurations, so whichever team touched an enterprise dashboard later had a tested pattern instead of designing tables from scratch.

06. Documentation Thirty-two documented configuration patterns covering states, interactions, and usage guidelines, so an engineer could open a component and know exactly how to build it without pinging design first.

Interface

The System in Action Foundations, core components, chat bubbles, and the enterprise table kit shown together in one working interface, the full system applied to a real screen rather than shown piece by piece.

Testing the Assumptions

With a three-month window, I split ownership by area: foundations and the more complex chat components stayed with me, the junior designers took core UI and application components under close review, and the engineer worked alongside us from week one instead of joining after design was finished. That meant naming conventions and technical constraints got caught during design, not in a Slack thread three weeks later.

With a three-month window, I split ownership by area: foundations and the more complex chat components stayed with me, the junior designers took core UI and application components under close review, and the engineer worked alongside us from week one instead of joining after design was finished. That meant naming conventions and technical constraints got caught during design, not in a Slack thread three weeks later.

Results & Impact

Before the system existed, every new screen started from a slightly different set of assumptions, and dev handoff meant re-explaining intent every time. After it shipped:

  • TAT for design delivery was reduced from 10 days to 4 days

  • No shared library existed, so consistency depended entirely on individual memory as the team scaled

  • Dev handoff was slow because engineers had to reverse-engineer intent from scratch every time

  • Some of the product's most basic components still had real UX issues baked in

  • The product needed to look and feel like enterprise software, not an early-stage build

Before the system existed, every new screen started from a slightly different set of assumptions, and dev handoff meant re-explaining intent every time. After it shipped:

  • TAT for design delivery was reduced from 10 days to 4 days

  • No shared library existed, so consistency depended entirely on individual memory as the team scaled

  • Dev handoff was slow because engineers had to reverse-engineer intent from scratch every time

  • Some of the product's most basic components still had real UX issues baked in

  • The product needed to look and feel like enterprise software, not an early-stage build

Retrospective
  • Leading two junior designers through this taught me as much about delegation and review as it did about tokens and components. The system only stayed consistent because we reviewed every component together, not because I built it alone and handed it down.

  • Enterprise data patterns like tables and filters get overlooked in most design systems because they're unglamorous. Building them properly early saved far more time later than the chat components did, even though they're the less exciting part of the story.

  • Leading two junior designers through this taught me as much about delegation and review as it did about tokens and components. The system only stayed consistent because we reviewed every component together, not because I built it alone and handed it down.

  • Enterprise data patterns like tables and filters get overlooked in most design systems because they're unglamorous. Building them properly early saved far more time later than the chat components did, even though they're the less exciting part of the story.