User Journeys designed
AI Cloud user docs should start with what people are trying to do, not with the implementation folders that make it possible.
Core Journeys
| Journey | Start | Success condition | Follow-up page |
|---|---|---|---|
| Get access | Sign in and verify tenant/project context | User lands in the right workspace with the expected role | Account and Access |
| Protect account | Add or manage MFA, sessions, keys | Account posture matches the provider and user intent | Account and Access |
| Launch capacity | Select GPU capacity or app and request launch | Allocation moves to active | Launch and Operate |
| Connect and work | Use browser or SSH access on active workload | Workload is reachable and usable | Launch and Operate |
| Track spend and data | Understand credits, balance, billing, storage | User knows current usage and ownership | Billing and Storage |
| Recover from issues | Handle failed, blocked, or recovery states | User knows the next safe action | Troubleshooting |
| Govern tenant | Review membership, keys, spend, and escalation path | Tenant admin can safely manage the workspace | Tenant Administration |
Role View
- End user: account protection, launch, connect, release.
- Customer admin: membership, project posture, budgets, support escalation.
- App or SDK consumer: switch to Build on AI Cloud once the question becomes integration rather than product use.
Flow Coverage Rule
Every major user flow should exist here before the team claims product completeness. If a page or feature exists in the app but not in this flow map, the documentation portal should treat it as missing coverage rather than done.