Overview
- The problem
- Cancelling one cloud service has consequences for access and billing, but does not always mean that every other service stops working.
- My contribution
- I designed the cancellation/deactivation journeys and recovery states, including confirmations, failures, payment restrictions, grace messaging, and reactivation entry points.
- The outcome
- A documented lifecycle across AGS, AMS, and Extend with explicit service-specific consequences and next actions.
Problem
Cancellation, loading, failure, cancelled-service, restriction, grace-period, and reactivation screens document the lifecycle. They establish designed consequences and recovery paths; cancellation analytics and support findings are not supplied.
The challenge: an exit is still a product experience
A cancellation flow has to answer several questions at once: which service is being changed, when the change completes, what happens to access, and what charges remain. Those questions become harder when a team uses multiple related services with independent states.
My scope covers both the request and what follows it. I designed the confirmation, in-progress, success, and failure surfaces alongside reactivation and restriction messaging. The story is about preserving understanding through a state change, not about claiming improved retention.
My Role
- Company / product context
- AccelByte · AGS, AMS, and Extend subscription lifecycle
- Users
- Game teams changing their service subscriptions and reviewing what remains available or payable.
- My role & scope
- I designed the cancellation/deactivation journeys and recovery states, including confirmations, failures, payment restrictions, grace messaging, and reactivation entry points.
- Evidence available
- Original project narrative and design artifacts retained in this case study.
Process
The archive explores the states around a transition, not just its confirmation dialog. It includes failure and recovery alongside the intended path, without claiming a tested or shipped state machine.
- Review consequences
- Confirm the service change
- Receive progress or failure feedback
- Understand remaining access
- Review usage or reactivate
Feedback through the transition
Submitting the request creates an in-progress state; failure has a distinct destination with support and a route back to Billing. The interface does not silently replace an unresolved operation with a success message. Clear feedback matters because uncertainty here can prompt repeated requests or a mistaken belief that access has already changed.
In-progress and failed operations remain distinct. These are designed states, not a claim that server-side cancellation was tested.Key Decisions
Cancelling one service does not necessarily end all access. A reusable transition pattern must retain service-specific consequences, billing responsibilities, and recovery. Clarity and control take priority over making the exit hard to find.
Key design decisions
Explain consequences before confirmation
Access changes, completion timing, and outstanding billing expectations belong before a consequential action, not only in the message after it.
Inspect the cancellation designKeep each service's state independent
An AGS cancellation should not make an active AMS subscription appear cancelled. Confirmation and usage views communicate remaining access explicitly.
See service continuityMake recovery contextual
A reactivation action appears next to the affected service and its retained usage context. Restrictions are explained where they block an action.
Explore reactivation and restrictions
Trade-offs and design takeaways
- Name the affected service instead of using ambiguous account-level success or failure copy.
- Explain access and financial consequences before a user commits.
- Keep retained usage readable without misrepresenting current service availability.
- Make unavailable actions understandable and recovery routes discoverable.
The design result is an explicit lifecycle across cancellation, continuity, restrictions, and recovery. My takeaway is that trust is earned at the uncomfortable moments: when an operation fails, when a service stops, and when the user needs to understand what is still true.
Final Solution
The design connects an informed exit to transition feedback, remaining access, payment context, restrictions, and reactivation. Original states below show the consequences close to the relevant action.
A clear exit starts before the button
The cancellation screen names the exact AGS offering and explains completion timing, invoice expectations, and the change in access. Keep Subscription and Cancel Subscription remain visibly different actions. The information is attached to the decision instead of deferred to a help page.
The left-hand decision area explains the exit. Product marketing testimonials on the right are original screen content, not endorsements of my work.The design also exposes a tension worth acknowledging: the adjacent marketing content competes with a sensitive exit task. A respectful experience should make the customer's intended action clear even when retention messaging is present. That balance deserves explicit evaluation rather than treating a testimonial column as proof of successful retention.
Cancelled does not mean everything is unavailable
The confirmation identifies AGS as the cancelled service and explicitly says that an active AMS subscription remains usable. It offers Review Usage Detail and Go to Home as next steps. This makes the success message useful beyond announcing completion.
The confirmation carries the service dependency logic into the next step.This distinction continues in the Usage view. Historical consumption remains visible, while the affected AGS area receives an unsubscribed notice and a Reactivate AGS action. AMS remains represented separately. A single account-level disabled screen would hide this nuance.
Recovery where the problem is visible
Reactivation sits beside the affected service, while other services and retained usage remain readable.The recovery action is placed where the user can see why it is needed. Retained usage supplies context for a decision to return, without implying that a cancelled service is currently active. The source includes reactivation entry points from Billing and Home as well as Usage, so the user does not need to remember one hidden recovery location.
Restrictions need an explanation
Two supporting designs communicate different constraints: Payment explains a cancellation/deactivation-related hold and disables its update action; the homepage announces a grace period during which service activation is unavailable. These should remain distinct messages because they affect different tasks.
Availability is communicated in context. A shared warning treatment should not blur the difference between the two restrictions.The design makes the limitation visible, but a production review should still confirm timing, eligible actions, and what changes when the restriction ends. Backend completion rules and recovery guarantees are outside what a static design export can prove.
Outcomes
The outcome is a documented service-specific lifecycle and recovery design. No retention lift, cancellation reduction, or support-volume change is claimed.
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.
Designed feedback cannot establish correct backend state, billing behavior, or users' understanding of what remains accessible.
What to validate next
The following is a proposed validation plan, not research already conducted:
- Test whether customers can explain which service is cancelled and which remains usable.
- Check understanding of completion timing, retained usage, and remaining billing consequences.
- Evaluate whether retention content interferes with a clear, voluntary exit.
- Exercise failure, repeated-request, pending, and reactivation paths with engineering and support.
- Measure comprehension and recovery task success only after establishing an agreed baseline.
Learnings
- What worked in the design
- The post-cancellation experience is treated as part of the product rather than an ending screen.
- What I would change next
- Review the state model with engineering and billing, test consequence comprehension, and exercise interrupted transitions and reactivation before measuring outcomes.
