CloudSun
Designed a 24-route operations workspace without losing the operator.
A call-centre workspace has live queues, agent states, escalations, compliance steps and reporting all demanding attention at once — the default outcome is a dashboard wall an operator scans instead of reads.
SAAS
CloudSun
- Role
- Product design and front-end architecture
- Scope
- Application information architecture, role-based navigation, dashboard hierarchy, status language system, design system, multi-route frontend.
- Outcome
- A concept workspace proving dense operational software can be designed without drowning the operator. The hierarchy is explicit, the status language is consistent, and 24 routes collapse into a small number of mental models an agent can actually hold.
- Technology
- Next.js, TypeScript, Tailwind CSS, Framer Motion, Zustand
Disclosure. Concept product demonstration, not a commissioned client deployment. Designed end-to-end as an operational workspace; a live interactive preview is available so the 24-route workspace can be explored hands-on.
Operational software fails when it treats every screen as equally urgent. A call-centre workspace has live queues, agent states, escalations, compliance steps and reporting — all demanding attention at once. The default outcome is a dashboard wall that an operator scans instead of reads. The design problem is hierarchy: deciding what an agent, a supervisor and an admin each need to see first, and making the rest reachable without being loud.
- Twenty-four distinct application routes across the product
- Three primary roles with overlapping but unequal needs
- Information density that must not become visual noise
- Eight-hour daily use — every interaction tax compounds
- Status language that must mean the same thing across routes
- Concept project — no real call-centre data to validate against
The structural decisions that shaped the solution — explicit and arguable, not hidden inside a polished screen.
- 01
Role-weighted priority grid
Mapped all 24 routes to a role-weighted priority grid before designing any screen.
- 02
Shared status language
Defined a status language (open, holding, escalated, resolved, breached) reused across every route so an operator never re-learns meaning.
- 03
Now vs later
Separated "now" surfaces (live queue, active case) from "later" surfaces (reports, config) at the navigation level, not just visually.
- 04
Density as a primitive
Built a design system where density is a primitive — compact tables, inline status, keyboard-first actions — rather than a compromise.
- 05
Motion signals state
Scoped motion to signal state change, never to decorate.
- Primary operator workspace as a single focused queue with contextual action
- Supervisor views as overlays on the operator view, so context is never lost
- Status component system reused verbatim across all 24 routes
- Keyboard-first navigation for power-operator use
- Documented route map and role matrix as a living artifact
A concept workspace that proves dense operational software can be designed without drowning the operator. The hierarchy is explicit, the status language is consistent, and the 24 routes collapse into a small number of mental models an agent can actually hold.
- Application routes
- 24 routes mapped to a role priority grid
- Role-based workflows
- Agent, supervisor, admin
- Status language
- Shared system reused across routes
- Dashboard hierarchy
- "now" vs "later" separated at nav level
- Design system
- Density as a primitive
- Keyboard navigation
- Power-operator first
As a concept project there is no real call-centre data to prove the hierarchy works. The honest mitigation is that the route map and role matrix are documented as artifacts an operator could audit — the design decisions are explicit and arguable, not hidden inside a polished screen.
Route map
Mapped 24 routes to a role priority grid.
Status language
Defined the shared status system.
Operator surface
Designed the focused queue workspace.
System
Built the density-first design system.
Technical material kept secondary — for the engineering reader who wants to look under the hood.
- Front-end architected for a large route count without a monolithic bundle — route-level code splitting and shared layout shells.
- Zustand stores scoped per role-context to keep operator state local and fast.
- Motion library scoped to state transitions; respects prefers-reduced-motion everywhere.
- Design tokens emitted for status colours so the status language is enforced at the token layer.