Direct answer
Structure the console around objects and their states. Navigation is how you reach the queue. Do not lead with a chart wall. NN/g’s IA vs navigation split is the whole game: get the objects right, then the chrome.
Mobile is not optional
On-call staff use phones. Every list/detail needs a visible back path, a 44 px target, and a programmatic selected state. WCAG 2.2 target size and focus-not-obscured apply to operator tools, not only marketing sites.
A practical sequence
Design the object, then the list, then the chrome.
- Name the primary object (request, ticket, workspace)
- Define list, detail, and one mutation
- Expose filters as query state, not only hover menus
- Keep destructive actions behind a confirmation bound to the exact set
- Pause decorative motion when the document is hidden
Design system, not a new product
Reuse the marketing tokens if they meet contrast. Do not invent a second palette for ‘admin’. Empty, loading, and error are the states that make a system; the rest is decoration.
What to send if you want a senior review
Share the primary object and whether staff work on a phone. Related work at Kiwi: design system and product UX optimization. Walkthroughs available on request.
Frequently asked questions
Should the console share the public website header?
Share tokens and components. Do not share the marketing nav or the cookie banner behaviour if the console is authenticated and separate.
How many nav items?
Fewer than the number of jobs. If everything is top-level, nothing is ranked.
Can we demo the console?
Yes, with seeded tickets. We do not expose production operator tools as a public URL.
Sources
- Nielsen Norman Group — Information architecture vs. navigation
- W3C WAI — Accessibility fundamentals
- W3C — How to Meet WCAG 2.2
Figures cited above are drawn from the linked publications and are the responsibility of their sources; we date and scope them rather than presenting them as universal guarantees.