Telecom bills were correct and opaque. I argued the design problem wasn't pricing — it was that customers couldn't translate the bill. Three design decisions dropped billing-support tickets 40%.
O2's Priority tier customers were calling support at £8/ticket with the same question: "Why is my bill so high?" The previous portal was already transparent — every call, text, and megabyte itemised. Transparency wasn't the problem. Translatability was.
As lead product designer for the Priority tier portal (2014–2016, millions of UK subscribers), I argued the fix wasn't more pricing options or a friendlier tone — it was a redesigned bill where every number was verifiable. Three decisions made the difference.
The legacy portal opened on a 47-row itemised table. Engineering wanted to keep it — auditors needed every line accessible. I argued: auditors need the rows on demand, not on landing. Most customers spend <10 seconds on the bill page; the first surface has to answer "what is this for?" not "prove every charge."
Compromise: the summary opens first; every category expands into the full itemisation underneath. The auditors keep their rows. The customers get their answer.
Three options on the table for how customers would verify a charge. The argument with engineering was about render cost. The argument with billing-ops was about audit risk. The deciding factor turned out to be neither.
| Design option | Customer behaviour | Engineering cost | Ticket-deflection signal | Status |
|---|---|---|---|---|
| A — Tooltip on hover | Math hidden until hover; 71% of customers never discovered it (heatmap data). | Cheap. | ~ -8% (marginal). | REJECTED ❌ |
| B — Math inline, every charge | Customer reads the sentence as part of the bill itself; doesn't require discovery. | Mid. Required a calc service on the bill-render path. | -40% (8-week post-launch average). | SELECTED ✅ |
| C — Separate "explain my bill" page | Friction. 4 clicks deep. Engineering preferred this for audit isolation. | Cheapest of three. | ~ -12% (still required customer to seek it out). | REJECTED ❌ |
The deciding factor: Option C tested with 20 customers showed they didn't trust an "explain" page they had to click into — it read as a retroactive defence. Math inline read as the bill itself being honest.
I wrote the redline spec for the bill-line component so engineering could implement without round-trips. Annotated below: the one component that ships across every charge, every category, every currency. Token names match the design system; engineering used them verbatim.
- Category dot. 8px circle, tokenised by category. Pre-attentive recognition.
- Label. 13px sans, ink. The thing the customer recognises.
- Math sentence. Mono-12, gold left-rule. Reads as machine output, not marketing.
- Expand affordance. Always visible. Drill-down is one tap, not a hunt.
One component. 47 variations across the bill. Engineering implemented in 9 days from the spec.
Transparency in complex systems isn't about showing more. It's about helping people verify what they're seeing. Connect the charge to the behaviour, show the math, and the number becomes trustworthy.
I've carried this forward into every system where non-technical users have to act on opaque outputs — AI recommendations, financial risk scores, algorithmic pricing. The pattern holds: show the logic, make it verifiable, and trust emerges from transparency.
Design patterns demonstrated
- AI Failure States: When the usage forecast couldn't predict with confidence (new phone, unusual roaming), the portal showed actual usage with historical context — never a low-confidence prediction dressed as fact.
- Confidence Score Patterns: Roaming charges shipped with high-confidence math; forward projections shipped with explicit confidence bands. Customers learned which numbers to act on and which to treat as guidance.
One pattern per month with tradeoffs and code examples. 2,500+ designers already subscribed.