Overview
- The problem
- A team needs to understand what is active, what it is consuming, and what it will pay, across services that use different meters and lifecycle states.
- My contribution
- I designed the Billing and Usage interfaces, trial and unlock paths, and their supporting payment and feedback states.
- The outcome
- A connected set of original designs covering trial, active-service, billing-history, consumption, and failure scenarios.
Problem
Trial, active, unlocked, payment, and failure designs show that service access, consumption, and invoices are different states. The original interfaces support that distinction; billing-support logs and research findings are not published here.
The challenge: technical usage has financial consequences
Cloud consumption is not a single familiar unit. AGS surfaces player concurrency, AMS has instance hours and data transfer, and Extend introduces logs, egress, and VM hours. A list of these numbers alone does not explain the relationship between consumption, service access, and a bill.
My design scope connects those questions across Billing, Usage, and Payment. The aim is to let a team inspect its situation before taking a commercial action, while keeping the technical detail available. This narrative explains the design visible in the file; it does not imply that a particular interview or usability study took place.
My Role
- Company / product context
- AccelByte · AGS billing and usage
- Users
- Game teams using AccelByte's cloud console, including the people configuring services and reviewing their costs.
- My role & scope
- I designed the Billing and Usage interfaces, trial and unlock paths, and their supporting payment and feedback states.
- Evidence available
- Original project narrative and design artifacts retained in this case study.
Process
The record covers service-state variations, trial activation, consumption detail, billing history, and recovery. These are documented interface scenarios, not proof of usability-test iterations.
- Which services are active?
- What is being consumed?
- What contributes to the balance?
- What happens if I unlock?
- What will be invoiced?
Trial activation is a commitment to explain
The offering screen places product capabilities beside a sequence explaining the trial, setup, and full-version path. That pairing matters: the user should understand both what becomes available and what happens later. Activation is not presented as an isolated button detached from its consequences.
The action is accompanied by an explanation of the service journey. Historical allowance and pricing copy is preserved as design evidence, not a current offer.The source contains evolving commercial terminology and allowances. I have retained the original screens rather than reconciling these into a new pricing claim. A production review should check that offering copy, status badges, usage meters, and invoice rules all describe the same approved model.
Key Decisions
Different services use different meters and lifecycle rules. A shared layout supports familiarity, while service-specific units and consequences must remain visible. A single balance cannot explain both current consumption and historical payment.
Key design decisions
Separate the bill from its explanation
Billing answers what is active and payable. Usage explains the consumption behind a balance. Keeping them adjacent preserves a route between financial and technical context.
See the usage hierarchyMake service state actionable
AGS, AMS, and Extend do not share one account-wide state. Each service carries its own status and next action instead of relying on a single upgrade banner.
Inspect the service statesDesign beyond the successful payment
Empty history, mixed service states, payment restrictions, and unlock failure are part of financial trust, not details to leave outside the story.
Explore the exception states
Trade-offs and design takeaways
- Use one repeated service-state pattern, while retaining product-specific meters and consequences.
- Keep totals scannable without hiding the units needed to investigate a charge.
- Distinguish current consumption, upcoming invoices, and historical payments instead of collapsing them into one balance.
- Make an upgrade understandable before making it easy to trigger.
The design result is a connected financial experience across multiple cloud products, not a claimed conversion lift. My main takeaway is that financial clarity depends on consistent relationships between screens as much as on the clarity of any single screen.
Final Solution
Billing and Usage link the top-level financial view to cost drivers, trial commitments, activated services, and payment recovery. Original screens retain their sample units, periods, and amounts.
A service portfolio, not one subscription
The Billing page groups AGS and its Extend add-on together, while giving AMS its own service area. Trial badges and local actions explain the state of each offering. The interface can therefore show one service in trial while another is active, rather than making the whole account appear uniformly paid or unpaid.
The trial state separates service access from payment history. Each service exposes its own next action.There is a useful tension here: a consistent structure makes services comparable, but their meters and eligibility rules remain different. The visual system repeats the status/action pattern without pretending that every product is the same plan.
From balance to cost drivers
Usage starts with the selected period and a current balance. Service-level sections then break that summary into meaningful measures: player concurrency for AGS, infrastructure consumption for AMS, and resource consumption for Extend. The tax notice sits next to the balance, where it changes how that figure should be interpreted.
A top-level balance leads into service-specific meters. All displayed figures are sample screen content, not outcome metrics.This hierarchy serves two reading speeds. Someone checking the overall position can stop at the summary. Someone investigating a charge can continue into the relevant product and its units. AMS measures include visible drill-down affordances, so an aggregate is a starting point rather than the only explanation.
Billing after activation
The populated Billing design adds an upcoming payment, a route back to Usage, and transaction-level history. A mixed-state example keeps AGS and AMS in trial while Extend is active. This demonstrates why lifecycle state belongs to the service rather than the account as a whole.
A populated payment history and active add-on coexist with other services still in trial.Upcoming payment and current usage are related but not interchangeable. The page labels the former as a previous-cycle amount including taxes, while Usage explicitly identifies a balance excluding taxes. Maintaining that distinction is more important than simply making the largest number prominent.
Payment context and recovery
Payment information remains in the same Billing & Usage navigation family. In the supplied restricted state, an explanation of an ongoing cancellation/deactivation request appears above a disabled update action. The design pairs an unavailable control with context rather than leaving the user to guess why it cannot be used.
Supporting states keep the user oriented when a financial action is unavailable or fails.The unlock-failure design names the failed operation and offers both support and a return to Billing. It does not imply that payment or activation succeeded. This is designed recovery guidance; the portfolio does not claim that a backend payment integration has been independently tested.
Outcomes
The delivered design set covers the financial lifecycle across multiple cloud services. No reduction in support contacts, billing errors, or time to understand a charge has been measured in the public record.
Evidence & limitations
This case study documents my interface design from the supplied Figma file. Screen amounts, dates, customer names, and trial allowances are example design content, not project results or current commercial terms. Release status and measured outcomes are not claimed.
The designs cannot establish whether users distinguish an estimate, consumption total, and invoice.
What to validate next
The following is a proposed validation plan, not research already conducted:
- Ask game-team participants to explain which services are active and what each next action changes.
- Test whether they can identify a cost driver from the top-level balance without confusing consumption with an invoice.
- Check understanding of taxes, billing periods, trial limits, and mixed service states.
- Review empty, pending, failed, and restricted states with billing, support, and engineering stakeholders.
- Establish a baseline before measuring task success, time to explanation, or billing-related support volume.
Learnings
- What worked in the design
- Repeated structures connect service access, consumption, and payment without treating them as one value.
- What I would change next
- Test explanation tasks with game teams and billing stakeholders, then baseline billing-related support and task completion before measuring improvement.
