Microsoft Foundry
Models

The Problem

11,000 models,
and nowhere to start.

Developers hit 11,000 models with no way to narrow the list, and no signal of what would even run in their region.

Picture a developer who just wants to ship a feature this week. They open Microsoft Foundry, land on the Models page, and hit more than 11,000 models, each with different capabilities, pricing, context windows, and regional availability. Users kept telling us the same two things: help me narrow this list, and help me figure out where to start. Some picked a model only to hit a wall at deployment because it wasn't available in their region.

Our team of five spent three months redesigning model discovery end to end. I came to the project from the research side, after running a UX research study on Foundry.

Before After

Toggle between the old catalog and the shipped redesign. Before: a dense multi-column grid where every model shows little more than a name and a task, with no way to narrow by region, so a developer could commit to a model and only hit a wall at deployment. After: Region is promoted into the filter rail as a first-class way to narrow the catalog, in a cleaner, more scannable layout, with Compare a click away.

User Research

Developer interviews shaped
our direction.

Every method pointed to the same gaps: unclear terms, dense structure, and no way to compare.

We ran our own study: a heuristic evaluation of the live platform, moderated developer interviews, and a card sort.

Who we designed for

Research pointed to three personas: Maya, a student developer, and Priya, a product manager weighing cost against capability. After aligning with Microsoft, we designed primarily for Alex, a startup developer who needs to move fast without picking a model that causes problems later.

Sketches & Wireframes

Sketching our way
out of the problem.

Two decisions drove the redesign: where the region problem gets solved, and what a developer sees first.

Before touching Figma, we sketched. Paper let us argue about structure instead of pixels, which is where those two decisions got settled.

Three ideas carried from paper into the mid-fidelity wireframes:

Designing for the states that aren't the happy path

A catalog of 11,000 models is mostly edge cases. Three shaped the design as much as the main flow, each a decision with a real trade-off.

Three directions we killed

With a fixed IA and a tight scope, the hard part was deciding where not to spend the effort. The shipped answer looks obvious in hindsight; it wasn't. I explored three approaches that tested worse, and killing them is what made the final design defensible.

Mid-fidelity wireframes

With the structure settled, I moved into Figma to resolve layout and hierarchy. These mid-fidelity screens worked out where each decision lives; the high-fidelity, clickable prototype comes next.

High-Fidelity Prototype

The clickable, high-fidelity build.

Before it shipped, the redesign lived here: a full high-fidelity prototype, embedded and clickable. Explore Discover, the Models page, filtering, and side-by-side compare, then see the shipped solution next.

User Testing · Round 2

Validating the high-fidelity
prototype.

Round two tested one thing on the real prototype: could developers understand, navigate, and compare?

An earlier round on the wireframes had already shaped the layout; this final round put the high-fidelity prototype in front of developers across the Home, Discover, and Models pages, testing three things: whether they could understand the interface, navigate to the right region, model, or task, and compare options to find the best fit.

Three refinements came out of it: region and pricing moved to the top of each model card so they register before anyone opens a model, the compare tray became persistent with a running count, and the best value in each comparison row got called out so trade-offs read at a glance. Directional signals from a small, moderated round, enough to steer the design, not to claim statistical significance.