Case Study · B2B · Workflow · Enterprise UX
Bulk Operations at Enterprise Scale
Users were spending up to an hour opening deliverables one by one to change a single date. I redesigned it into a three step flow with a review before any data is written.
Problem: Users spent 50 to 60 minutes editing deliverables one by one to change a shared field, and often left briefs half updated.
My role: Senior Product Designer and design owner, from discovery to handoff, working with PMs, Customer Success and 13 engineers.
Decision: After five rounds of exploration, a three step wizard: one field per run, with a review of every change before anything is written.
Outcome: 108 individual edits became one wizard run of under five minutes, and Customer Success reported a drop in bulk editing complaints.
108 → 1
Manual edits for one project wide date change → one wizard run
The request was speed. The real problem was data integrity.
Customer Success brought me two escalations from different clients. One was a brief template with 89 deliverables. The other, from Electrolux, was a project wide date shift that took 108 individual edits. Both arrived framed the same way: make this faster. Underneath, they pointed to one root cause: there was no way to edit a shared field across multiple deliverables at once.
Same root cause, two manifestations
Complaint 1 · Template scale
deliverables in a single brief template. To change one shared field, the user had to open and edit each deliverable individually.
Complaint 2 · Project scale (Electrolux)
individual edits to shift delivery dates across one project: 6 active briefs, about 18 deliverables each.
Unpacking complaint 2: how 108 edits add up
Going beyond the escalations
Two escalations could have been two loud clients. Before designing anything, I wanted to know if this was a pattern. I didn't have direct access to end users, so I triangulated three sources: the CS escalations, the project managers who work with these clients daily, and around 30 Microsoft Clarity session recordings of users working in the deliverable list.
What 30 sessions showed
50 to 60 min
for most bulk changes
One tab per deliverable
users opened every deliverable in a separate browser tab and edited them one by one
Abandoned midway
leaving briefs where some deliverables had the new value and others the old one
Speed was the complaint. Inconsistent data was the real risk. Editing one tab at a time was slow, but it was also error prone: one missed tab meant a deliverable with the wrong date going into production. That reframe shaped every decision that followed.
How the direction evolved.
The wizard wasn't the first idea. It came out of five rounds, each one ruling something out.
Benchmark: I looked at how Picturepark, Bynder and Jira handle batch editing of metadata, and documented the real Electrolux edit form with its long lists and conditional fields. The pattern was clear: select many, choose what to change, confirm.
One form per deliverable: The first option kept the existing form and stacked one per deliverable inside a single modal: Deliverable 1 of 9, 2 of 9, and so on. It was familiar, but users still edited every deliverable by hand. It moved the manual work into one place instead of removing it.
Checklist modal, three iterations: Next, a checklist modal: tick the fields to change, set the value, update every selected deliverable at once. I took it through three iterations, adding fields that expand on select, a warning for fields that only exist in some deliverables, and success, partial and failure messages. I tested it internally with Customer Success, project managers and stakeholders. That's where it broke, as explained below.
First wizard: many fields at once: The first wizard split the job into steps: select deliverables, choose fields, set values. It still let users pick several fields per run, which made the values step long and hard to review when fields came from repeaters and conditional sections.
Final wizard: one field per run: I narrowed it to one field per run. It was a deliberate trade off: ship a smaller, safer version sooner, get real feedback, then expand to several fields. For setting values I tried checkboxes per deliverable, then a global toggle with overrides. I replaced the toggle with an Apply to all button because a clear label is easier to read than a toggle, which users associate with turning something on or off.
The checklist modal: tested, iterated, and my call to drop it.
I tested the checklist modal internally with Customer Success, project managers and stakeholders. It looked fine in a demo, but testing exposed problems that would hurt real users at scale. I made the call to drop it before any engineering time was spent, and moved the team to a wizard.
Why a wizard, and what it costs.
I compared the three directions against one risk: writing wrong data across 100+ deliverables.
Approach
Strength
Why it lost, or the cost I accepted
One form per deliverable
Reuses the existing form. Nothing new to learn.
Still one deliverable at a time. At 100+ deliverables it moves the manual work into one modal instead of removing it.
Checklist modal
Familiar. All fields and one confirm action. Fastest to ship.
Tested internally. A wrong selection forced users to start over, and nothing could be reviewed before writing.
Multi step wizard
One field per run, individual overrides, and a mandatory review before anything is written.
Slower for experienced users repeating the same change, and only one field per run, a scope I chose to ship sooner and expand after feedback. I accepted that cost because the alternative was silent errors in client production data. More on this in the reflection.
The review step is the heart of the feature. When metadata drives production and delivery for clients like Electrolux or LEGO, undoing a mistake is expensive, so users see every change before it happens.
What changed, and what I couldn't measure.
Time
The Electrolux date change went from 108 individual edits, and the 50 to 60 minutes we saw in Clarity, to a single wizard run of under five minutes.
Data integrity
The review step removes the pattern from the sessions: users abandoning midway and leaving briefs half updated. Every change is now confirmed before it is written.
Customer Success
CS reported a clear drop in bulk editing complaints after launch, and the Electrolux case became a success story in internal demos.
Scalable foundation
The CMF aware architecture, with dynamic field rendering and editable or uneditable grouping, extends to future field types without a redesign.
Honest caveat: the wizard wasn't instrumented, so I don't have post launch usage data. That gap is the first thing I'd fix.