Proposal v2

Monitor
dashboard IA

Restructuring information architecture based on
dashboard IA research and a comparable case study.

Precedent

The Vonage problem

Vonage's dashboard nav grew organically as they expanded from one product to many — ending up with a "long product-based list" where users couldn't find what they needed.1 This is exactly our situation: the monitor sidebar grew from a few bots to bots + terminals + 5 pages + external links, with Library accumulating 6 unrelated sub-tabs.

Vonage restructured their nav into 4 task-based groups (Quick Links, Build & Manage, Troubleshoot & Learn, More) and validated it with tree testing. Result: 19% increase in navigation success rate.1

The key insight: they stopped grouping by product (entity) and started grouping by what the user is trying to do (intent). Our proposed restructure follows the same approach.

Audit

What's wrong now

1
No overview

There's no "is everything OK?" page. Users should be able to "grasp the available breadth of information first, then focus on the area of interest."2 Currently you land on a bot detail and have to click around to assess colony health.

2
Library is a junk drawer

Knowledge, Ideas, Requests, Recall, Schedule, Inbox — six unrelated things behind one label. This is product-based grouping ("it's all library stuff") rather than task-based ("what am I trying to do?"). The Vonage case showed this pattern directly hurts findability.1

3
Controls are buried

Bot restart is the 5th item in "Pages." GoodData's hierarchy principle: "align visual and logical hierarchies."2 Actions on a bot belong where you're viewing the bot, not in a separate page.

4
Duplicate content

Colony > Tools and System > Tools show the same data. When content appears in multiple places, users can't build a reliable mental model of where things live. NN/Group's information foraging theory (Pirolli & Card, 1999): duplicate entries split the "information scent" and reduce confidence in navigation paths.4

5
"System" is vague

Servers, Infrastructure, and Tools are three different concerns under one ambiguous label. Clearer labeling directly improves navigation success rates.1

6
Nav overload

Simpler navigation structures consistently outperform complex ones in tree testing (NN/Group). A sidebar is the right pattern for our complexity — "ideal for complex systems" with frequent view-switching5 — but ours is overloaded. Collapsible sub-menus are the admin panel standard.6

Before / After

Current vs proposed

Current — product-based
maexbot bot
party-palace bot
cronus bot
forge bot
+ custom bots...
tmux sessions
Controls
Colony
System
Servers
Infrastructure
Tools
Library
Knowledge
Ideas
Requests
Recall
Schedule
Inbox
Experiments
System Metrics
Proposed — task-based
Overview new
maexbot
party-palace
cronus
forge
+ custom bots...
Colony ...talk to the colony
Queue ...see what's queued new
Knowledge ...look something up
Infrastructure ...check the server
tmux sessions
Changes

What moves where

Research-driven
Add Overview page. Eye-tracking shows users scan dashboards in an F-pattern — top-left first, then down the left side.3 The 40-30-20-10 space rule gives concrete layout targets: 40% to bot status grid, 30% to system health/alerts, 20% to colony activity trends, 10% to navigation.3 This is the most research-informed change — the specific layout guidance directly shaped the design.
Research-driven
Split Library into Queue + Knowledge. The Vonage case study showed that restructuring from product-based to task-based grouping produced a measurable 19% improvement in navigation success.1 Library groups by data type ("it's all reference material"). Queue and Knowledge group by intent: "what needs doing" vs "what do I know."
Research-validated
Move Controls into bot detail page. Design instinct: per-bot actions belong in context. Backed by GoodData's hierarchy principle: "align visual and logical hierarchies."2 Vonage's "Quick Links" pattern also supports surfacing high-frequency actions at point of use.1
Research-validated
Deduplicate Tools. Common sense: having the same content in two places is confusing. Backed by information foraging theory — duplicate entries split the "information scent" and reduce user confidence in navigation paths.4
Design instinct
Rename System → Infrastructure. Clearer label. No specific research drove this — it's a naming improvement.
Design instinct
Move Experiments to bot detail. It's Cronus-specific content in a colony-wide nav. No research needed — it just doesn't belong at the top level.
Confidence

What we know vs what we're guessing

High confidence: Task-based nav outperforms product-based nav. The Vonage case study measured this directly — 19% improvement — and our monitor has the same structural problem.1

High confidence: An Overview page will reduce time-to-insight. The 40-30-20-10 space rule gives us a concrete layout framework.3 Progressive disclosure (overview → detail) is well-established UX pattern.2

Medium confidence: The specific groupings (Queue vs Knowledge) are reasonable but untested. Ideally we'd validate with card sorting, but the user base is small (Max + bots). We can iterate quickly if the groupings feel wrong.

Retracted: The "40% engagement drop beyond 12 items" stat cited in v1 traces to DesignRush but not to a verifiable primary source. We've removed it. The directional claim (simpler nav outperforms complex nav) still holds per NN/Group's tree testing research, but we can't put a specific number on it.

Sources

References