Teams operating dozens of brand sites live across Google Analytics, PageSpeed, documentation wikis, changelogs, and ticket queues, one tab per question. Pandora's Box asks a simple thing: what if the portfolio had a home? Not another dashboard bolted onto the pile, but the single surface where you see a site, understand it, read how it is built, and ask for what it needs next, without leaving.
The challenge
Operating a large multi-brand portfolio fragments attention. Site status lives in one tool, analytics in another, performance audits in a third, design-system documentation in a fourth, and feature requests in chat threads that never reach the backlog. The cost is not just time spent switching tabs, it is decisions made without the full picture, and small operational truths, a slow page, a stale doc, a repeated request, that go unseen because no single surface holds them together.
- Site health, analytics, and performance data scattered across four or five disconnected tools
- No portfolio-level view of which brands and markets a team operates
- Design-system documentation divorced from the sites that consume it, so it drifts and rots
- Feature requests and feedback lost between chat, email, and tickets, never reaching the backlog
- Every operational question answered by stitching two or three vendor tools together by hand
Discovery & research
Because Pandora's Box is a concept, its discovery phase is a set of explicit design hypotheses rather than conducted user research. I mapped how I run a multi-brand portfolio day-to-day, audited the tools currently answering each operational question, and tore down existing operations dashboards, then stated plainly the assumptions the design would stand or fall on.
The morning question sequence is predictable
Operators running a portfolio tend to open their day with roughly the same sequence: what is live, how is it performing, what changed, and what does the team need next. I used this assumed sequence as the backbone of the navigation, ordering the platform by question rather than by data type.
EvidenceWorking hypothesis drawn from my own operating routine across a multi-brand portfolio, stated as an assumption, not a measured user study.
Answers are scattered by tool, not by question
A single operational question, is this brand healthy, is typically answered by stitching together three or four tools: analytics, a performance auditor, a status check, a ticket queue. The sprawl is organised around vendors, so no tool answers a question end-to-end. Consolidating by question was the design response.
EvidenceMapped from the actual tool landscape used to run the portfolio (Google Analytics, PageSpeed and Lighthouse, changelog docs, Jira); a landscape audit, not participant research.
Documentation drifts away from the sites it describes
In this class of workflow, design-system and module docs usually live in a separate wiki, so they rot relative to the shipped sites. I assumed that co-locating documentation with the site directory, inside the same tool as the data, would keep it honest and used more often.
EvidenceDesign assumption; the failure mode is a familiar one from maintaining system documentation separately from implementation.
Feedback dies in the gap between chat and backlog
Feature requests raised in chat or email rarely survive the trip to a tracked ticket. I treated the request-to-backlog handoff as the highest-value flow to design explicitly, giving requests votes, tags, and a Jira ID so they become delivery work rather than lost intent.
EvidenceHypothesis grounded in the common chat-to-ticket leakage; reasoned through conceptually against a Jira-linked queue, not validated with users.
Admins and members want the same map, at different depths
Rather than fork the interface by role, I assumed a shared information architecture with role-aware depth, members see and act, admins additionally configure, would be cheaper to maintain and easier to learn than two divergent products.
EvidenceDesign principle carried over from earlier role-aware system work; a stated assumption for the concept, not a tested one.
How I approached it
I started from the questions operators actually ask each morning, which sites are live, how are they doing, what changed, and what does the team need next, and structured the platform around that sequence rather than around data types. That gave four surfaces: My Sites as the portfolio front door, Site Data per brand, Documentation and Release Notes for the system, and Ask Hermes for the feedback loop. The navigation follows the operator's intent, not the vendor boundaries the data happens to arrive from.
Mapped the daily operational questions and the tools currently answering each one, then designed the information architecture to follow the questions, not the tools
Designed the portfolio directory: every brand site with URL, operational status, market, and freshness, scannable at a glance
Brought Google Analytics, Lighthouse scores, and Core Web Vitals into one per-site data view, balancing density against readability
Embedded module documentation with live code snippets and instructional video, co-located with the sites that consume it
Designed Ask Hermes: feature requests with votes, tags, and Jira IDs feeding future releases, so feedback lands in the backlog instead of a thread
Layered role-aware depth over a single shared IA so admins and members share one map without forking the interface
Trade-offs
The hard part was scope discipline: a single pane of glass can swallow every feature ever wished for. The concept stays at pre-alpha scope on purpose, directory, data, docs, feedback, with templates and deeper automation marked as coming-soon rather than promised. The second challenge was information design under load, keeping vitals, scores, and trends dense enough to be useful but calm enough to scan, and holding one mental model across content types as different as a status grid, a metrics chart, a documentation page, and a request queue.
- Designing data density that stays scannable, vitals, scores, and trends without dashboard fatigue
- Holding one mental model across very different content types: sites, metrics, docs, requests
- Role-aware views for admins and members without forking the interface into two products
- Keeping the concept honest, scoped as a concept, with unbuilt features clearly marked coming-soon
Final direction
A clean, light operations hub. A My Sites portfolio grid is the front door: every brand with status, market, and freshness. Per-site Site Data combines Google Analytics, Lighthouse diagnostics, and Core Web Vitals assessments in one view. Documentation carries live code snippets and video walkthroughs, sitting beside the sites it describes, and Release Notes track what changed. Ask Hermes closes the loop: requests carry votes, tags, and Jira IDs so feedback lands in the backlog and becomes a release note, not a forgotten thread. One shared information architecture, with role-aware depth for admins and members.
Outcomes
As a concept, Pandora's Box demonstrates an operating model rather than a shipped metric: portfolio teams would get a shared source of truth for site health and system knowledge, and a feedback loop that closes rather than leaks. Its value here is qualitative and directional, it names the operational questions worth designing around and shows an architecture that answers them in order. It is the operational companion to a multi-brand design system, the place where the system meets the sites that run on it.
A portfolio without a home page is a portfolio run from memory.
Internal tools earn adoption the same way products do: by answering the questions people actually have, in the order they ask them, and by making the next action reachable from the surface where the problem first appears.