2022 · Systems and information design for image quality control · 4MIN READ
Streamlining a Multi-Team QC Workflow
Resolution loop, one issue at a time
01
Issue reported
Any team
Date, style number, colour, view, urgency and source go in one row. Urgent rows turn red automatically until they carry a status.
02
Issue picked up
Retouching / DAM
The team that owns the fix writes its note on the same row - never a new one - so one issue keeps one history.
03
Status set
Retouching / DAM
Pending or Complete, with an update date. Locked entries turn pink until the lock is released.
04
Partner check
External partner
The partner confirms the fix landed. Unconfirmed rows stay visible in the pending filter instead of quietly disappearing.
If the check fails, the row goes back to step 02 with its full history attached - the loop that used to restart as a brand new email thread.
Shared tracking sheet
| Date | Style | Colour | Urgency | Source | Issue | Team notes | Status | Partner check |
|---|---|---|---|---|---|---|---|---|
| 25-07 | 072...313 | 310 | Urgent | Studio | Label not visible | - | Pending | No |
| 08-08 | 072...325 | 690 | Urgent | Internal | Colour differs | Pushed again | Complete | Yes |
| 08-08 | 082...312 | 400 | Not urgent | Internal | Wrong colour | - | Pending | No |
Rules the sheet enforces on its own
- Urgent rows turn red on their own, and stay red until someone sets a status.
- Locked entries turn pink, and clear the moment the status becomes Complete.
- Nothing is ever deleted: an unresolved issue is updated on its original row, which is what killed the duplicates.
- The update date is mandatory on every status change, so pending age is readable at a glance.
One sheet, six views
Retouching
Writes
Team notes, status, update date
Sees
Its own tab, filtered to pending
DAM
Writes
Team notes, status, locked in PIM
Sees
Its own tab, plus everything locked
Copywriting
Writes
Issue, urgency, source
Sees
Copy-related issues only
Fitting
Writes
Issue, urgency, source
Sees
Fit-related issues only
Product
Writes
Issue, urgency, source
Sees
Its own reports and their status
External partner
Writes
Partner notes and partner check
Sees
Complete rows awaiting confirmation
Process summary
How the work was made
01
Surveying how the process was really used
I asked every party involved - Retouching, DAM, Copywriting, Fitting, Product and the external partner - how they were reporting issues today and where it broke down. The answers did not describe one process; they described six, each with its own channel and its own idea of what 'done' meant.
02
Designing one shared tracking system
One sheet with a fixed column model and three status stages: Pending, Complete, Partner check. Urgency and status colour themselves automatically, each team gets its own tab with input permissions and saved filters, and an unresolved issue is updated on its original row rather than reported again.
03
Writing the onboarding manual
The system was only worth as much as its adoption, and the users were not technical. I wrote a step-by-step manual - one instruction per screen, in the teams' working language - covering data entry, urgency, status, locking and filtering, so anyone could start using the sheet without being trained on it.
04
Opening a feedback loop
The manual ends with an explicit invitation: tell me what to change, including in the other teams' tabs. Treating it as a living tool rather than a one-off delivery is what kept it in use as each team's needs shifted.
Participants
Five internal teams - Retouching, DAM, Copywriting, Fitting and Product - plus an external retouching partner, surveyed first and onboarded afterwards.
Result
Adopted and used simultaneously by all six parties, ending duplicate issue tracking and giving each step of the resolution a named owner.
What I would test next
Measuring time-to-resolution per issue and checking whether the urgency flag actually shortens it, rather than assuming visibility is enough.
Outcome
- One shared tracking system replacing mail and chat reporting across six parties
- Duplicate reporting eliminated by the update-the-original-row rule and per-team filters
- Clear ownership of every stage: who reports, who fixes, who sets status, who confirms
- An onboarding manual that let non-technical teams adopt the system without training sessions
What I took from it
That a spreadsheet can be a product if you treat it like one. The survey mattered more than the build: once I understood what each team was already doing, the system only had to formalise it. And writing the manual taught me that a design is finished when someone who was not in the room can use it unaided.
Next case study
Personal Finances