User Interactions designed
This page explains the main GPUaaS interactions for teams learning the product. It is intentionally journey-first: what the user is trying to do, what the product shows, and which backend capabilities support the flow.
Navigation Model
| Product area | User intent |
|---|---|
| Overview | See account state, billing posture, active work, and attention items |
| Workloads | Operate active and historical allocations, apps, and tasks |
| Infrastructure | Browse catalog, launch compute, inspect allocations, manage storage |
| Apps | Browse, deploy, and manage GPUaaS apps |
| Access | Manage projects, team, SSH keys, API keys, and policy surfaces |
| Developer | Read docs, download artifacts, inspect APIs, and build apps |
| Ops/Admin | Manage platform health, inventory, users, audit, payments, and incidents |
Core User Journeys
| Journey | User interaction | System behavior |
|---|---|---|
| Sign in | Choose work or personal account path, authenticate, land in product shell | Validate identity, establish session, load profile, tenant/project, and first-run state |
| Launch workload | Choose SKU, capacity, image, network, access, review, and submit once | Validate availability, policy, balance, idempotency, and create allocation/task |
| Track provisioning | Follow task progress and allocation state | Move through lifecycle states and expose failures/retry paths |
| Operate allocation | Open console, metrics, SSH/access, storage, and release actions | Mint terminal token, validate ownership, relay access, collect usage, audit actions |
| Billing and payments | View balance, usage, low-balance state, checkout, and return status | Rate usage, write ledger entries, process Stripe webhook, emit billing events |
| Project/access management | Create projects, switch context, manage members/keys/policies | Enforce tenant/project scope and write audit evidence |
| Storage | Upload, browse, download, rename, delete, and attach data | Enforce namespace/path safety and object storage operations |
| Admin operations | Manage nodes, users, allocations, audits, payments, and health | Expose admin-only APIs, operational read models, and privileged audit logs |
| App builder | Read SDK docs, define manifest, test app, promote artifact | Validate app contract, credentials, runtime expectations, and promotion evidence |
Important UX Rules
- Launch is a full-page workflow with one idempotent submit path.
- Terminal access uses short-lived tokens and websocket session binding.
- Allocation states must remain visible after actions; rows should not appear to disappear without a status path.
- Billing warning and depleted states must be persistent and understandable.
- Admin surfaces are platform-admin operations; tenant-admin journeys remain tenant-scoped and separately modeled.
- Department attribution is mandatory in the platform model, but the UI keeps the default department hidden for one-department tenants. Department selectors and filters appear only when multiple departments exist or an explicit department capability is enabled; department admins, budgets, and approvals remain separate shipped capabilities.
- Developer docs should feel like part of the product shell, not a disconnected static reference.