Overview
- The problem
- A prospective team needs to understand the offer before configuring it: which environment fits, how player demand affects cost, and when to explore, estimate, or contact the provider.
- My contribution
- I designed the pricing-page interfaces shown here: environment selection, pricing explanation, example-package discovery, detailed scenario reading, and routes into estimation or enterprise contact.
- The outcome
- An original public-facing design direction connecting product comparison, commercial explanations, example scenarios, and next actions.
Problem
The source frames show environment comparison, pricing explanations, example scenarios, FAQs, and routes into estimation or contact. They reveal the information architecture being designed, not observed purchasing behavior.
The challenge: make the offer understandable before the tool
The pricing page serves a different question from the calculator. A visitor may not yet know which product, environment, or level of support fits their team. Presenting every technical input immediately would skip the work of explaining the offer.
My design scope connects product framing, environment choice, player-scale pricing, examples, and the next action. The page has to serve different levels of readiness without treating every visitor as either a sales lead or an expert ready to configure a full stack.
My Role
- Company / product context
- AccelByte · AGS public pricing experience
- Users
- Game teams evaluating a backend platform, from initial exploration to more specialized hosting and support needs.
- My role & scope
- I designed the pricing-page interfaces shown here: environment selection, pricing explanation, example-package discovery, detailed scenario reading, and routes into estimation or enterprise contact.
- Evidence available
- Original project narrative and design artifacts retained in this case study.
Process
Environment choices, scenario details, and multiple next-action patterns are preserved as design explorations. The archive does not establish which variant shipped or whether one outperformed another.
- Understand the platform
- Compare environments
- Understand the pricing meter
- Inspect an example
- Estimate or start a conversation
Examples that open into their assumptions
Recognizable game categories give visitors a starting point for exploration, not a quote for their own game.The package gallery uses familiar game categories and exposes a concise service/scale summary. See Details leads beyond the headline amount. The intent is to make a complex offer approachable without pretending that genre alone determines a deployment's requirements.
The complete detail design reveals inputs behind the example. Sample labels, stories, and totals are illustrative, not real customer results.The detail view gives the scenario narrative and service assumptions a readable hierarchy. AGS, AMS, Extend, and the analytics-service example have different input tables. This makes the example inspectable and supports a transition into custom estimation when its assumptions do not match the visitor's game.
Several example figures in the source are draft values. They are not presented as calculation benchmarks or validated quotes. A final content review should align each summary, detailed table, and calculator starting state before publication as commercial material.
Key Decisions
The page must orient an unfamiliar team without becoming the calculator itself. Examples offer a starting point, but require visible assumptions to avoid looking like universal quotes. Self-service estimation and enterprise contact need distinct, coherent routes.
Key design decisions
Start with a meaningful environment choice
Shared and Private Cloud differ in hosting context, not only price. The comparison makes those differences visible before continuing into a configuration.
Inspect the comparisonConnect price to player demand
Player-scale pricing needs a named meter and an explanation. Separate base environment and player demand so a starting price is not mistaken for the whole future bill.
See the pricing model presentationUse examples as starting points, not promises
Game-type packages provide a recognizable entry, while detailed assumptions and a calculator route reveal why one example cannot represent every game.
Explore package details
Trade-offs and design takeaways
- Explain the environment distinction before asking for a detailed workload configuration.
- Separate a commercial starting point from the variable cost of player demand.
- Use recognizable examples, while making their assumptions available for inspection.
- Offer different next steps without making every visitor enter a sales flow.
- Keep pricing terminology and examples coherent across the page and calculator.
The design result is a public-facing information structure for evaluating a game-cloud offer. No conversion increase, qualified-lead improvement, or A/B-test result is claimed. My takeaway is that pricing UX should help a visitor form a correct mental model before it asks for commitment.
Final Solution
The final design direction connects offer comparison to worked examples, estimation, and support for unresolved questions. Historical scenario values remain illustrative rather than current commercial terms.
Compare environments before configuring them
The environment comparison describes the hosting context alongside its commercial entry point. Historical prices are preserved as source copy.The screen groups included platform services before comparing the environments. Shared Cloud describes an operated cloud context; Private Cloud describes a dedicated, isolated environment. The selection requirement and disabled Next action make the first decision explicit rather than allowing an ambiguous configuration to continue.
The important distinction is the relationship between hosting, control, and commercial terms. A price-only comparison would hide why a team might choose one environment over another. The design gives those differences a place before workload-specific detail.
Explain what changes as a game grows
The player-scale meter is explained separately from the environment choice. This is historical pricing presentation, not a current rate card.A separate player-scale section explains that demand affects the price beyond the base environment. Its tiered presentation gives a visitor a high-level model before they enter a custom scenario. The meter definition is part of the explanation, not an optional technical footnote.
This creates a responsibility across the experience: pricing-page terminology, example assumptions, and calculator inputs must describe the same approved commercial model. The file contains variants, so this case does not combine them into a new definitive price list.
Multiple next steps, one coherent page
The full source design shows how comparison, explanation, examples, and contact routes belong to one discovery experience.A visitor ready to explore can move toward a free start; someone planning a configuration can estimate; a team with specialized requirements can contact the provider. The enterprise section is a different path, not a substitute for understandable self-service information.
The page's length is a trade-off. It brings several decision stages together, but creates more to scan. Jump links and distinct sections support different entry points. Whether visitors recognize the correct path should be validated through tasks, not assumed from the presence of a CTA.
Answer unresolved questions in context
The FAQ addresses questions that change how a visitor interprets the offer, rather than adding unrelated marketing content.Meter definitions, movement between environments, and the meaning of a free start are purchase-relevant questions. Keeping them with the pricing experience reduces the need to infer terms from a short plan card. The original explanations remain historical design content and should be checked against approved product policy before reuse.
Outcomes
The outcome is the original public-facing pricing design and its connected decision paths. No pricing-page conversion uplift or approved production variant is claimed.
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.
A complete explanation can still fail if people choose the wrong environment or mistake examples for quotes.
What to validate next
The following is a proposed validation plan, not research already conducted:
- Ask prospective teams to compare environments and explain the differences without relying only on the entry price.
- Check whether visitors distinguish base hosting, player-scale pricing, support, and add-on costs.
- Test whether package examples help orientation or encourage misleading assumptions about a real game.
- Evaluate discoverability of calculator, free-start, and enterprise-contact paths for different levels of readiness.
- Review the full page, example tables, FAQs, and calculator against one approved commercial model.
- Establish a baseline before measuring comprehension, task success, or conversion.
Learnings
- What worked in the design
- Comparison and example assumptions prepare the visitor for a more detailed estimate.
- What I would change next
- Test environment choice and price comprehension with game teams, then instrument the path from comparison to estimate or qualified contact.
