Skip to content
All work

Flanksource

Operational visibility

Five tools, one screen

Role
UX/UI Designer
Client
Flanksource
Studio
Nygaard Design
Year
2025

The challenge

Engineers had metrics, logs, and config in Git. What they did not have was one place that told them what needed attention.

What it turned out to be

A dashboard that pulls the actionable item out of each of the five tools and puts it on one screen.

Flanksource began as a Kubernetes consulting firm, so they had seen the same problem repeatedly. Teams had plenty of data and still could not tell what needed attention.

Metrics dashboards, log tools, Git for config. Each fine on its own, none of them connected. Mission Control was built to tie them together, and the dashboard is where that has to be visible.

Domain first

Learning what the five things actually are

I logged into the beta and worked through each component before drawing anything. I could not decide what should surface by default until I knew what each of these meant to the person on call.

  1. 01
    TopologyHow services relate to each other
  2. 02
    PlaybooksAutomated runbooks and their last result
  3. 03
    CatalogThe inventory of what exists
  4. 04
    Health ChecksContinuous probes against services
  5. 05
    NotificationsEverything the platform wants to tell you

The move

Lift the decision, leave the depth

Each tool stays as it is. The dashboard takes only the item from each that needs someone to act, and puts those four things on one screen in priority order.

FIVE PLACES TO LOOKTopologyService healthPlaybooksLast runCatalogNew insightsHealth ChecksWhat is failingNotificationsLatest alertsONE PLACE TO LOOKMission ControlFailing health checks3Last-run playbooks12New catalog insights8Latest notifications5Each tool keeps its depth. The dashboard only lifts the thing that needs a decision.
Five sources, one entry point. Failing health checks lead because they are the only row that implies something is wrong right now.

Engineers did not need more data. They needed to know which of the five places to open first.

Findings

What the immersion surfaced

Four things that shaped the layout

  1. 01

    Engineers needed context, not more data

  2. 02

    Key components were siloed across separate views

  3. 03

    Actionable items were buried inside individual tools

  4. 04

    The terminology was unfamiliar and had to be learned before anything could be designed

Design

Before and after

Moving from wireframes to structural representations meant testing how much density the view could carry before it stopped being scannable.

Before. Components accessible but separate, so status meant five visits.
After. Last-run playbooks, new catalog insights, notifications, and failing checks in one view.

Outcome

One entry point into system health instead of five separate views. Reviewed with the Flanksource product team, and iterated on density and hierarchy from their feedback.

Reflection

What I took from it

  • 01

    I could not have designed this without using the product first

  • 02

    Data density requires strict visual hierarchy