Leena AI
The System Behind the Charts
Every new dashboard was rebuilding something that already existed, just slightly differently each time. The same chart type existed in five-plus versions with no shared logic between them. Color, spacing, and empty states shifted from module to module.
Role
Lead Product Designer
Timeline
3 Weeks
team
1 Designer & 1 Engineer
Scope
Chat Library, Tokens, Design System
Final Results
~3x faster design cycles
~90% fewer design inconsistencies
New chart types ship in without breaking the system
The problem
Every new dashboard rebuilt something that already existed, slightly differently each time. The same chart types existed in five or more versions with no shared logic between them. Color, spacing and empty states shifted from module to module. Developers received specs that were inconsistent, sometimes with different names for the same thing, and nothing told anyone which chart to use in which situation.
The same chart types existed in 5+ versions with no shared logic.
Color, spacing and empty states changed from module to module.
Developers received inconsistent specs, with the same component named differently.
There was no guidance on which chart to use and when.
The charts themselves weren't where the trouble sat. Underneath them there was no system, so the first decision I made was to stop fixing charts and build what they were missing.
Looking at what existed
Before designing anything new, I went through the dashboards to find where the same chart had been rebuilt and how the versions had drifted. I also looked at how engineers named and built these components, because the specs they received were part of the problem.
This pointed to the order of work. Cleaning up the most visible charts first would have been faster to show, and the drift would have come back with the next dashboard. So I started underneath them.
Setting the targets
I tied the work to outcomes the team could check: faster design cycles, fewer inconsistencies, one shared language between design and code, and new chart types that could be added without rework.
The results at the end are measured against these.
The foundation
I started with primitives and worked up: design tokens, then atoms, molecules, organisms and templates. Every dashboard gets assembled from the same parts, which is why one chart built correctly passes its rules to the others.
Typography, spacing, color and elevation are defined once as shared tokens, so no screen is styled by eye. I treated this as the most important step in the project, even though it produced nothing a stakeholder could point at for a while. Everything after it depended on it.
Choosing the charts
I built eight chart types: funnel, progress, donut, horizontal bar, stacked bar, comparison bar, line and area. Each shares the same layout logic, labeling, tooltip behavior and empty states. I kept the set to what the product used.
A longer list would have meant more to maintain and more ways to choose the wrong chart, and one of the system's jobs was to take that guesswork away.
Four further decisions shaped how the system works day to day
Responsive by default. Every chart scales across breakpoints, and full-screen reports use the same components scaled up instead of duplicated versions built for the purpose.
Tooltips as their own system. I didn't leave tooltips for each chart to handle. Placement, timing and content were defined once, so they stay consistent across every chart type. Tooltips are small, and they're exactly where inconsistency tends to creep back in.
Flexible viewing. Users can switch chart types, change breakdown dimensions and apply filters without leaving the report, so exploring the data doesn't mean losing their place.
Modular cards. Cards run from compact KPI tiles to full-width views, all built from the same base component. Changing what a card shows doesn't rebuild the container around it.
Full-screen reports for metrics that need more room
The same chart components scale up to fill the page, no duplicate versions built just for full-screen.
Built for handoff, not just for Figma
A chart library lives in code as well as in Figma, and a gap between the two would recreate the original problem. So I matched the naming conventions to what engineers already called things in code, and I documented every state. I also wrote chart usage guidelines that tell teams which chart fits which situation.
The naming call took real effort early on, and I'd make it again. A library that designers and developers name differently is two libraries that happen to look alike.
Results
Metric | Change |
|---|---|
Design cycles | 3x faster |
Design inconsistencies | ~80% reduction |
Handoff clarity | One shared naming system |
Adding new chart types | Drops in, no rebuild needed |
Naming and documentation mattered more than I expected going in. A component described inconsistently across design and code is effectively two components, even if they look identical. Getting the names to match took up-front work, and it's why this became the base that every analytics surface was built on afterward.
I'd also say that starting underneath the charts was the harder sell and the better call. It took longer to show progress, and it's the reason new chart types now drop in without a rebuild.
