Designing a two-role edit and review workflow for the B2B Digital Catalogue, because AI can't fix bad data at the source.
The B2B Digital Catalogue relied on AI enrichment to populate product attributes. But enrichment was only as good as the source data. Data coming in from client funnels was incomplete, inconsistent, and often wrong. The result: catalogue records full of bad data, and no way for anyone to fix it.
The model could only work with what it was given. Bad input meant bad output, consistently.
Data arrived from multiple client funnels, incomplete, inconsistent, missing key attributes.
Attributes on the PDP were read-only. No edit button. No escalation path. No self-serve correction.
We could've trained a better model. None of it would've worked. The problem wasn't the AI.
Retraining the model, adding data sources, tweaking thresholds, none of it addressed the root cause. No human could correct what the AI got wrong. The data entered the system incorrect and stayed incorrect. The solution required giving clients the ability to fix attributes directly, with governance to ensure quality and a review layer to prevent new errors.
Both roles are client-side, this is a self-serve workflow. The separation ensures no single user can submit and approve their own changes, maintaining data integrity without requiring internal oversight.
Client-side user who identifies incorrect attributes and submits corrections. Works inline on the PDP.
Reviews submitted edits with full context. Can approve all or reject with field-level comments explaining exactly what needs fixing.
Separation of roles. Shared accountability for cleaner data.
Before touching Figma, I mapped every backend constraint, every system boundary, and every edge case. The edit feature sat at the intersection of multiple products, each with their own data ownership rules.
Specifications, owned by MMA (separate product). Cannot be edited here.
Classification path, owned by Taxonomy (another product). Read-only in this flow.
Adding new attributes, introduces data governance issues. Not in Phase 1 scope.
Partial acceptance, backend limitation. Reviewer must accept all or reject all in Phase 1.
Phase 1 ships what's safe. Phase 2 expands what's possible.
The reviewer experience went through multiple iterations. Early designs allowed reviewers to accept or reject a submission as a whole with a single comment. After a client demo the feedback was clear: "How will the editor know what specifically to change?" Editors were re-submitting with the same issues because they couldn't tell which fields were wrong.
The best iterations come from real users, not internal reviews. Good rejections teach.
The edit flow begins on the Product Details Page, the same page where incorrect data lives. No navigation to a separate editing interface, no context switch. The edit button lives where the problem is visible.
Editing lives where the data lives.
Not all attributes can be edited here. Backend constraints, data ownership across products, and governance requirements all shape the scope. Clear boundaries reduce error surface, and tell users exactly where to go when something can't be fixed here.
Boundaries are a feature, not a limitation.
The reviewer reviews the result, not the typos.
The reviewer sees a queue of pending edit tickets, SKU ID, status, supplier, and timestamp. One click opens the full submission. Every pending edit is visible, nothing gets lost in email threads or support tickets.
The review screen shows current value vs new value side by side for every attribute, images, documents, and all editable fields. The reviewer works through each field individually, not the submission as a whole.
Checking 'Reject this edit' on any field reveals a comment box, the reviewer explains exactly what's wrong with that specific field. Multiple fields can be rejected with separate comments. The global Reject button only activates once at least one field is flagged, you can't accidentally reject without flagging something first.
All non-rejected fields go live immediately. Audit log captures the decision.
Submission sent back to editor with field-level comments. Editor knows exactly what to fix and where.
The reviewer doesn't reject submissions. They reject specific fields, and tell the editor exactly why.
The flow is deliberately linear, no branching, no parallel paths. If rejected, it loops back to step 1. The editor re-edits based on field-level feedback and resubmits. The loop ends when the data is right, not when patience runs out.
A multi-team escalation became a 2-role self-serve workflow.
* In development. Metrics updated post-launch.
Reviewer must accept all or send all back. Backend limitation, granular field-level acceptance is a Phase 2 problem.
Power users managing hundreds of products will need bulk correction tools. Single-product editing doesn't scale.
Adding new attribute types still requires Taxonomy team involvement. Not in Phase 1 scope.
Phase 1 ships. Phase 2 learns. That's how good products grow.
Designing within constraints isn't compromising, it's collaborating with reality.
The best designers don't ask for the perfect canvas. They ask: what's the smallest, sharpest version of this that solves a real problem today?
This won't win design awards. But it'll quietly improve thousands of catalogue records, and make the AI that depends on them actually useful.
That matters more.