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
4 Months
team
1 Designer & 1 Engineer
Scope
Chat Library, Tokens, Design System
Final Results
~5x faster design cycles
~80% fewer design inconsistencies
~80% fewer design inconsistencies
The problem
Developers got inconsistent specs, sometimes with different names for the same thing. And nothing told anyone which chart to use when. The charts themselves weren't the problem.
What was missing was any logic connecting them.
Same chart types rebuilt in 5+ versions with no shared logic
Color, spacing, and empty states differed across modules
Developers received inconsistent specs, named differently module to module
No guidance on which chart to use and when
The foundation
Start with tokens, then components, then dashboards assembled from the same primitives every time. That's the whole principle, and it's what everything else in the system builds from: design tokens, atoms, molecules, organisms, templates.
Typography, spacing, color, and elevation got defined once as shared tokens, so no screen was ever styled by eye.
Eight chart types funnel, progress, donut, horizontal bar, stacked bar, comparison bar, line, and area, all share the same layout logic, tokenized styling, consistent axis labeling, tooltip states, and empty states. Build one chart correctly and the other seven inherit the fix.
Responsive by default. Every chart scales across seven breakpoints, from XS to XXL, and reflows without losing its visual logic at any size.
Tooltips as their own system, not something each chart handled independently. Placement, timing, and content format stay consistent across every chart type.
Flexible viewing, without leaving the report. Users can switch chart types, change breakdown dimensions, and apply filters in place.
Modular cards, from compact KPI tiles to full-width views, all built from the same base component. Changing what's inside a card never means rebuilding 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
Naming conventions matched what engineers already called things in code. Every state got documented. Chart usage guidelines told teams which chart fit which situation. A library that designers and developers name differently isn't really one library, it's two that happen to look alike.
Results
Metric | Change |
|---|---|
Design cycles | 5x faster |
Design inconsistencies | ~80% reduction |
Handoff clarity | One shared naming system |
Adding new chart types | Drops in, no rebuild needed |
Looking back
Naming and documentation mattered more than I expected going in. A component described inconsistently across design and code quietly turns into two libraries instead of one, no matter how clean the components themselves are. Getting the naming to match took real upfront effort, but it's what let this become the base every analytics surface after it was built on.
