Infrastructure was becoming
a design problem.

The TimeTravel control let operators rewind Weave Cloud to any point in time and replay how their infrastructure looked and behaved. Designed and built as a reusable component in the shared library, it became one of the most distinctive UX moments in the Weaveworks product suite.

Four distinct Weaveworks products — Weave Cloud, Weave Scope, WKP, and Weave GitOps — were being built by separate engineering teams. Without a shared component library, design diverged silently: different button styles, inconsistent spacing, conflicting colour usage. The ui-components library gave every team a single source of truth: documented, versioned, and hot-reloadable. Bianca shaped the component API design and the Style Guide that underpins it — making the design system real, not just aspirational.

The component documentation site rendered each component's prop table, live example, and source markup side by side — built with react-docgen, hosted on S3, now preserved on the Wayback Machine.

29 components · Style Guide Alert · Button · CircularProgress · Code · DataTable · Dialog · Dropdown · GraphEdge · GraphNode · Grid · GridColumn · GridRow · Input · ListItem · LogoProgress · MatchedText · Menu · MenuItem · PrometheusGraph · ResourceDial · Search · Tab · TabSelect · Text · TimeTravel · TimestampTag · WeaveCloudLogo · WeaveLogo · WeaveWorksLogo

Notable: PrometheusGraph — live metric time-series · TimeTravel — rewindable infrastructure state · GraphEdge & GraphNode — Scope topology primitives · ResourceDial — CPU/memory gauge

Slide-out creation flow — Name, Model, Provider (AWS: EKS), Region, K8s Version, Node groups. The cluster list behind shows green "Ready" dots. The terminal-to-GUI moment.

Fleet overview — "Clusters 14 + Create Cluster" with a table of all clusters across regions. Nav: Clusters · Models · Policies · Dashboards · Teams. The control room for a Kubernetes estate.

"Models 3 + Add Model" — reusable cluster blueprints: Production cluster, Machine learning cluster. Define once, deploy anywhere. GitOps for infrastructure configuration.

Cluster scaling — node counts, status, and inline actions (View cluster, View dashboards). Surfacing the right affordances at the right moment without overloading the interface.

The management cluster itself — GitOps reconciliation status, workload links, and the entry point into the entire managed fleet. The dashboard for the dashboard.

Pre-wired observability — Prometheus, Grafana, Flagger, Flux, Tiller, ingress — and their GitOps-managed status. Complexity bundled into clarity.

The moment of cluster creation — Model dropdown open, showing Production cluster, Machine learning cluster, Search components. Node groups, type (m5.large), and desired capacity. First seen on stage at KubeCon 2019.

An earlier version of the cluster fleet view — the design before the Feb 2020 refinements. Shows the evolution of the system and the design thinking that led to the final product.

The Model template library from the December demo. Pre-built cluster blueprints that could be attached at creation time — a key conceptual leap that simplified operator decisions at scale.

Workspaces gave enterprise teams isolated namespaces within a shared cluster. Designing for multi-tenancy meant making invisible boundaries visible — without making the interface feel divided.

The main workloads view — Kustomizations and HelmReleases with sync status, cluster, namespace, and timestamps. Dark sidebar navigation. The starting point for any operator session.

Drill-down into a single workload — sync status, source, applied revision, conditions, events. Everything you'd otherwise get from five kubectl commands, in one scannable view.

The topology graph — a visual map of how GitOps sources, kustomizations, and deployed objects relate. The same instinct that drove Weave Scope's topology visualiser, now applied to GitOps.

Inline YAML inspection — any resource, readable in context. No terminal. No context-switching. Designed for the operator who needs to verify, not just observe.

GitRepositories, HelmRepositories, Buckets — all tracked sources with sync intervals, last-fetched timestamps, and ready status. The inputs to the GitOps pipeline, surfaced clearly.

The Flux controllers themselves — source-controller, kustomize-controller, helm-controller, notification-controller — with versions and running status. Visibility into the engine under the hood.

The full Enterprise UI in dark mode at 3388×1684. Left nav: PLATFORM · DELIVERY · GUARDRAILS · DEVELOPER EX. The Clusters view with Create / Connect / Delete PR actions. The dark theme toggle visible top-right.

The same Enterprise UI in light mode — multi-cluster fleet management, GitOps fleet view, and the full sidebar navigation. The polished end-state of six years of design iteration.

Deployed applications with sync status, cluster, namespace, and source — all in a single scannable table. The GitOps feedback loop, made legible for teams who don't live in the terminal.

All installed Flux controllers with version info and running status. Giving platform teams visibility into the GitOps engine powering their clusters, without needing kubectl.

GitRepositories and HelmRepositories tracked by Flux — URL, branch, sync interval, ready status. The inputs, always visible, always current.

The full sync history and event log for a deployed application. The GitOps feedback loop made auditable — every reconciliation, surfaced in time order, with context.