Leena AI
Leena AI's Enterprise Design System
A design system for a virtual assistant product, built in three months by deciding carefully what belonged in it.
Role
Lead Product Designer
Timeline
Created based on use cases
team
3 Designers, 1 Engineer
Scope
Design System, Templates, Documentation
Final Results
Design delivery time dropped from 10 days to 4
Dev handoff got 2X faster
Why this mattered
By late 2022, Leena AI's design team had grown and the product was starting to show it. Every new screen rebuilt the same basic components slightly differently.
The team had no shared reference, so consistency lived in each designer's memory, and that stops working once more than a few people are involved.
I put together a small team to fix it properly. The goal was a system that could hold up under an enterprise-grade virtual assistant product, not a prettier kit.
The problem
No shared components, so consistency depended entirely on individual memory.
Dev handoff meant explaining intent every time, and engineers had to reverse-engineer it from each mock.
Some of the components that enterprise use cases needed didn't exist yet, so every new screen was held together by hand.
Looking before building
I didn't open Figma first. The brief could have been "build a component library," and I took it as something different: the team needed a shared way of making decisions, with components as the output. That changed what I looked at. Before drawing anything, I went through live product screens to see which patterns kept getting rebuilt and where the copies had drifted apart. I also talked to the designers who'd use the system daily and to the engineer who'd implement it, because they were the ones who knew where time was actually being lost.
What I found set the build order: foundations first, then a base kit, then the pieces that made this a virtual assistant product, then the enterprise screens.
Agreeing on what success meant
A design system judged on appearance is hard to defend a year later. So before building, I set the goals. I got the people who'd judge the work to agree on them: designers should assemble screens from existing parts instead of redrawing them, color and spacing should come from shared tokens instead of memory, and an engineer should be able to build from a spec without asking what it meant.
Every later decision was checked against those goals. When something didn't help any of them, it stayed out.
Building the system
1. Foundations
I began with color styles, a spacing scale, elevation and a full typography system, all tokenized. The reasoning was practical: if new components inherit their consistency from tokens, nobody has to rebuild it each time. Everything after this step got cheaper.
Base UI Kit
Buttons, dropdowns, text fields, checkboxes, chips, toggles, tooltips and breadcrumbs. I built this with the designers who'd use it day to day, so it recorded decisions the team already kept re-making instead of one person's visual preference. I deliberately kept it to what screens needed. More variants would have given designers more ways to pick the wrong one, and given the engineer more to build in the same three months.
Chat & Bubble System
This is where I put the depth, because it's what makes the product a virtual assistant and not a generic dashboard. A standard kit would have offered a basic message component and left every screen to improvise. I built 12 to 15+ bubble variants with multiple expandable states, covering everything from plain text to multi-step interactions and multi-agent handling. It was the largest single investment in the system, and the one a generic kit couldn't have given us.
Application Components
Modals, notifications, file upload, date pickers, welcome headers, and the CTA components that enterprise deployments need. These are the pieces a real screen requires that a demo never shows, and they were the ones missing when screens were being built by hand.
Enterprise Data Patterns
A reference library of table variants and filter configurations, so a dashboard could pull from existing patterns instead of designing a table from scratch. Tables and filters are easy to push to the end of a plan because they're unglamorous. I built them early. By the time the more visible components arrived, the least exciting part of the system was already solid.
Building it with engineering
The system had to work in code as much as in Figma, so I worked with the engineer from the start on how we'd build and hand it off.
Documentation was the clearest example of scoping to what's useful. I asked what an engineer would actually use, and the answer was behaviour: states, interactions and edge-case guidelines for every component, so someone could open one and build exactly what was meant without guessing. I documented that and stopped. Nobody gets value from documentation nobody reads.
With three designers and one engineer, I also couldn't build all of it myself. I split ownership of sections across the designers and reviewed each one for consistency. The system came out coherent because of that review step, which I treated as part of the job, as seriously as the components.
The system came together
In one working interface, foundations, core components, chat bubbles, and enterprise tables were applied to a real screen rather than shown piece by piece.
Before the system existed, every new screen started from a slightly different set of assumptions, and dev handoff meant explaining intent every time. After it shipped:
Design delivery time dropped from 10 days to 4.
Consistency stopped depending on memory, because shared components carried it.
Dev handoff got 2x faster. Engineers had documented specs instead of reverse-engineering mocks.
The product started to read as one consistent enterprise system, not patched-together screens.
Looking back
Leading this taught me as much about delegation and review as it did about components and systems. It worked because ownership was split across designers and reviewed for consistency, and it would have stalled if I'd tried to touch every piece myself.
Sequencing mattered more than I expected. Data patterns like tables and filters are easy to skip over when you're ordering a design system, but putting them early meant the less glamorous part of the system was solid before anyone touched the flashier parts.
