Overview
- The problem
- A game team's projected cost depends on more than a subscription tier: service selection, hosting, player demand, workload shape, resources, and support all contribute.
- My contribution
- I designed the calculator interfaces shown here: service configuration, workload inputs, cost summaries, mobile estimate access, and the estimate-download handoff.
- The outcome
- Original desktop and mobile designs connecting configurable inputs to a reviewable estimate and a shareable record of its assumptions.
Problem
Desktop and mobile frames show the dependencies between service choices, workload inputs, resources, and estimates. A design recommendation accompanies the mobile estimate comparison.
The challenge: forecast a system before using it
This calculator belongs before adoption. The user is planning a possible configuration, rather than reviewing the actual consumption and invoices shown in the Billing & Usage case. Keeping that distinction explicit is essential: an estimate is a scenario, not an amount already owed.
The task crosses commercial and technical questions. A hosting choice changes the environment; multiplayer demand introduces sessions and regional traffic; an extension brings CPU, memory, operation, and logging assumptions. The interface needs to expose enough of that model to support a decision without forcing every user through every field.
My Role
- Company / product context
- AccelByte · AGS pricing calculator
- Users
- Game developers and technical decision-makers planning a cloud configuration, with commercial stakeholders reviewing its estimate.
- My role & scope
- I designed the calculator interfaces shown here: service configuration, workload inputs, cost summaries, mobile estimate access, and the estimate-download handoff.
- Evidence available
- Original project narrative and design artifacts retained in this case study.
Process
The record includes configuration variants, workload inputs, mobile estimate-access alternatives, and the download handoff. The paired mobile frames preserve the actual review context rather than presenting an invented A/B-test winner.
- Choose services
- Set hosting and demand
- Configure workload assumptions
- Review component costs
- Save or discuss the estimate
An estimate that stays reachable on mobile
Original interface designs. Example amounts are historical design content, not validated costs. Open either screen to inspect the complete original.Keep the estimate within reach.
The mobile design moves the estimate into a persistent entry and an expanded sheet, instead of squeezing the desktop sidebar.
The trade-off
Less simultaneous comparison; more room to configure. Focus order, dismissal and control overlap remain validation tasks.
“Insan has excellent communication skills and always articulates his design decisions with clarity and confidence.”
Adi RitongaSenior UI/UX Designer · AccelByteManaged Insan directlyLinkedIn recommendation Key Decisions
A simple price field would hide the assumptions behind cloud cost. The design exposes configuration while grouping explanations by resource. On mobile, estimate access competes with input space; a reachable summary must not conceal the assumptions it summarizes. Prices are historical design examples.
Key design decisions
Reveal complexity through the selected service
AGS, AMS, and Extend need different inputs. A shared expandable structure supplies consistency without presenting every technical field at once.
See service selectionKeep the assumptions beside the estimate
A forecast becomes more useful when a team can inspect the player, workload, region, and machine inputs behind it, not only a total.
Inspect the technical modelAdapt the estimate's location, not just its size
Desktop can place configuration and estimate side by side. Mobile uses a persistent estimate entry and an expanded sheet, preserving access without squeezing the sidebar.
Compare mobile states
Trade-offs and design takeaways
- Use a shared configuration pattern, but retain each service's units and dependency rules.
- Make assumptions inspectable before asking someone to trust a forecast.
- Pair exploration controls with readable numeric values and explicit units.
- Adapt the relationship between configuration and summary across devices.
- Carry the scenario's inputs into its export, not only the headline cost.
The design result is a connected planning experience across service choice, workload specification, forecast review, and handoff. No improvement in estimate accuracy, completion, conversion, or support volume is claimed. My takeaway is that a trustworthy estimate is an explanation of assumptions, not just a number displayed with confidence.
Final Solution
The desktop and mobile designs connect service configuration to a cost breakdown and a shareable estimate. Input explanations, summary access, and the download flow are shown in their original context below.
A configurable stack, not a fixed plan
The updated service-selection design gives AGS and AMS independent selection controls. Hosting and daily player-demand inputs sit inside the relevant service. Support and other services follow in their own sections. A separate estimate area provides a second reading level while the main column remains focused on configuration.
The design separates configuration from the forecast summary. Displayed prices and totals are example design values, not a validated cost calculation.The common pattern is service → configuration → cost breakdown. What varies is the meaning of the inputs. That balance allows the page to grow with a product stack without making a server workload look interchangeable with player concurrency or support.
The source also includes support prerequisites and unavailable service states. These are dependency rules to make understandable at the point of selection, not simply controls to disable. Their final production behavior requires agreement with the commercial and engineering model.
Translate game demand into workload inputs
AMS configuration starts with the game mode and workload: players per session, buffer percentage, egress per player, and sessions per VM. Regional PCCU makes the geographical distribution explicit. Machine specifications then show the chosen instance alongside CPU and RAM details.
Workload, traffic distribution, and machine choice remain named assumptions rather than disappearing behind a monthly total.The sliders support exploring a range, while numeric values and unit labels make the selected assumption inspectable. The More Game Mode action extends the model to another workload rather than requiring a single averaged input to represent every mode.
The annotations make CPU/memory compatibility and unavailable instances explicit. I designed those constraints alongside the inputs so that valid choices could remain discoverable.
Different resources need different explanations
A repeated configuration grammar accommodates different resource models without flattening their meaning. Open each complete design at full size.Bare Metal introduces a workload-share assumption and separate machine choices. Extend instead exposes application type, CPU and memory needs, operation volume, egress, and log ingestion. More Application supports another extension workload. These details are the systems-thinking core of the calculator, not additional standalone portfolio projects.
The source includes unfinished placeholders and differing example totals. Before implementation, the calculation model and interface values need a shared review with engineering and commercial stakeholders.
From a browser scenario to a shareable estimate
The download step retains the estimate beside a contact form. Name, company, and email fields support the handoff; the updates checkbox is explicitly optional. Submit & Download is shown as unavailable before completion, making the form state part of the intended flow.
The planned configuration remains visible during the handoff. The optional marketing choice is distinct from the contact fields.There is a real product trade-off here. Contact details support a commercial conversation, but gating an estimate can add friction to a planning task. That tension deserves measurement rather than an unsupported claim that the form improved lead quality.
The export keeps assumptions with the forecast, so a teammate can inspect what the number represents. This is an export design, not a tested download.The file also contains spreadsheet-format exploration. Document and spreadsheet formats serve the same handoff: preserving a scenario outside the interface. Neither export format is presented as a working integration in this case study.
Outcomes
The design deliverable makes assumptions reviewable alongside an estimate. Calculation accuracy, current prices, launch approval, and a conversion outcome are not established by these frames.
Evidence & limitations
The screens document my interface design, not project results or current commercial terms. Prices, totals, workloads, and game examples are historical/sample design content. The file contains variants; no approved release, calculation accuracy, research results, or measured impact is claimed.
Reviewing a design cannot establish whether users enter realistic workloads or whether the calculation is correct.
What to validate next
The following is a proposed validation plan, not research already conducted:
- Ask representative game teams to create and explain a realistic configuration, including units and workload assumptions.
- Test whether they can identify a cost driver and compare two scenarios without confusing a forecast with an invoice.
- Check invalid combinations, machine eligibility, support prerequisites, and contact-sales thresholds with engineering and commercial stakeholders.
- Validate mobile sheet focus, dismissal, numeric-input behavior, and persistent estimate access.
- Evaluate whether a shared export contains enough context for a teammate to review independently.
- Verify the calculation model, tax rules, rounding, and export consistency separately from interface usability.
Learnings
- What worked in the design
- The estimate stays connected to the technical assumptions that create it.
- What I would change next
- Validate input comprehension and mobile summary access, then compare estimated versus actual costs using an implemented calculator and a documented baseline.
