Overview
- The problem
- A new user enters a console with studio and game contexts, multiple products, technical navigation, and several possible next steps.
- My contribution
- I designed the onboarding guidance and homepage experiences, including namespace orientation, setup entry points, trial information, and resource discovery.
- The outcome
- Original onboarding and homepage designs, with a reported average 21.17% increase in registered users and 25% increase in registered-to-active studio conversion.
Problem
The design record includes namespace orientation, guided tours, setup entry points, sample-game routes, and service-specific trial explanations. Reported registration and activation outcomes are separated below from the interface evidence and proposed research.
The challenge: a console is not a single journey
A developer console needs to support both first-time orientation and repeated operational work. The same home area can contain setup, usage, analytics, product discovery, and documentation. Without a clear context and a concrete next step, those options can compete for attention.
I treated the entry experience as a relationship between orientation and action. A tour can identify important regions, but it cannot replace a meaningful setup path. The designs combine namespace guidance, direct configuration actions, and reference material that remains reachable after onboarding.
My Role
- Company / product context
- AccelByte · AGS and AMS onboarding
- Users
- Game teams evaluating and configuring AGS and AMS, with different levels of product familiarity.
- My role & scope
- I designed the onboarding guidance and homepage experiences, including namespace orientation, setup entry points, trial information, and resource discovery.
- Evidence available
- Original project narrative and design artifacts retained in this case study.
Process
AGS and AMS tour sequences and home states show how one guidance pattern changes with product context. The source demonstrates alternatives and states, but does not include an experiment log isolating each change.
- Understand the current namespace
- Review service access
- Choose sample or own-game setup
- Configure the game
- Inspect usage and find resources
Know where you are before configuring anything
The guided onboarding anchors its first explanation to the studio namespace selector. The selected scope remains visible in the sidebar and page title. This supplies a reference point for navigation instead of teaching menu labels in isolation.
The first tour step explains the current studio context. The tour marker belongs to the original design, not a portfolio progress claim.The file includes separate AGS and AMS tour sequences. Their shared structure creates familiarity, while service-specific content acknowledges that a server-management task is not identical to a game-backend task. The key design principle is contextual orientation, not the number of tour steps.
Key Decisions
The console serves both newcomers and returning teams. Teaching every feature at once would compete with setup; a tour alone would not give users a useful task. Service-specific allowances also need explanation without turning the welcome into a technical specification.
Key design decisions
Orient around the current context
A studio and a game are different working scopes. The namespace selector and contextual guidance explain that distinction before deeper navigation.
See namespace orientationMake setup a concrete next step
The homepage provides a direct setup route and a sample-game path, rather than requiring every newcomer to begin by exploring the entire feature catalogue.
Explore the setup homepageExplain the trial in the product's units
AGS and AMS have different technical constraints. Product-specific trial summaries connect those allowances to the activities that may become restricted.
Compare trial explanations
Trade-offs and design takeaways
- Teach the current working scope before teaching every navigation item.
- Pair orientation with a task the user can actually begin.
- Use consistent guidance structures without hiding service-specific constraints.
- Keep learning resources available after the welcome or tour has closed.
The design result is a coordinated entry experience across namespace context, trial explanations, setup, and resource discovery. My takeaway is that onboarding continues in the page hierarchy and available next actions, not only inside a welcome modal.
Final Solution
Namespace context, a concrete setup route, trial guidance, and persistent resources form the entry experience. The original screens below show how orientation and action are connected.
A homepage that points toward action
The game homepage puts Game Setup near the top, followed by analytics, related services, and resources. It gives an early-stage user a concrete configuration entry point while preserving destinations that support a team already working with the console.
The complete source screen shows the hierarchy from setup to operational context and supporting resources. Example analytics are not project results.The Byte Wars sample-game route in the studio experience offers a different kind of entry: learning through an example rather than immediately integrating an existing game. This makes the choice between exploring the product and configuring a real project visible.
There is a trade-off in combining setup, analytics, cross-product discovery, and learning material on one page. It supports several stages of readiness, but creates a longer page with competing actions. The setup hierarchy is the design response; whether that priority is understood remains a question for validation.
Guidance changes with the service
The welcome/trial screens explain access before the user starts relying on it. AGS describes its own limit and period; the AMS example explains instance usage, network egress, image capacity, and fleet constraints. Both connect limits to the activities that can be restricted and point toward Usage for monitoring.
The explanation changes with the service instead of presenting one generic trial limit. Values are historical design examples.The challenge is to disclose enough technical detail to support an informed start without turning the welcome into a specification document. The product-specific grouping gives the details a purpose: understanding what the team can do now and when it needs to review usage or unlock access.
Discovery without losing the working context
AMS and Extend appear as related service opportunities within the home experience. Documentation, community, product updates, and roadmap access sit further down the page. This keeps product discovery and help attached to the current workspace instead of sending every question to an unrelated destination.
Feature-highlight cards are discovery surfaces. Their presence does not establish that I designed the complete underlying Player Tracing, Matchmaking X-ray, or Configuration Migration tools in this case study. The scope here is how the home experience presents and routes to capabilities.
Outcomes
I report an average 21.17% increase in registered users and a 25% increase in registered-to-active studio conversion for this work. My contribution included guided tours, homepage previews, and free-trial design. These are reported project outcomes, not evidence of an isolated experiment or sole causation.
What supports these numbers
- Verification status
- Owner-reported result; not independently verified
- Measurement period
- Not available
- My contribution
- Guided onboarding, homepage previews, and free-trial experience design
- Evidence available
- Owner-supplied resume and original project narrative. No baseline cohort, measurement window, or isolated experiment is available.
Registered users
- Reported result
- Average increase of 21.17%
- Baseline & comparison
- Baseline and measurement period not published.
- Source & scope
- Reported by Insan for the onboarding work; underlying analytics not included.
Registered-to-active studio conversion
- Reported result
- Increased by 25%
- Baseline & comparison
- Baseline and measurement period not published.
- Source & scope
- Reported by Insan; no isolated experiment or sole-causation claim.
Evidence & limitations
Screen amounts, dates, customer names, and trial allowances are example design content, not project results or current commercial terms. The registration and activation outcomes are reported by Insan; baseline figures, measurement periods, and underlying analytics are not included here.
The reported metrics do not isolate the effect of each design change, and baseline figures and measurement windows are not published.
Reported registration and activation outcomes
I report an average 21.17% increase in registered users and a 25% increase in conversion from registered studios to active studios. My contribution included clear guided tours, homepage previews, and free-trial design.
These are project outcomes I report for this work. Baseline figures, measurement periods, and underlying analytics are not included in this case study; no claim of an isolated experiment or sole causation is made.
What to validate next
The following is a proposed validation plan, not research already conducted:
- Ask a newcomer to explain the difference between studio and game context and find the correct setup route.
- Compare the sample-game path with own-game configuration using realistic team tasks.
- Test whether a multi-step tour is helpful or whether some guidance should be shown at the moment of use.
- Check whether returning users can bypass orientation and reach usage or configuration efficiently.
- Define a successful first configuration before measuring completion and time-to-setup.
Learnings
- What worked in the design
- Onboarding continues in page hierarchy and available next actions after the tour closes.
- What I would change next
- Retain a funnel definition and dated baseline, segment first-time and returning teams, and test whether newcomers understand scope and can start setup without assistance.
