Skip to main content
Allan Buntoengsuk

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

DoorDash

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 my time there:

  • Improvements to Match, where operators confirm item data against existing SKUs
  • Edit tool, an interface to edit SKUs (which did not exist yet)

DoorDash's ability to improve item quality at scale was capped by tooling. Bad SKU data meant that customers can't find items or accurately judge substitutions. In addition, Dashers may not be able to find items because they are mislabeled.

Match

Operators could reject a bad match, but they couldn’t say why

An operator could accept an incorrect SKU or reject it, and nothing more. Which meant 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 flag 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% and build time was reduced from 18 days to 3.

Match rejection UI showing attribute-level selection

Edit

Fixing a single SKU took three days

The process: 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 actually comprised of three different records

  • 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 should be primary, which is editable, and what an operator does when they conflict. Conflicts can 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. Then, select multiple SKUs into an edit queue. Save advances to the next item.

A live preview, mobile and desktop, updates as attributes change. With many fields in play, motion alone wouldn’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 may find themselves needing to replace the AI-generated name, so I wanted to make it easy.

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

I took care to indicate 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. But 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 divergent directions and 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 ended up arguing 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 and model-trained suggestions on missing attributes to ensure all SKUs are robust and healthy. The tool should go from being an editor to being an 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 didn’t 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 ended up impacting 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 were scoped as P2. Near-term work ships H1 2026.

Editing that used to take 1-3 days now takes only a few hours.