Data Center Composer

Overview

I designed Fungible Data Center Composer’s composition experience, a suite for assembling and operating bare-metal data-center resources. From concept to MVP, I translated cloud-scale infrastructure into workflows administrators could understand and adapt.

Make composable infrastructure actionable

Composition joined physical servers, storage, networking, and virtual constructs, but users needed control rather than vocabulary to decode. With one month for initial wireframes, I relied on market research, white papers, the founder’s vision, and assumptions before customer input.

01 · Define the shared model

Give the environment a stable meaning

I mapped Data Center Admins, who manage inventory and allocation, alongside Tenant Admins, who allocate capacity across teams. The map surfaced permissions, handoffs, and edge cases before interface detail made them expensive.

I used concept maps and an environment/template metaphor to create shared language with product and engineering. As names shifted, I reframed the model so the workflow remained legible without hiding physical and virtual relationships.

Design decision: I chose an environment-centered model, with templates as reusable definitions and instances as deployable parts.

02 · Redesign navigation

Make complex environments easy to traverse

After the MVP launch, engineers and stakeholders said the environment page was difficult to navigate; lists and cards obscured the path to an instance. I reviewed the existing page, interviewed two engineers, and incorporated customer feedback gathered by the UX team.

I explored structures that privileged instances or server specifications, then tested a tree for a single environment. The final direction flattened the hierarchy, made sections expandable for scale, and added instance overview and quick links while retaining monitoring context.

Design decision: I replaced competing cards and lists with an expandable tree that made hierarchy, scale, and direct access visible together.

03 · Iterate creation

Turn configuration into a guided commitment

I iterated the creation flow around three constraints: people had to understand configuration choices, deploy with fewer errors, and use a UI the team could build. A preview-and-bind exploration exposed the cost of ambition and was backlogged.

FDC 1.0 started with a reduced card layout. In FDC 2.0, I used a two-column, checkout-like review with resource counts; a later FDC 3.0 direction expanded GPU, boot-source, and Cloud-init options while carrying forward clearer hierarchy and consistent add/edit patterns.

Design decision: I sequenced the workflow from a simple card pattern to a reviewable configuration flow instead of shipping every option at once.

04 · Scale templates safely

Make reuse accountable across tenants

I designed the template experience as more than a save action: a Tenant Admin could reuse a composed environment, while a Data Center Admin could review promotions and manage access to shared catalog resources. The flow made ownership visible where multi-tenant work can otherwise become opaque.

I then shaped version control so teams could preserve a test environment as a version, update it deliberately, or return to an earlier state. Template-card exploration reduced specification clutter and supported a scalable pattern, not a one-off marketplace.

Design decision: I connected promotion, role-based review, and version history so reusable infrastructure could move between tenants with clear stewardship.

An MVP and a durable systems-design lesson

The MVP launched in August 2020. I continued to evolve the experience through subsequent iterations, but the final release was pending when product direction changed and the product was retired.

• I turned a new infrastructure concept into an environment-centered workflow.
• I gave administrators a scalable path from structure to instance-level action.
• I established reusable patterns for creation, sharing, permissions, and versioning.

Design for learning as well as operation

I learned that innovative infrastructure needs both education and familiar interaction patterns. The concept evolved toward a third version before product direction changed, reinforcing the value of incremental systems that can accommodate change.