Workload API

Overview

The Workload API is a platform that enables teams to deploy, monitor, and manage customer code at scale. Designed the core set of entities and console interface that generalize the experience across different workload types and deployment scenarios.

The problem

When deploying from source code, the system needs metadata to build a container image: a reference to the uploaded source code, and instructions for how to produce a Dockerfile. This requires capturing multiple, often conditional inputs that vary by build type, creating complexity and confusion in the API design.

Our solution was to group all build inputs into a single ImageBuildConfig object on the Container entity. The Dockerfile source is modeled as a discriminated union, so each variant carries exactly the fields it needs—eliminating optional parameters and conditional logic that lead to invalid states.

Research

Before committing to engineering implementation, we conducted user testing sessions to pressure-test the redesigned Workload API experience. Each 30–45 minute session involved participants interacting with an interactive prototype we created, allowing us to observe real-world usage patterns and uncover friction points in the API design.

The prototype was built using Claude Design, enabling us to rapidly iterate and test different interaction patterns without waiting for implementation cycles. This approach allowed us to validate assumptions early and make confident decisions about what would ship.

Our priority throughout was surfacing pain points while there was still time to act on them—testing confirmed that the simplified entity model and discriminated union approach resonated with users and significantly reduced cognitive load when working with the API.

Design

Once we had a clear understanding of the problems to be addressed, the PM team started creating 6-pagers and PR/FAQs that described the vision for the redesigned platform. We adopted the working backwards methodology pioneered by Amazon—writing the customer announcement and FAQ before designing the product.

This approach helped everyone on the team, including design, to assess and interrogate the platform's viability, guide development decisions, and maintain a relentless customer-centric focus. Rather than iterating on implementation details, we debated the core value proposition and customer experience first, ensuring alignment before engineering began.

The design process focused on creating a unified console experience that made complex workload orchestration feel intuitive—providing clear visibility into build status, configuration options, and workload management through a consistent, tab-based interface.

Outcome

The research and iterative design process validated our approach: by designing around clear, composable entities and discriminated unions, we achieved a dramatic reduction in API surface area and cognitive load. User feedback consistently highlighted that the simplified mental model was immediately intuitive—no longer wrestling with optional fields or conditional logic.

The redesigned workflow was reduced to two core actions: Configure & Build, and Deploy & Monitor. This simplification emerged directly from research findings showing where users struggled most. The new entity model, complemented by a unified console interface with clear status indicators and streamlined interactions, shipped as the foundation for Workload API v2.

The outcome demonstrated the value of designing with constraints (discriminated unions force explicit, valid states), involving users early (testing the prototype before implementation), and maintaining a relentless focus on cognitive simplicity over feature completeness.

← Back to all work