Vision AI
Every Second Counts: Using AI to Make Workplaces Safer
Eight days of field research told us nobody wanted a 99%-accurate inspector.
Year :
2025
Industry :
Industrial AI Vision
Client :
In-house product
Project Duration :
1 year
The Premise
The premise was straightforward. Manual inspection on a factory line is inconsistent, so build a computer vision system accurate enough to replace the judgment call. Push detection accuracy as high as it will go and the quality problem takes care of itself.
We spent eight days in three manufacturing plants testing that premise. It didn’t survive.
Quality engineers told us they would rather work with a system that was 90–95% accurate and told them how sure it was, than one that was 99% accurate and told them nothing. Not as a compromise — as a preference.
That finding redirected the product. We stopped designing an inspector and started designing a second opinion.
Context
Vision AI is a production-grade visual inspection platform for manufacturing — surface defect detection, assembly verification, dimensional inspection, and packaging quality control, running on industrial cameras and edge compute alongside existing MES and PLC systems.
I led design end to end, from discovery through implementation. Three of the five designers on my team worked on this product; I set direction across all of them and across our other projects. On the build side, AI/ML engineers, full-stack developers and a product manager, with plant-side stakeholders — quality managers, production managers, IT/OT, operators — involved throughout.
Discovery
Eight days across three shifts in manufacturing plants. Day shift, night shift, and weekend, because we suspected — correctly — that the system would be used very differently when quality engineering support wasn’t in the building.
Contextual inquiry on the line, shadowing operators through inspection cycles and watching what they actually did with borderline calls.
Stakeholder interviews across nine roles, from line operators to the executive sponsor, mapped to a RACI so we knew whose constraints were binding and whose were preferences.
Environmental audit — lighting, vibration, dust, mounting positions, network headroom.
Workflow analysis of the detection → decision → action chain, tracing where time and confidence leaked out of each phase.
What We Found
The bottleneck wasn’t detection. It was adjudication.
Borderline cases accounted for roughly a third of inspection decisions, and that’s where the system was failing — not on the defects that were obviously defects. The same defect type was classified differently by different inspectors a significant share of the time, and classification varied noticeably between shifts on borderline calls specifically. Operators told us they were uncertain on those calls, and the uncertainty had a predictable resolution: reject when in doubt.
That behaviour is expensive in a direction most quality systems don’t optimise for. Unnecessary rework was costing several times more than the customer complaints it was meant to prevent. The plant wasn’t losing money on missed defects. It was losing money on good product being thrown away by people who weren’t sure.
Fatigue was structural, not incidental. Missed defects rose measurably in the final hours of a shift. Night and weekend shifts ran with minimal quality engineering support, so the operators with the least backup were making the hardest calls at the worst hours.
The physical environment set hard limits. Illumination differed substantially between day and night shifts. Conveyor vibration displaced cameras by millimetres. Dust required daily cleaning to keep optics clear. Only two or three viable camera positions existed per station. Network bandwidth was already at around 60% of capacity during peak production — which quietly ruled out streaming high-resolution imagery to the cloud and made edge processing a requirement rather than a preference.
And documentation was eating the experts. Quality engineers were spending hours per shift on manual data entry, while the defect knowledge that mattered most lived in senior engineers’ heads and nowhere else.
The Assumptions the Research Killed
This is the part worth reading. We wrote our assumptions down before going in and marked each one against what we found.
“Operators will resist AI because of job security.” Wrong. The large majority welcomed AI assistance for decision support and rejected full automation. The resistance wasn’t to the technology, it was to being removed from the loop. Design implication: human–AI collaboration, not replacement.
“Quality engineers want automated classification.” Wrong. They wanted confidence scoring with final human validation. Design implication: build the validation workflow, not the autonomous decision.
“99% accuracy is necessary for adoption.” Wrong, and this was the one that changed the product. 90–95% with clear confidence indicators beat black-box 99%. Design implication: explainability outranks raw accuracy.
“Real-time processing is mandatory.” Overstated. Near-real-time, within a handful of seconds, was acceptable for most inspection workflows — which loosened the hardware requirements considerably.
“Operators need mobile access.” Wrong. Stationary workstations were preferred for safety and network-security reasons. We stopped designing mobile-first.
“All defect types automate equally.” Wrong. Surface defects were automation-ready; dimensional and assembly defects needed human–AI collaboration. Design implication: phase by defect complexity, not by line.
Six assumptions, four reversed outright. If we had built to the original brief we would have shipped an accurate black box to people who had already told us they wouldn’t trust one.
What We Designed Instead
An inspection decision assistant, not an inspector.
The core screen shows the AI’s read as a three-state signal — pass, review, reject — with the confidence figure attached rather than buried. Confidence is the point of the interface, not a diagnostic detail, because the research said the operator’s real problem is knowing when to trust the machine.
Alongside it, the reference panel: acceptable and defective examples side by side. This exists because borderline calls were the failure mode, and the fix for a borderline call isn’t a better number — it’s a comparison the operator can make in three seconds.
Every decision is one click to accept or override, logged against the operator’s ID. The override is deliberately as cheap as the acceptance. A system that makes disagreeing with it expensive gets agreement, not accuracy.
Documentation happens in the background from what the operator already did, which is where the quality engineers’ lost hours come back.
Deliberate omissions. We did not build automated rejection without human confirmation, even where the model was strong enough. We did not build mobile. We did not chase the accuracy ceiling on dimensional defects. Each one came directly from a finding above.
Prioritisation
Eight candidate use cases, scored on value, feasibility and data-readiness, then cut to a phase-one MVP of two: AI-assisted inspection decision support, and automated defect documentation. Both scored at the top on all three axes.
Predictive quality management scored highest of anything on value and was deferred to phase three, because data-readiness was the constraint and no amount of design solves for training data that doesn’t exist yet.
Where It Stands, and What I’d Do Differently
Where It Stands, Honestly
The platform went into phased deployment against the plan above. Targets were set against a composite north-star metric combining first-pass yield, equipment effectiveness and total quality cost — with a defined guardrail that throughput must not degrade, because the fastest way to lose a plant manager is to make the line slower.
What I can’t claim yet is outcomes. Phase-one deployment was in progress, and we did not have clean pre-deployment instrumentation on several of the measures we most wanted to move. The honest position is that the discovery work is validated and the impact work isn’t finished.
If I ran this again I would instrument the baseline during discovery rather than after — while I was already on the line for eight days with access to every system I’d later need a number from. That’s the single biggest thing I’d change, and it’s a sequencing mistake, not a measurement one.
What I’d Do Differently
The feedback loop should have been in the MVP. We built a system that asks operators to calibrate their trust in a model and gave them no structured way to tell the model when it was wrong. Operator override data is the highest-value training signal in the entire product and we were logging it without closing the loop. It sat in phase three. It belonged in phase one.
I’d revisit confidence as a percentage. A number is precise and close to meaningless to someone who hasn’t been trained on what the model’s 92% is calibrated against. There’s a version of this interface where uncertainty is carried entirely by language and visual weight, and after watching operators read these screens under time pressure, I suspect it’s the better one.
More Projects
Vision AI
Every Second Counts: Using AI to Make Workplaces Safer
Eight days of field research told us nobody wanted a 99%-accurate inspector.
Year :
2025
Industry :
Industrial AI Vision
Client :
In-house product
Project Duration :
1 year
The Premise
The premise was straightforward. Manual inspection on a factory line is inconsistent, so build a computer vision system accurate enough to replace the judgment call. Push detection accuracy as high as it will go and the quality problem takes care of itself.
We spent eight days in three manufacturing plants testing that premise. It didn’t survive.
Quality engineers told us they would rather work with a system that was 90–95% accurate and told them how sure it was, than one that was 99% accurate and told them nothing. Not as a compromise — as a preference.
That finding redirected the product. We stopped designing an inspector and started designing a second opinion.
Context
Vision AI is a production-grade visual inspection platform for manufacturing — surface defect detection, assembly verification, dimensional inspection, and packaging quality control, running on industrial cameras and edge compute alongside existing MES and PLC systems.
I led design end to end, from discovery through implementation. Three of the five designers on my team worked on this product; I set direction across all of them and across our other projects. On the build side, AI/ML engineers, full-stack developers and a product manager, with plant-side stakeholders — quality managers, production managers, IT/OT, operators — involved throughout.
Discovery
Eight days across three shifts in manufacturing plants. Day shift, night shift, and weekend, because we suspected — correctly — that the system would be used very differently when quality engineering support wasn’t in the building.
Contextual inquiry on the line, shadowing operators through inspection cycles and watching what they actually did with borderline calls.
Stakeholder interviews across nine roles, from line operators to the executive sponsor, mapped to a RACI so we knew whose constraints were binding and whose were preferences.
Environmental audit — lighting, vibration, dust, mounting positions, network headroom.
Workflow analysis of the detection → decision → action chain, tracing where time and confidence leaked out of each phase.
What We Found
The bottleneck wasn’t detection. It was adjudication.
Borderline cases accounted for roughly a third of inspection decisions, and that’s where the system was failing — not on the defects that were obviously defects. The same defect type was classified differently by different inspectors a significant share of the time, and classification varied noticeably between shifts on borderline calls specifically. Operators told us they were uncertain on those calls, and the uncertainty had a predictable resolution: reject when in doubt.
That behaviour is expensive in a direction most quality systems don’t optimise for. Unnecessary rework was costing several times more than the customer complaints it was meant to prevent. The plant wasn’t losing money on missed defects. It was losing money on good product being thrown away by people who weren’t sure.
Fatigue was structural, not incidental. Missed defects rose measurably in the final hours of a shift. Night and weekend shifts ran with minimal quality engineering support, so the operators with the least backup were making the hardest calls at the worst hours.
The physical environment set hard limits. Illumination differed substantially between day and night shifts. Conveyor vibration displaced cameras by millimetres. Dust required daily cleaning to keep optics clear. Only two or three viable camera positions existed per station. Network bandwidth was already at around 60% of capacity during peak production — which quietly ruled out streaming high-resolution imagery to the cloud and made edge processing a requirement rather than a preference.
And documentation was eating the experts. Quality engineers were spending hours per shift on manual data entry, while the defect knowledge that mattered most lived in senior engineers’ heads and nowhere else.
The Assumptions the Research Killed
This is the part worth reading. We wrote our assumptions down before going in and marked each one against what we found.
“Operators will resist AI because of job security.” Wrong. The large majority welcomed AI assistance for decision support and rejected full automation. The resistance wasn’t to the technology, it was to being removed from the loop. Design implication: human–AI collaboration, not replacement.
“Quality engineers want automated classification.” Wrong. They wanted confidence scoring with final human validation. Design implication: build the validation workflow, not the autonomous decision.
“99% accuracy is necessary for adoption.” Wrong, and this was the one that changed the product. 90–95% with clear confidence indicators beat black-box 99%. Design implication: explainability outranks raw accuracy.
“Real-time processing is mandatory.” Overstated. Near-real-time, within a handful of seconds, was acceptable for most inspection workflows — which loosened the hardware requirements considerably.
“Operators need mobile access.” Wrong. Stationary workstations were preferred for safety and network-security reasons. We stopped designing mobile-first.
“All defect types automate equally.” Wrong. Surface defects were automation-ready; dimensional and assembly defects needed human–AI collaboration. Design implication: phase by defect complexity, not by line.
Six assumptions, four reversed outright. If we had built to the original brief we would have shipped an accurate black box to people who had already told us they wouldn’t trust one.
What We Designed Instead
An inspection decision assistant, not an inspector.
The core screen shows the AI’s read as a three-state signal — pass, review, reject — with the confidence figure attached rather than buried. Confidence is the point of the interface, not a diagnostic detail, because the research said the operator’s real problem is knowing when to trust the machine.
Alongside it, the reference panel: acceptable and defective examples side by side. This exists because borderline calls were the failure mode, and the fix for a borderline call isn’t a better number — it’s a comparison the operator can make in three seconds.
Every decision is one click to accept or override, logged against the operator’s ID. The override is deliberately as cheap as the acceptance. A system that makes disagreeing with it expensive gets agreement, not accuracy.
Documentation happens in the background from what the operator already did, which is where the quality engineers’ lost hours come back.
Deliberate omissions. We did not build automated rejection without human confirmation, even where the model was strong enough. We did not build mobile. We did not chase the accuracy ceiling on dimensional defects. Each one came directly from a finding above.
Prioritisation
Eight candidate use cases, scored on value, feasibility and data-readiness, then cut to a phase-one MVP of two: AI-assisted inspection decision support, and automated defect documentation. Both scored at the top on all three axes.
Predictive quality management scored highest of anything on value and was deferred to phase three, because data-readiness was the constraint and no amount of design solves for training data that doesn’t exist yet.
Where It Stands, and What I’d Do Differently
Where It Stands, Honestly
The platform went into phased deployment against the plan above. Targets were set against a composite north-star metric combining first-pass yield, equipment effectiveness and total quality cost — with a defined guardrail that throughput must not degrade, because the fastest way to lose a plant manager is to make the line slower.
What I can’t claim yet is outcomes. Phase-one deployment was in progress, and we did not have clean pre-deployment instrumentation on several of the measures we most wanted to move. The honest position is that the discovery work is validated and the impact work isn’t finished.
If I ran this again I would instrument the baseline during discovery rather than after — while I was already on the line for eight days with access to every system I’d later need a number from. That’s the single biggest thing I’d change, and it’s a sequencing mistake, not a measurement one.
What I’d Do Differently
The feedback loop should have been in the MVP. We built a system that asks operators to calibrate their trust in a model and gave them no structured way to tell the model when it was wrong. Operator override data is the highest-value training signal in the entire product and we were logging it without closing the loop. It sat in phase three. It belonged in phase one.
I’d revisit confidence as a percentage. A number is precise and close to meaningless to someone who hasn’t been trained on what the model’s 92% is calibrated against. There’s a version of this interface where uncertainty is carried entirely by language and visual weight, and after watching operators read these screens under time pressure, I suspect it’s the better one.
More Projects
Vision AI
Every Second Counts: Using AI to Make Workplaces Safer
Eight days of field research told us nobody wanted a 99%-accurate inspector.
Year :
2025
Industry :
Industrial AI Vision
Client :
In-house product
Project Duration :
1 year
The Premise
The premise was straightforward. Manual inspection on a factory line is inconsistent, so build a computer vision system accurate enough to replace the judgment call. Push detection accuracy as high as it will go and the quality problem takes care of itself.
We spent eight days in three manufacturing plants testing that premise. It didn’t survive.
Quality engineers told us they would rather work with a system that was 90–95% accurate and told them how sure it was, than one that was 99% accurate and told them nothing. Not as a compromise — as a preference.
That finding redirected the product. We stopped designing an inspector and started designing a second opinion.
Context
Vision AI is a production-grade visual inspection platform for manufacturing — surface defect detection, assembly verification, dimensional inspection, and packaging quality control, running on industrial cameras and edge compute alongside existing MES and PLC systems.
I led design end to end, from discovery through implementation. Three of the five designers on my team worked on this product; I set direction across all of them and across our other projects. On the build side, AI/ML engineers, full-stack developers and a product manager, with plant-side stakeholders — quality managers, production managers, IT/OT, operators — involved throughout.
Discovery
Eight days across three shifts in manufacturing plants. Day shift, night shift, and weekend, because we suspected — correctly — that the system would be used very differently when quality engineering support wasn’t in the building.
Contextual inquiry on the line, shadowing operators through inspection cycles and watching what they actually did with borderline calls.
Stakeholder interviews across nine roles, from line operators to the executive sponsor, mapped to a RACI so we knew whose constraints were binding and whose were preferences.
Environmental audit — lighting, vibration, dust, mounting positions, network headroom.
Workflow analysis of the detection → decision → action chain, tracing where time and confidence leaked out of each phase.
What We Found
The bottleneck wasn’t detection. It was adjudication.
Borderline cases accounted for roughly a third of inspection decisions, and that’s where the system was failing — not on the defects that were obviously defects. The same defect type was classified differently by different inspectors a significant share of the time, and classification varied noticeably between shifts on borderline calls specifically. Operators told us they were uncertain on those calls, and the uncertainty had a predictable resolution: reject when in doubt.
That behaviour is expensive in a direction most quality systems don’t optimise for. Unnecessary rework was costing several times more than the customer complaints it was meant to prevent. The plant wasn’t losing money on missed defects. It was losing money on good product being thrown away by people who weren’t sure.
Fatigue was structural, not incidental. Missed defects rose measurably in the final hours of a shift. Night and weekend shifts ran with minimal quality engineering support, so the operators with the least backup were making the hardest calls at the worst hours.
The physical environment set hard limits. Illumination differed substantially between day and night shifts. Conveyor vibration displaced cameras by millimetres. Dust required daily cleaning to keep optics clear. Only two or three viable camera positions existed per station. Network bandwidth was already at around 60% of capacity during peak production — which quietly ruled out streaming high-resolution imagery to the cloud and made edge processing a requirement rather than a preference.
And documentation was eating the experts. Quality engineers were spending hours per shift on manual data entry, while the defect knowledge that mattered most lived in senior engineers’ heads and nowhere else.
The Assumptions the Research Killed
This is the part worth reading. We wrote our assumptions down before going in and marked each one against what we found.
“Operators will resist AI because of job security.” Wrong. The large majority welcomed AI assistance for decision support and rejected full automation. The resistance wasn’t to the technology, it was to being removed from the loop. Design implication: human–AI collaboration, not replacement.
“Quality engineers want automated classification.” Wrong. They wanted confidence scoring with final human validation. Design implication: build the validation workflow, not the autonomous decision.
“99% accuracy is necessary for adoption.” Wrong, and this was the one that changed the product. 90–95% with clear confidence indicators beat black-box 99%. Design implication: explainability outranks raw accuracy.
“Real-time processing is mandatory.” Overstated. Near-real-time, within a handful of seconds, was acceptable for most inspection workflows — which loosened the hardware requirements considerably.
“Operators need mobile access.” Wrong. Stationary workstations were preferred for safety and network-security reasons. We stopped designing mobile-first.
“All defect types automate equally.” Wrong. Surface defects were automation-ready; dimensional and assembly defects needed human–AI collaboration. Design implication: phase by defect complexity, not by line.
Six assumptions, four reversed outright. If we had built to the original brief we would have shipped an accurate black box to people who had already told us they wouldn’t trust one.
What We Designed Instead
An inspection decision assistant, not an inspector.
The core screen shows the AI’s read as a three-state signal — pass, review, reject — with the confidence figure attached rather than buried. Confidence is the point of the interface, not a diagnostic detail, because the research said the operator’s real problem is knowing when to trust the machine.
Alongside it, the reference panel: acceptable and defective examples side by side. This exists because borderline calls were the failure mode, and the fix for a borderline call isn’t a better number — it’s a comparison the operator can make in three seconds.
Every decision is one click to accept or override, logged against the operator’s ID. The override is deliberately as cheap as the acceptance. A system that makes disagreeing with it expensive gets agreement, not accuracy.
Documentation happens in the background from what the operator already did, which is where the quality engineers’ lost hours come back.
Deliberate omissions. We did not build automated rejection without human confirmation, even where the model was strong enough. We did not build mobile. We did not chase the accuracy ceiling on dimensional defects. Each one came directly from a finding above.
Prioritisation
Eight candidate use cases, scored on value, feasibility and data-readiness, then cut to a phase-one MVP of two: AI-assisted inspection decision support, and automated defect documentation. Both scored at the top on all three axes.
Predictive quality management scored highest of anything on value and was deferred to phase three, because data-readiness was the constraint and no amount of design solves for training data that doesn’t exist yet.
Where It Stands, and What I’d Do Differently
Where It Stands, Honestly
The platform went into phased deployment against the plan above. Targets were set against a composite north-star metric combining first-pass yield, equipment effectiveness and total quality cost — with a defined guardrail that throughput must not degrade, because the fastest way to lose a plant manager is to make the line slower.
What I can’t claim yet is outcomes. Phase-one deployment was in progress, and we did not have clean pre-deployment instrumentation on several of the measures we most wanted to move. The honest position is that the discovery work is validated and the impact work isn’t finished.
If I ran this again I would instrument the baseline during discovery rather than after — while I was already on the line for eight days with access to every system I’d later need a number from. That’s the single biggest thing I’d change, and it’s a sequencing mistake, not a measurement one.
What I’d Do Differently
The feedback loop should have been in the MVP. We built a system that asks operators to calibrate their trust in a model and gave them no structured way to tell the model when it was wrong. Operator override data is the highest-value training signal in the entire product and we were logging it without closing the loop. It sat in phase three. It belonged in phase one.
I’d revisit confidence as a percentage. A number is precise and close to meaningless to someone who hasn’t been trained on what the model’s 92% is calibrated against. There’s a version of this interface where uncertainty is carried entirely by language and visual weight, and after watching operators read these screens under time pressure, I suspect it’s the better one.