Billing & Consumption · UX Case Study · Internal Operational Tool
Client consumption, read against what was purchased
An internal operational tool for selecting clients, comparing their consumption with purchased limits, following usage trends, configuring threshold alerts and supporting internal billing activities.
- Employer
- Platform 3 Solutions
- Role
- Senior UX Lead
- Participation
- UI / UX 100%
- Year
- 2025 to 2026 · Shipped
- Type
- Internal tool
- Team
- Individual ownership
- Areas
- Client selection · Consumption dashboard · Tier plans · Alert configuration · Billing · Plans · Clients
What this deck shows, and what it withholds
Everything described here is work I did. The product and its figures are withheld under confidentiality, and the interfaces shown here are redrawn rather than captured.
- 01
Withheld
The product name, and all client, tier and consumption figures. No production screenshot appears here.
- 02
Shown
The structure I designed, the decisions I made and why, and how the design was carried through build.
- 03
Redrawn
Where a screen carries the argument, it is reconstructed: the structure, layout and behaviour kept, the identifying content removed and every value replaced with a placeholder.
An internal view of client consumption
who uses the tool, and for what
The platform sells capacity. Clients purchase tiers that set limits across usage dimensions. This tool sits inside the organisation, between those limits and the teams that act on them.
Client (purchases tiers) → Platform (records consumption) → Billing & Consumption tool (relates consumption to what was purchased) → Internal teams: sales, finance, product team heads. Clients do not use this tool.
- 01
Select a client
- 02
Compare consumption with purchase
- 03
Follow usage trends
- 04
Configure threshold alerts
- 05
Support billing activities
Usage dimensions include storage, query volume, data transfer, users and compute.
Consumption needs context to be read
the problem behind the screens
Each piece of information was available on its own. None of them, alone, told an internal team whether a client was within what it purchased.
Consumption only becomes meaningful when it is read with the rest of the chain.
- 01
Client
Which client?
- 02
Entitlement
What did it purchase?
- 03
Consumption
What has it used?
- 04
Billing period
For which period?
- 05
Alerts
What should raise attention?
- 06
Billing context
What matters for billing?
The chain describes the relationship the design had to express, not a formal method.
Three teams, one source of truth
different internal questions, answered from the same model
Each team asks something different. Each question depends on the same relationships, so the tool presents one shared model rather than a view per team.
One shared model: client, entitlement, consumption and billing period. The same figures, read against the same limits and period, for every team.
- 01
Sales
Where does this client stand against what it purchased?
- 02
Finance
What consumption is relevant to billing activities in this period?
- 03
Product team heads
How is capacity being used across clients?
Each team reads the part of the shared model that answers its question.
What I owned
UI/UX 100%, from requirements to reviewed build
My ownership did not stop at handoff. It ran from interpreting requirements through reviewing what was built.
Requirements (from the BA and stakeholders) → Business rules (how tiers, usage, periods and alerts relate) → Information architecture (flows, screen relationships, scope) → UX design (dashboard, tiers, alerts; alternatives explored) → Figma and prototype (designs on the shared design system) → Review (with stakeholders and the implementation team) → Handoff (supported developer handoff) → UX review and QA (reviewed builds, raised UX issues, refined designs).
- 01
Decisions
Explored alternatives and made the UX decisions, not only the screens.
- 02
Consistency
Applied the shared design system and component language used across the product family.
- 03
Quality
Raised UX issues during implementation and QA, and refined designs based on feedback and constraints.
Deciding how the concepts relate
the work between requirements and screens
The need came from Sales and Finance and reached me as requirements through the BA. The requirements listed what the tool should contain. My work was deciding how those pieces relate.
- 01
Read together
Some values only make sense side by side. Consumption, allowance and current tier are placed in one card and one cell, never split across places.
- 02
Carried across views
Some context applies everywhere. Client and billing period are chosen once, in the header, and every client view inherits them.
- 03
Global or client-specific
Two scopes need two places. Global holds clients, plans and billing; one client holds dashboard, tier plan and billing. “Billing” appears in both scopes as two different destinations.
- 04
One question per screen
Each screen has a single job. Where is the client now (dashboard) · what did it purchase (tier plan) · what should raise attention (alerts) · what matters for billing (billing). A screen that answers one question can put that answer first.
Read from the shipped structure: these four decisions shape every screen that follows.
Rules as interface behaviour
each rule, its UX implication and the design response
Each business rule created a reading problem. The interface resolves it where the figure is shown.
- 01
Each dimension has a purchased allowance
Usage alone does not show headroom. Used and allowed are shown together, so headroom is read, not calculated.
- 02
Data tier and usage tier are held independently
One tier label per page would be wrong. Tier is shown per metric, across two tables, so position is read correctly on each structure.
- 03
Figures belong to a billing period
A figure without its period can be misread. The period sits above and the time sits on each reading, so each figure states when it was true.
- 04
Alerts use thresholds against limits
Rules set apart from limits are hard to reason about. Configuration opens over the tier plan, so rules are set and read against their limits.
Select the client once
persistent context and two levels of scope
Most views describe one client in one period; some modules exist across all clients.
The decision: client selector in the header, persisting across tabs. Global modules in the sidebar. Client views in tabs.
- 01
Reasoning
Context should be inherited, not re-entered. Two scopes need two distinct places.
- 02
Consequence
The client is never asked for again. “Billing” appears in both scopes as two destinations.
- 03
Supporting exploration
A top menu was explored; the sidebar was chosen, with the top row kept for client context.
Redrawn layout. Labels are generic, and no production screenshot is shown.
Position first, then direction
the order of questions on the dashboard
The first question is where the client stands: used of allowed, with the current tier for that dimension. The limit sits with the figure.
- 01
First: where does the client stand?
Used of allowed, with the current tier for that dimension. The limit sits with the figure.
- 02
Then: how is usage changing?
Change against the previous period, then trend charts for follow-up questions.
- 03
Not here: what needs attention?
The dashboard does not show alert status. Thresholds and severity live in the alerting model.
- 04
Why tier is per dimension
Data and usage tiers can differ, so a single page-level tier would mislead.
Redrawn. One card stands for every usage dimension, and every value shown is a placeholder.
Two entitlement models, shown separately
locating one client on both
A client holds a data tier and a usage tier, and the two change independently. A single combined representation would suggest one hierarchy that moves together.
- 01
Design response
Two separate tables. The current tier badged on each. Consumption inside the entitlement cell. Readings timestamped for the selected period.
- 02
Rationale
A combined structure would imply the two entitlement models move together, so I represented them separately.
- 03
Resulting UX
Users see the client’s position on each structure without reconciling two entitlement models themselves.
Consumption sits inside the current tier’s entitlement cell. Redrawn: tier names and limits are placeholders, and the positions are illustrative.
Alerts set against the limits they protect
configuration kept in context
From limit to notification: tier limit → threshold → warning or critical → notification to recipients.
- 01
Metric
The dimension the rule watches, chosen from the tier plan it applies to.
- 02
Thresholds and severity
Warning and Critical are separate states, each set as a percentage of the limit.
- 03
Recipients
Individual recipients and groups, listed against the rule.
- 04
Repeat
Repeat is set as a percentage of the limit rather than on a timer.
- 05
Enabled
Off pauses the rule and keeps it, so turning something off is not a destructive act.
Rules read back in their own terms: type, metric, threshold, recipients. Redrawn: storage thresholds shown as the confirmed example, other values replaced with placeholders.
Carrying the design through build
shared patterns, handoff and UX review
Requirements → UX design → Figma → Review → Handoff → Build → UX review, with refinement from feedback and constraints along the way.
After handoff, I reviewed built screens against approved designs and raised UX issues during implementation and QA.
- 01
Shared component language
Designed with the patterns used across the product family: header context, sidebar navigation, tabs, data tables, panels and accordions.
- 02
Example from implementation review
Alert configuration panel: recipients listed in full made the panel scroll unnecessarily. Implemented as an accordion, opened only when needed.
Raised in implementation review, and implemented.
What the design established
and what carries forward
What the design established
- Consumption and entitlement presented together
- Client context selected once, carried across views
- Global and client scope separated
- Independent tier structures made explicit
And
- Figures tied to a billing period and time
- Alerts connected to the relevant limits
- Business rules shown directly in the interface
- Shared component patterns applied
- 01
Relate the concepts before designing the screens.
- 02
Show the context that gives a number its meaning.
- 03
Optimise internal tools for fast interpretation and clear operational decisions.
The tool shipped. Quantified results were not captured, so none are claimed.