Skip to main content
Allan Buntoengsuk

DoorDash

Two tools behind 400K SKUs a week. One I rebuilt, one I created from scratch.

Year
2026
Role
Senior Product Designer
Tags
Internal ToolsMarketplaceSystems DesignCross-functionalOperator tooling

I joined the New Verticals (grocery) Catalog team in July 2025 to rethink internal catalog tooling. Two tools came out of it:

  • Improvements to Match, where operators confirm item data against existing SKUs
  • Edit tool, which didn't exist yet.

Bad SKU data means customers can't find items or judge substitutions. Dashers hunt for things and can’t find them because they are mislabeled. And DoorDash's ability to improve item quality at scale was capped by tooling.

Match

Operators could reject a bad match, but not say why

An operator could accept an incorrect SKU or reject it, and nothing more. The same bad SKUs kept coming back.

With my PM and the vendor teams running the queue, I added attribute-level selection to rejections, so an operator can mark which fields cause mismatch. Same for multi-candidate rejections, where the reason differs per candidate.

Match now handles around 400K SKUs a week across 2,000+ vendors. Accuracy went from 77% to over 90%, build time from 18 days to 3.

Match rejection UI showing attribute-level selection

Edit

Fixing a single SKU was a three day round trip

Run a query, export a CSV, edit in a spreadsheet, bulk upload, wait.

Editing a SKU involves running a query, exporting a CSV, editing the data, and then re-uploading

The core problem

A SKU is comprised of three different records, not one

  • Raw Merchant Data - Raw uneditable data from the Merchant
  • UMP - DoorDash’s SKU item data
  • Linked UGP - Universal SKU Product data, this can be linked to a UMP
Three-source view on the current SKU viewer

Editing meant deciding which source wins, which is editable, and what an operator does when they conflict. Conflicts result in messy data and hinder standardization.

The editor makes all three visible in one view. An operator sees what the merchant sent, what the catalog resolves, and how these items link together—all without leaving the page.

Design

Near-term: Manager and Editor

Search by item name, business ID, or merchant-supplied ID. Select multiple SKUs into an edit queue. Save advances to the next.

A live preview, mobile and desktop, updates as attributes change. With many fields in play, motion alone doesn't tell an operator what moved, so selecting a field highlights its corresponding output in the preview.

Near-term SKU Manager
Near-term SKU Editor w/ live app preview
Field input with corresponding preview data highlighted

Decision

The AI writes the item name but the operator has to be able to override if necessary

Editing certain fields triggers LLM name regeneration. An operator who can't tell a generated name from a human one wouldn’t be auditing anything.

Four states: AI-generated, edit on hover, user-edited, user-edited on hover with revert. Provenance is visible in the field itself, and the override path is one action.

Care was taken to indicated when a name was edited by an operator and to allow reverting back to the original AI-generated name.

AI-generated item name override

Direction

The near-term tool fixes data. The team hadn't decided whether that was the vision

I fed the briefs, requirements, and Slack threads into structured prompts to generate Figma Make directions, then aligned the near-term ones with Prism, the DoorDash design system. AI was useful for divergence and for producing something the team could react to in days. I had to ensure that I was communicating that this was just a vision/initial idea as the fidelity often invited feedback that was too granular or focusing on the wrong thing.

My long-term concepts argue for a different product. If operators are always going to be behind the data, the tool should tell them where to look. That means change attribution to keep an auditable record of all changes, performance metrics in the editor to spot inefficiencies/incorrections, and model-trained suggestions on missing attributes to ensure all SKUs are robust and healthy. Going from editor to optimizer.

Long-term vision intelligent SKU edit
Long-term SKU Intelligence view

What I didn't solve

Upstream merchant data quality—we had recently started using AI systems to import and automatically build SKUs, aided by human in the loop via the Match tool. I did not focus on how to improve merchant data extraction or robustness, only post-import SKU quality and the connections to the product that a dasher/consumer may see.

Impact

The prototypes impacted what the team decided to build

Presenting the near-term Figma Make directions got buy-in for the near-term build, and pulled Preview mode and Edit History into it. SKU metrics scoped as P2. Near-term work ships H1 2026.

Editing that took 1-3 days now takes hours.