2024 to 2025

Designing self-service ML infrastructure

I brought JupyterLab and VS Code to HyperPod so teams could develop and train on the same GPU infrastructure without days of manual setup.

Role: Lead Product Designer and Design Engineer
Team: Solo designer with engineering and product
Duration: 8 months
Scope: Shipped admin experience and data scientist prototype

~99%Setup reduction: From 1 to 2 days down to 2 to 5 minutes
1:15Template reuse: Templates could span namespaces and teams
3+Enterprise customers: Adopted within 2 weeks of launch
13+Spaces created: Active early usage after launch

Design for two mental models

Problem: Customers maintained separate GPU infrastructure for interactive development and distributed training. Administrators needed governance, while data scientists needed fast access to compute.
My decision: I shipped a guided admin console and prototyped a hardware-first self-service path for data scientists instead of forcing both personas through one workflow.
Tradeoff: We launched CLI access for data scientists before the GUI was ready. That unblocked power users while I used working prototypes to validate the broader experience.
Shipped result: The admin flow cut setup from 1 to 2 days to 2 to 5 minutes, and the data scientist prototype became input to the 2025 roadmap.

Give each persona the right starting point

HyperPod development Space settings for compute, environment, and storage — The admin experience groups compute, environment, and storage settings in one reusable definition.

Make governance reusable

Administrators configured compute, environments, and storage once, then made those choices reusable through templates.

Prototype dialog for creating a HyperPod development Space — The prototype lets a data scientist choose team context and capacity before creating a Space.

Prototype self-service creation

The data scientist prototype turned namespace and capacity details into guided choices instead of raw Kubernetes configuration.

Show capacity before commitment

The hardware-first model surfaced available compute first. Cluster and namespace became supporting context, so people did not finish a long flow only to learn that the GPU they needed was unavailable.

HyperPod Spaces console showing templates and current development Spaces — Templates, status, sharing, compute, and storage stay visible in the same operational view.

Use code to move the work forward

Source repository used for the HyperPod Spaces design prototype — The working prototype lived in code so dynamic infrastructure behavior could be reviewed directly.

Prototype the real behavior

Static mockups could not keep up with changing capacity and cost. I moved to working prototypes that could express real state and became input to the API contract.

AWS Machine Learning Blog article announcing interactive IDEs on HyperPod — AWS published the Spaces on HyperPod launch and setup model in November 2024.

Ship the admin foundation

The first release brought interactive IDEs to HyperPod and documented the quick installation, namespace, and template model for customers.