Senior Product Designer · 3 months to MVP

Usage Management

Real-time alerts, usage trending, and a subscription cost breakdown that gave admins control instead of surprise.

Usage alerts: an admin sets thresholds at 75%, 80% and 100% on a subscription, then picks the email recipients. Press play to watch.

The story in three acts

Act 1 · The setup

Admins couldn’t see overages until the invoice landed.

Usage spikes went unnoticed for weeks. Bills came in 3× higher than expected, support tickets piled up, and the people on the hook for budget had to explain charges they never saw coming.

Act 2 · The turn

Three small stages instead of one 9-month rebuild.

Per-service cost attribution would have taken nine months. I split it into alerts, anomaly-led trending, then a subscription cost view, each useful on its own and shippable in three.

Act 3 · The payoff

Same data, better hierarchy.

v1 showed every chart at once. v2 led with what changed and tucked the rest one click deeper. Support tickets dropped 30% in month one, and admins finally felt ahead of the bill instead of behind it.

What

A usage and cost management surface for SaaS admins, shipped in two stages: email-based usage alerts admins configure themselves, and an anomaly-led usage trending view that absorbs the cost breakdown. Each stage is usable on its own.

Why

Admins had no visibility into mid-month usage. Bills arrived 3× higher than expected, support tickets spiked, and customers started evaluating competitors. The job they were trying to do, keep spend predictable, was failing.

How

01
Broke the work into two stages achievable in 3 months instead of promising perfect cost attribution in 9.
02
Tested with 6 admins. They wanted multiple thresholds per subscription (75/80/100%) and anomalies surfaced first, not a drill-it-yourself cost tree.
03
Used prototypes as a translation layer to align engineering, finance, product, and CS around the same artifact.

Journey map, as-is vs to-be

The same five moments, two very different emotional arcs.

Plan

As-is: 🙂 Confident

To-be: 🙂 In control

Use

As-is: 😶 Unaware

To-be: 🛎️ Alerted

Bill

As-is: 😨 Blindsided

To-be: 🔮 Predicted

React

As-is: 😤 Frustrated

To-be: 🧭 Self-serves

Decide

As-is: 🚪 Churn risk

To-be: 🤝 Retained

'Budget is set, I trust the plan limits will hold.'

'A team blew past 120% of plan and nobody told me.'

'Invoice is 3× higher than I forecast, and I have to explain it.'

'I have to call CS to understand my own bill.'

'Maybe a competitor with simpler pricing is the answer.'

Visibility into how each team is tracking from day one.

Real-time signal when usage crosses safe thresholds.

A trended view that anticipates overage before invoice day.

Cost broken down by subscription with clear attribution.

Confidence that next month won’t blow up the same way.

Predictability by default, not surprise.P2

Alert before bill, not after.P1

Anomalies first, details one click deeper.P2

Cost lives next to the plan it belongs to.P3

Trust is rebuilt one predictable cycle at a time.P4

Emotional curve

As-isTo-bePainNeedDesign principle

Dashed grey traces the as-is emotional arc, solid indigo shows the redesigned to-be arc. Pains and needs feed directly into the design principles below.

Measured impact

−30%: Support tickets in month one
3 mo.: To MVP, vs. 6-9 estimated
4 teams: Shipping in parallel

What I learned

01
Sequencing beats scope. Saying no to perfect cost attribution is what made alerts shippable in 3 months, and that early win bought the room for stages 2 and 3.
02
Hierarchy is a feature. v1 and v2 had the same data; leading with anomalies instead of dashboards is what made the product feel usable.
03
Prototypes are the cheapest alignment tool I have. Four teams stopped debating in meetings once they could react to the same artifact.