Code Review

Role

Lead Product Designer

Timeline

Multi-phase (2024)

Themes

Developer Tools · AI Design · Information Architecture

Impact

Rebuilt trust for 80,000+ engineers who'd rejected the prior redesign.

An 18.3% lift in deployments per developer, publicly reported — a per-head gain multiplied across every one of them. The figure covers this and other projects I led design for. As a result, the team asked me to design a configurable AI auto-approval system handling millions of changes a month (2026).

Amazon's code review tool is the gate every code change clears before it merges. 80,000+ engineers use it daily, and how fast code moves through it feeds a number the whole company gets measured on. A security rebuild had shipped and cost the tool its users' trust. I led the redesign to win it back.

Code review velocity was the biggest driver of ASBX's cost-to-serve metric

Amazon Software Builder Experience (ASBX), the org behind Amazon's internal developer tools, measures itself in cost-to-serve-software, and its research names code review velocity as the biggest thing that moves it. Code review is where every change waits for a human yes before it ships. That's the tool I led the redesign of.

A security rebuild impacted usability and trust

The previous redesign moved the tool off AngularJS onto React, a security fix with no design behind it. Dropping the old layout into Cloudscape, Amazon's design system, cost engineers the density they lived in every day. More UI got bolted on to compensate, and the screen turned busy and hard to read. As one engineer put it:

“The dashboard is where you see every open CR in one glance. In the new one, I have to scroll.”

— Software engineer

2,500 survey responses said the rest: too much scrolling to see their work, a screen too busy to scan, too many CRs that weren't theirs, and slower loads on top of it.

The goal: simplify the dashboard so authors and reviewers could quickly spot the CRs that needed them, and cut the time it takes to get a CR approved.

I started by mapping who actually used it

The rebuild decided what to show using aggregate counts across all users: if enough people used something, it went on the screen. No individual needed all of it, so the result was bloated for everyone. I ran a workshop instead, mapping the real users — three primary roles (authors, assigned reviewers, volunteer reviewers) plus the people around them (on-call, managers, scrum masters) — and what each one actually needed to accomplish their goals. Those findings mapped directly onto the explorations and solutions that follow.

The workshop also mapped secondary jobs (On Call, Manager/Lead, Scrum Master) and user mental models. View full workshop artifact

Engineers thought in two buckets, so the dashboard did too

Engineers split their work into active work — “my changes” and “to review” — and passive monitoring. I built the dashboard the same way, structuring the information architecture to support the mental models they already had rather than teaching them new ones. A sub-section hierarchy then refined code reviews into buckets aligned with each workflow: for authors, changes that need your attention versus changes waiting on others.

Click to expand

For authors: five clear states, each wired to an action

Approval counts told authors nothing about what to do next. I replaced them with five plain states, each mapped to a next step, so an author opens the tool and knows what's theirs to do. A nudge system let authors follow up without leaving the tool. And AI-generated descriptions gave reviewers context at every revision, which kept authors' changes smaller and moved them through review faster.

Click to expand

For reviewers: making the cost of a review predictable

Reviewers dodged big CRs because they couldn't guess the time cost, so those changes sat. I gave every CR an AI-estimated effort level, so a reviewer with ten minutes could find a quick one and finish it, and CRs stopped stalling in the queue. IDE integration let them review diffs right in the editor, without switching tools.

Click to expand

The loudest complaint was noise, so I cut it

Bold everywhere, too much color, photos where an alias would do.

“The new dashboard has everything in bold, and the colors are too catchy.”

— Software engineer

I pulled the volume down: title-forward rows, text over color, status pills reserved for the few moments that needed a flag.

People wanted opposite layouts, so I let them build their own

Needs genuinely conflicted. Some wanted everything on one dense page to save clicks; others wanted My Changes and To Review split, because it matched how they worked: merge what's approved, then sit down to review. One fixed layout couldn't serve both. So I gave people the controls: saved views, custom columns, filtering and sorting on the fly, so each person could build the density and layout that fit their work.

Click to expand

General settings

Name views, combine team aliases, filter by attention state

Click to expand

Column visibility

Toggle and reorder columns to focus on what matters

Velocity climbed across teams, and they asked me back to design AI auto-approvals at scale

The redesign won back the engineers who'd rejected the prior attempt, and moved code through review faster across 2025.

• •Review velocity climbed across teams as the dashboard, AI descriptions, and IDE review shipped.
• •AI descriptions at creation kept changes smaller and got reviewers context faster, cutting the time from CR to production.
• •Design moved from cleaning up late to sitting in on planning.
• •The nudge system shipped after my engagement ended, built off the direction we set.

This redesign was one of several projects I ran with the code review team through 2024, alongside broader AI and IDE integration work, all of it part of the 18.3% lift in deployments per developer across Amazon's 80,000+ engineers.

Then they asked me back by name to design a configurable AI auto-approval system handling millions of changes a month.