UX Case Study · Field Sales SaaS · Image Intelligence
On-Device Image Quality
Detection at Capture
Designed a real-time feedback system that flags poor-quality cooler images the moment a sales rep takes them — eliminating the costly back-office rejection loop and reducing fraudulent image submissions by surfacing errors before the rep ever leaves the store.
01 — Context
The Business Behind the Camera
Our SaaS product enables consumer goods companies to verify that retailers are maintaining cooler and shelf layouts per the agreed planogram — the contractual arrangement of products mandated by brands. Sales reps visit hundreds of outlets each week, capturing image sequences of coolers and shelves as evidence of compliance. These images feed into backend quality review workflows, Machine Learning models, and client-facing compliance dashboards.
The integrity of the entire compliance program rested on image quality. A blurry shot, a closed cooler door, or a photo taken from a bad angle produced useless data — and in some cases, actively misleading compliance scores. When a rep submitted a "Picture of Picture" (photographing a previous visit's printout instead of the actual shelf), it was an act of fraud that cost brands real money.
⚠️ Scale context: The field force averaged 600+ reps across active markets, each visiting 12–18 outlets per day. At that scale, a 15% bad-image rate translated to thousands of rejections per week — each requiring human review, re-visit scheduling, and client communication overhead.
02 — Problem Definition
A Broken Quality Loop
When the back-office QC team or the backend ML pipeline rejected an image, the sequence was already hours — sometimes days — old. The rep had left the store, moved on to other outlets, and often had no memory of what the cooler looked like. The rejection meant one of three things: the visit was marked invalid, the rep was asked to return, or the data gap was silently absorbed as missing compliance evidence. None of those outcomes were good.
Delayed rejection loop. Backend QC caught quality issues hours or days after capture. Reps had already left the outlet, making retakes logistically impossible without a costly second visit.
Manual review overhead. A dedicated QC team spent significant hours daily triaging rejected images — tagging error types, routing for re-visit, and updating client reports. This was entirely reactive and unscalable.
Fraudulent submissions eroding trust. "Picture of Picture" and other intentional quality violations were indistinguishable from accidental errors at the point of capture. Clients were paying for compliance data they couldn't trust.
Lost compliance revenue. When valid data couldn't be produced for an outlet visit, brands lost the ability to claim planogram compliance bonuses — a contractually significant sum per outlet per audit cycle.
Rep confusion about standards. Reps had no real-time feedback on what "good" looked like. Many errors (wrong angle, incomplete scene, missing overlap) were honest mistakes that could have been corrected on-the-spot with timely guidance.
Client-visible quality gaps. Compliance dashboards showed data holes attributable to image quality failures — a direct signal to enterprise clients that the data collection process was unreliable.
🔴 The core insight: The rejection happened at the wrong end of the process. Moving quality enforcement from back-office review to the point of capture — in the rep's hands, while they were still standing in front of the cooler — was the only way to make retakes possible without added cost.
03 — Research Evidence
What the Data Was Built From
Design decisions in this project were grounded in three evidence sources: structured analysis of the back-office rejection dataset, direct observation of field rep workflows, and review of back-office QC tooling. The table below documents the research corpus that informed the problem framing and solution direction.
| Evidence Source | Volume | What It Revealed |
|---|---|---|
| Field rep interviews | 14 reps across 3 regional markets | Reps had no awareness of rejection criteria; feedback reached them days later via supervisor, not system |
| Screen recordings reviewed | 31 sessions from 8 reps | Average capture-to-submission time was 9 seconds; reps did not review images before submitting |
| QC rejection records analysed | 6 months of back-office data (~18,400 rejections) | 38% of all rejections were Operator Errors correctable at capture; PoP fraud represented 8% of rejections but 100% of compliance disputes |
| QC tool workflow observations | 4 QC analyst sessions observed | Reviewers spent ~45s per image on triage; the "Is Usable?" binary at end of form was the only structured output |
| Stakeholder workshops | 3 sessions — Product, QC Lead, Client Success | Error taxonomy alignment: 25 named error types confirmed across all stakeholders as the shared vocabulary |
Key Findings That Drove Design Direction
04 — Problem Framing
Not All Errors Are Equal
A critical design decision early in the project: the system needed to treat different error types differently. Grouping all 25+ flaggable quality issues into a single "bad image" bucket would have been technically simpler, but behaviorally wrong. Through stakeholder workshops and analysis of six months of rejection data, three distinct error categories emerged.
Bad angle, not enough overlap, closed door, wrong scene type, image blur, incomplete scene. These are honest mistakes a rep can fix immediately by retaking the photo. The system should encourage a retake, not penalise.
Picture of Picture (PoP). This is a rep photographing a prior visit's printout as if it were a live shelf. It cannot be an accident. Detecting this at capture closes the exploit before submission and creates an audit trail.
Too dark, too bright, duplicate images, empty coolers/shelves, body part in frame, junk image. Some of these are legitimate conditions the rep can't control. The system should surface them for awareness without hard-blocking submission.
Error Source Breakdown — Based on 6 Months of Rejection Data
05 — Architecture & Design
Shifting Quality Left — From Backend to Capture
The system was architected as a layered quality gate running immediately after the Android camera shutter. The ML inference pipeline evaluated the captured frame against 25+ quality dimensions before the preview was shown to the rep. This introduced a sub-2-second feedback window — fast enough to feel instantaneous, meaningful enough to allow a retake before the rep moved their device.
Quality Gate — Execution Flow (After Shutter)
Camera shutter fires
Quality inference < 1.8s
Error types grouped
If any flags fired
Retake or Ignore Error
Decision recorded server-side
The QC Tooling Before — Desktop Back-Office
Prior to this system, quality tagging happened entirely in a desktop back-office tool. A reviewer manually checked checkboxes across 25+ error types — once per image, hours after capture. The "Is Usable?" dropdown at the bottom was the only field that fed downstream systems.
The back-office QC tool used by reviewers before the on-device system. A reviewer manually checks error types across 25+ quality dimensions — hours after the rep has left the outlet. "Is Usable?" is the only field that feeds downstream systems.
The On-Device Error Sheet — After
The mobile error sheet fires immediately after capture. All detected flags are surfaced in a single scrollable list, with the captured image visible behind the sheet for context. The rep makes a deliberate choice — Retake Image or Ignore Error — before proceeding.
On-device error sheet shown immediately after capture. All 8 detected flags are listed simultaneously. The captured image is visible behind the sheet. Rep chooses to retake or ignore — decision is logged either way.
💡 Design implication from the QC tool analysis: The back-office taxonomy was comprehensive and well-categorised — 25 named error types across visual quality, scene composition, and content validity dimensions. This existing taxonomy became the direct source of truth for which flags the on-device system needed to detect and surface. We didn't invent a new language; we moved an existing expert vocabulary to the point of capture.
06 — Design Decisions
What the Feedback System Had to Get Right
The mobile error sheet (shown in the second screenshot) is the product of several deliberate design decisions. Each one was anchored to a specific failure mode observed in field testing and stakeholder reviews.
An early prototype surfaced errors one at a time — "fix this, then see the next issue." The intent was to reduce overwhelm. In field testing, reps hated it. They retook the image after fixing one issue, only to be told there was another. It felt like a hidden-ball trick, and several reps abandoned the retake flow entirely after two rounds.
Decision: All detected errors are surfaced simultaneously in a single scrollable sheet, displayed as a list of warning items with consistent triangular caution icons. Reps can see the full picture at once — eight flags is a lot, but it's honest. The sheet header ("The image you captured has the following errors:") frames it neutrally, not as an accusation.
This also gave back-office context: when a rep chose "Ignore Error" on a multi-flag image, the full list was logged. Reviewers could see what was knowingly bypassed, enabling smarter audit targeting.
A hard block — preventing submission when errors were detected — was considered and rejected for several reasons. Some error flags represent genuine field conditions the rep cannot control: a legitimately empty cooler triggers "Empty Coolers/Shelves," and a mandatory retake would penalise the rep for accurate documentation. Absolute blocks also breed workarounds.
Decision: Both options are presented with equal visual weight — both rendered in the same red/coral colour with no visual hierarchy between them. This was intentional. We wanted the rep to read both options before acting, not default-tap the rightmost button. The choice requires conscious selection, and the decision is recorded either way.
For the specific case of "Picture of Picture" — a fraud signal — the system flags it identically to other errors in the UI, but the server-side logic routes it to a dedicated fraud audit queue regardless of which button the rep taps. The UI stays neutral; the backend consequence is not.
An early version used a full-screen modal with a neutral grey background. Reps in testing frequently asked "which image is this for?" — especially during sequences where multiple images were captured before the error sheet appeared. Without seeing the image, the error list felt abstract.
Decision: The error sheet is displayed as a partial-screen bottom sheet overlaying the captured image. The rep can see what image triggered the flags — "Captured from Bad Angle" is immediately interpretable when you can see the photo it refers to. The overlay preserves spatial context without requiring the rep to navigate away to check.
A server-side detection approach would have allowed heavier models and easier updates, but introduced a critical dependency: network connectivity. Field reps often operate in basement retail environments, refrigeration sections with poor signal, and rural markets with unreliable data. A detection system that silently failed when offline would have been worse than no system at all.
Decision: Core quality detectors — angle, blur, overlap, scene completeness, brightness — run on-device using a quantised lightweight model deployable via the standard app update mechanism. Server-side models handle the heavier classification tasks (scene type validation, PoP detection) asynchronously on upload, with results feeding the back-office audit queue rather than blocking the rep. The on-device gate addresses the correctables; the server gate addresses the fraud signals.
When a rep tapped "Ignore Error" and the image went through to back-office review, the reviewer saw the same error flag names the rep had been shown. This was a deliberate consistency choice. In early builds, we used simplified rep-facing labels ("Photo is Blurry") and technical QC labels ("Image Blur") — and the disconnect caused confusion in escalation conversations.
Decision: The mobile error labels match the QC tool taxonomy exactly: "Captured from Bad Angle," "Not Enough Overlap," "Multiple Disconnected POS in one Scene." Reps learning the terms on mobile become fluent in the same vocabulary the backend team uses — reducing friction in supervisor coaching, rep feedback, and client audit discussions. Terminology alignment was a system design choice, not just a content choice.
07 — Before vs. After
What Changed for Each Stakeholder
Behaviour Change — Sales Rep in the Field
08 — Validation
Measured Outcomes — 90-Day Post-Launch
Metrics were tracked across the full field force over a 90-day post-launch window. Baseline was established from the 90-day period immediately preceding launch, using the same outlet and rep cohort.
| Metric | Ease | Before | After | Change |
|---|---|---|---|---|
| Backend image rejection rate | Improved | ~15.2% of images | ~6.1% of images | −60% rejection rate ↓ |
| Re-visit scheduling events (quality-related) | Improved | ~320 / week | ~68 / week | −79% re-visits ↓ |
| Picture of Picture submissions | Improved | ~47 / week (baseline) | ~9 / week | −81% fraud submissions ↓ |
| QC team daily triage volume | Improved | ~1,100 images / day | ~310 images / day | −72% manual review load ↓ |
| Rep retake rate when error sheet shown | High | N/A (feature did not exist) | 64% of flagged images retaken | 64% correction rate |
| Outlet compliance data completeness | Improved | 82.4% outlets with valid images | 93.7% outlets with valid images | +11.3 pp completeness ↑ |
The 64% retake rate was the most important validation signal. It confirmed that when reps were given specific, timely, actionable information, the majority chose to fix the issue — not bypass it. The remaining 36% who chose "Ignore Error" did so on images where the error flags were frequently legitimate edge cases (empty shelves, lighting constraints), validated by QC reviewers who saw the same flags and agreed the images were usable.
Before vs. After — Key Metrics at 90 Days
Post-Launch KPI Monitoring — 90-Day Window
Before, I never knew there was a problem until my supervisor told me a week later. Now I fix it right there. It's actually faster.
— Field Sales Rep, post-launch rep survey
The QC queue used to be unmanageable. Now it's almost entirely legitimate edge cases — images that genuinely needed a human call. The noise is gone.
— QC Operations Lead, post-launch debrief
09 — Outcomes
Business Impact & ROI
The system produced measurable value across four business dimensions: elimination of re-visit costs, QC labour reduction, fraud loss prevention, and compliance revenue recovery. Calculations use 600-rep field force at regional market scale, with 250 working days per year.
Calculation 1 — Re-Visit Cost Elimination
Calculation 2 — QC Labour Reduction
Calculation 3 — Fraud Loss Prevention
Calculation 4 — Compliance Revenue Recovery
drop in image rejection rate — from 15.2% to 6.1% of all submitted images, measured over 90 days post-launch
reduction in Picture of Picture fraud submissions — from ~47 events/week to ~9 within the first 90-day window
of reps retook their image when shown the error sheet — confirming the feedback was actionable and specific enough to drive correction
improvement in outlet compliance data completeness — from 82.4% to 93.7% of outlets producing valid evidence per audit cycle
10 — Reflection
What This Project Taught Me About System Thinking
The surface deliverable was a mobile error sheet — a bottom sheet with a list of warning icons. But the actual work was a system redesign: moving a quality enforcement boundary from one end of a multi-party workflow to another, and designing all the touchpoints of that shift coherently.
The back-office QC tool, the mobile error UX, the ML model's classification taxonomy, the server-side audit logging schema, the rep training materials — all of these had to speak the same language and operate as a single coherent system. The moment any layer used different terminology or different categorisation logic, the audit trail broke and the data became incomparable.
The most impactful design decision in the whole project was not a UI component. It was the decision to use the existing QC taxonomy as the shared ontology across all layers. That single alignment choice made the system debuggable, trainable, and auditable in ways that no amount of interface polish could have compensated for.
We went from chasing quality problems to having a real-time feedback loop. The rep is now part of the QC system, not downstream of it.
— Product Lead, post-launch review
Clients stopped asking about data gaps. When they do see a gap now, it has an audit trail — which is something we've never been able to offer before.
— Client Success Manager, enterprise account debrief