A usage dashboard, on-system
Northbeam Labs, a B2B analytics startup, needed a customer-facing usage dashboard that looked like it shipped with the product, not bolted onto it.
- Client
- Northbeam Labs, B2B analytics
- Scope
- 11 screens, 6 chart primitives
- Timeline
- First draft in 48h, shipped in 9 days
The problem
Customers asked one question at renewal: what did we actually use? Northbeam's answer lived in a CSV export. Sales wanted a dashboard; engineering had two sprints and no design capacity.
The catch: Northbeam DS v2.3 had no data-visualization layer at all. Stat tiles, charts, and live states had to be drafted as system components, not one-off screens.
Three moves
Extend the system before the screen
Six chart primitives drafted from Northbeam's existing scale: stat tile, sparkline, area chart, bar row, delta chip, live badge. Each one tokened and documented before any page used it.
Draft the screens from real shapes
Wraith generated the 11 screens against Northbeam's actual event taxonomy, so empty, loading, and overflow states were designed against data that exists, not lorem numbers.
Review for hierarchy, then ship in code
The human pass cut two chart types and promoted the renewal-relevant numbers to the top row. Delivery was working React against the DS package, plus Figma for the record.
Before and after
What shipped
- 11
- screens shipped in code
- 6
- chart primitives added to the system
- 9
- days from brief to production
- 0
- off-system values in the audit
Nnamdi E.
Senior Designer, Wraith
The AI drafted eight chart types. Six survived review. A dashboard is a hierarchy argument, and the human makes that call.
Illustrative case, composed for planning purposes. Names and numbers are placeholders.
Your product could be case 03.
First draft in 48 hours, a named designer signs everything, pause anytime.