Project
Enterprise Computer Vision Platform
Domain
Enterprise AI / Computer Vision
Role
Product / UX Design
An in-house computer-vision platform designed for operational environments such as manufacturing, where AI detections needed to become understandable, reviewable human decisions.
Research and discovery
Site visit
Direct interviews with users and operators
Observing the existing operational workflow
Stakeholder discussions
Domain-expert input
Repeated product reviews
The real product interface and identifying details cannot be shown publicly. Visuals in this case study are intentionally abstracted to explain the system, workflow and design decisions without recreating confidential UI.
02 — The system behind the screen
A camera sees something. Eventually a person acts. Almost all of the design work lives between those two moments.
Source → detection → alert → evidence → human review → decision → record. Incident handling runs downstream as its own workflow.
That chain is usually drawn as a single line, which hides the thing that matters most about it: it changes hands. The system notices. A person judges. The system keeps what was judged.
Downstream workflow
Incident triage runs as its own workflow, with its own ownership and assignment.
What the system does is bounded. It watches the source, raises a detection, carries it forward as an alert with its severity and current state, and assembles the evidence a person would need. Then it stops and waits.
What the person does begins at review. They see the detection, its evidence and its confidence, and decide whether to accept the AI result or override it. They can also defer.
Afterwards the system takes over again, logging the decision and the metadata around it so the judgement isn’t lost once the alert leaves the screen.
03 — What made this difficult
Detection was the part that worked.
A computer-vision model can tell you that something happened in front of a camera. It cannot tell you whether it matters. That gap is where this project lived.
01
The chain was longer than the screen.
Between a camera seeing something and an action being recorded, seven things had to happen: detection, alert, evidence, review, decision, incident, record. Only part of that chain could be visible at once. Designing it meant deciding what to show at each step, and what to hold back until it was needed.
02
Everything after detection was a human problem.
The model’s job ended when it raised an alert. Is this real, does it matter, what do I do, who needs to know — all of that belonged to a person. The interface had to carry machine output and human judgement in the same frame without blurring which was which.
03
The AI had to fit into work that already existed.
Operators already had a way of noticing, checking and responding to events on the site. Introducing AI could not mean asking them to abandon that mental model and learn an entirely separate process. The design had to make AI useful inside the existing workflow, while changing only the parts where the system could genuinely reduce effort or improve visibility.
04 — Understanding the operator’s decision
The work started on the site, not in a design file.
We visited the manufacturing site and observed operators working the existing process. We interviewed the people who would use the system, and reviewed the workflows already in place before proposing anything to replace them. We ran stakeholder discussions and brought in domain-expert input to understand what the site actually cared about. As the solution took shape, we took it back through product review repeatedly rather than handing it over once.
The UX problem was not simply showing an AI detection. Operators needed enough context, evidence and system state to judge whether the event mattered and decide what to do next.
That changed what the product had to be. A detection feed would have been straightforward. A decision surface was a different problem — it had to hold the event, the evidence behind it, the system’s own state, and the consequences of acting, close enough together that one person could weigh all of it at once.
The decision questions the workflow had to support
05 — Key design decisions
01
Evidence before action
What we learned
An alert states that something was detected. On its own it doesn’t show what was detected, so there’s nothing for a person to check the claim against.
The tension
Evidence takes space and time. Putting actions within immediate reach makes the interface faster, and lets someone act on a claim they haven’t verified.
My decision
I made evidence surface before any action became available. The operator sees what the system saw first; the action follows.
Why it mattered
Verification becomes the default rather than an extra step. The interface stops treating a detection as a fact and starts treating it as a claim to be checked.
Review — order of appearance
Evidence
Actions
Accept AI result
Override / correct
Actions become available after the evidence is shown
02
Make uncertainty visible
What we learned
AI detections were not equally certain. Showing the result without its confidence could make the output appear more definitive than it actually was.
The tension
Confidence adds information the operator has to interpret, but hiding it removes useful context about the system’s uncertainty.
My decision
I surfaced confidence alongside the detection and its evidence, so uncertainty stayed visible at the point of review.
Why it mattered
The operator could judge the AI output with more context instead of treating every detection as equally certain.
03
Make urgency and ownership explicit
What we learned
Alerts did not all carry the same operational importance. The operator also needed to understand the current state of the alert and who was responsible for responding to it.
The tension
If every alert is presented with the same visual weight, urgency becomes harder to judge. But making everything visually loud simply creates another form of noise.
My decision
I used severity and operational state to make urgency visible, while keeping ownership and response context close to the alert.
Why it mattered
The interface helped operators understand not only what happened, but also how seriously it should be treated and who needed to act.
Alert list — urgency, state and ownership
Alert 01
State: Needs review
Owner: Assigned
Alert 02
State: In review
Owner: Assigned
Alert 03
State: Open
Owner: Unassigned
Severity shown as weight, not as a named scale
04
Keep humans in consequential decisions
What we learned
The workflow ends in operational actions with real consequences on the site.
The tension
Automating the final step is faster and removes a bottleneck. It also removes the person who can tell when the system is wrong.
My decision
I kept consequential actions behind a human decision. The system prepares the decision; it doesn’t take it.
Why it mattered
Accountability stays where it can actually sit. Someone remains answerable for the action.
05
Preserve traceability after action
What we learned
A decision made in the moment gets looked at later, by people who weren’t there.
The tension
Recording everything adds weight to the interface and slows the moment of action. Recording nothing makes past decisions unexplainable.
My decision
I made sure the operator’s decision and annotations were logged with the alert, so the judgement was preserved rather than lost after review.
Why it mattered
Decisions remain reviewable after the fact.
06 — The resulting system
The system’s job is to notice. The decision belongs to a person. This is what both look like, end to end.
The line from source to record reads straight, and it isn’t. Review is where it branches, and the branches are the product.
What the system does
Watches the source
Raises a detection
Carries it as an alert with severity and current state
Shows the detection with its confidence at the point of review
Assembles the evidence
Logs the decision and its metadata
What the person decides
Whether to accept the AI result or override and correct it
Whether to defer
Ownership and assignment sit in the wider alert and incident workflow
What stays afterwards
The operator’s decision or correction
The decision metadata captured with it
The chain
01
Source
02
Detection
03
Alert
04
Evidence
05
Human review
At review, the person decides
Accept AI result
The operator agrees with what the system raised.
Override / correct
The operator disagrees and corrects the result.
Defer
The judgement is not made at this moment.
All three are logged · operator annotations and decision metadata captured
Downstream workflow
Incident triage — its own workflow, with its own ownership and assignment
The system does not assume it was right.
At review, an operator can accept the AI result or override it. Both are decisions the product is built to support. Correcting the model isn’t an exception path bolted on beside the main one — it’s reached the same way and treated as a decision in its own right.
There is also a third option: defer. Not every judgement can be made the moment it’s asked for.
Incident handling sits downstream. A decision at review is not the same thing as an incident. Incident triage ran as its own workflow, with its own ownership and assignment.
What survives is the judgement. Operator annotations and decisions were logged, with decision metadata captured alongside them. The human correction outlives the review — the system keeps what a person concluded rather than discarding it once the alert leaves the screen.
System representation intentionally abstracted due to NDA.
07 — Reflection
This project changed how I thought about AI UX. Presenting model output clearly was only one part of the problem.
Working with operators changed that for me. The model was one voice in a decision that also involved evidence, urgency, ownership, and a person who would have to answer for what happened next.
The more consequential a system becomes, the more the design work sits around the model rather than on top of it — what counts as evidence, how uncertainty is shown, who owns a response, when a person has to intervene, and what happens when the system is wrong.
The AI could notice. The product had to help a person decide.