Equinix had one MVP and seven monitoring surfaces. I designed the system that held them together.

The project started in the middle. I first worked backward from the approved MVP and the available research, then moved forward through discovery, definition, structure, prototyping, and detailed visual design.

Two jobs, one artifact

Mapping the requirements against the MVP let me learn the DCIM domain while recovering the product logic. It also gave the producer, product manager, and engineering team a shared reference for what existed and what remained.

The approved MVP had no sitemap in the handoff. I reconstructed one from the product so the team could see the account, dashboard, reporting, notification, and monitoring branches as one system.

The alternatives below come from choices documented in the project archive. Where the record does not preserve a formal option set, the case states only the opposing path that the source directly describes.

One product tree, redrawn as accessible nodes

This redraw transcribes the named destinations in the original sitemap and groups the repeated monitoring sections under one facility branch. It is a portfolio redraw, not an original 2016 deliverable.

The archived use-case framework preserves the major transitions but not every branch or validation state. These diagrams rebuild three complete paths and label them as reconstructions.

Seven screens form the operating model: one overview, four monitoring surfaces, and two exception surfaces. The map shows the repeated navigation and the transitions between status, asset detail, alarms, and alerts.

These low-fidelity frames isolate the shared layout decisions from the detailed visual design. They are reconstructed for this case from the surviving screens.

The four monitoring sections answer the same questions.

Environmental, power, mechanical, and electrical answer the same operational questions: what is happening now, how it has changed, and which asset needs attention. The interface keeps that sequence stable while letting each subsystem carry its own measurements.

The dashboard became an operational overview rather than another report. The redesign removed the right rail, moved global actions into the top frame, and made the four facility states visible together.

MVP feedback showed that customers wanted live temperature and humidity trends up front. The redesign moved trends into the primary scan, kept the detailed sensor table underneath, and removed a reports section that duplicated the same answer.

Power Draw reused the first section template for primary, redundant, contracted, and total consumption at cage, cabinet, asset, and circuit levels. This was the proof that the system could carry different measurements without creating another navigation or data pattern.

Mechanical exposed the limit of strict consistency. Customer feedback identified the long asset list as the problem, so I used a directory tree instead of forcing the shared grid into the wrong job. Electrical retained the shared template and added an asset map for tracing connections.

Alarms are system faults; alerts are thresholds configured by users. The redesign kept that distinction explicit, added deeper filtering, and used persistent banners so a technician could monitor exceptions across IBXs without leaving the current task.

Seven surfaces in one working shell

This interactive recreation is built from the archived screens. Open a facility from the dashboard, move across environmental, power, mechanical, and electrical, then inspect alarms and alerts from the global navigation.

What held up.

• When a project arrives mid-stream, reconstructing the model can be the fastest path forward.
• A shared pattern should follow a repeated user question, not visual sameness alone.
• Exceptions need continuity. A fault should remain visible while the operator changes context.
• Consistency has limits. The Mechanical directory tree earned its difference by solving a different task.
• A platform decision pays off when the next surface gets cheaper to build.