Datch
Project
Diagnostic Agent
Product
Datch DA
Knowing when to talk and when to show
Datch is an AI assistant that helps maintenance technicians in heavy industry get stopped machines running again, using their own manuals, procedures, work history, sensor data and drawings.
Role
Product Design Lead and sole designer, covering UX, UI and research
Team
Product, backend and AI engineering teams
Timeline
2024 to 2026
Outcome
Live in 5+ large manufacturers, from steel to injection moulding, some across several sites
The problem
impressive in demos, not on the floor
Datch started life as an insights tool. It showed how data across a business fitted together, and it demoed beautifully. On the factory floor it fell flat. A technician standing at a stopped machine doesn't care how two pieces of data relate. They need a practical answer, fast.
So the company pivoted to the assistant Datch is today, and gave us two weeks to go from concept to a production-ready MVP.
Research
six profiles that kept themselves current
I built six user profiles from conversations with maintenance teams in semiconductors, steel, injection moulding, bottling and medical devices. Personas usually go stale within months, so I set up an AI automation that processed customer calls and interviews, pulled out pain points, feature requests and sentiment, and fed them back into the profiles.
One customer story summed it up. A big machine was down for several shifts. Each shift, a technician tried the most obvious fix, it failed, and the shift ended. Handovers weren't structured, so the next technician tried exactly the same thing.
That gave us two problems to design for:
Context gets lost between shifts.
There's no clear path through an unfamiliar fault.
And one insight: technicians don't need more information. They need structure.
First attempt
answers that said too much
Our early responses tried to be as complete as possible. A simple question returned everything Datch could find, grouped into themes: information, documents, procedures.
Technicians didn't like it. Every answer became a reading task beside a stopped machine. Thorough wasn't the same as useful, and that pushed us towards short answers that change shape depending on what the technician is trying to do.
Decision
each answer picks its own shape
In a normal app, a designer decides what each screen shows. In an AI product the answer is generated on the spot, so the design question moves from "what goes on this screen?" to "what shape should this answer take?"
Datch decides that for every response. It identifies what the technician is trying to do, then judges whether it knows enough to give a reasonably correct answer. If it doesn't, it asks. If it does, it shows, using the pattern that fits.
Testing
three prototypes, one winner.
I took three prototype variants into moderated sessions and tested each against the two problems from research. Workbench won.
It began as a ranked list of probable causes. Each round of iteration took something away, until two parts were left:
Log what you see. Technicians note symptoms and facts as they find them. It all builds into a case that the next shift, or a colleague, can pick up.
What should I do next? For when they get stuck. Datch looks at everything in the case and the site's own knowledge, and suggests one specific task at a time.
The first part serves technicians who know what they're doing and just need to keep track. The second catches them when they run out of ideas.
System
patterns the AI can use anywhere
Because the AI chooses the pattern, any pattern can show up at any moment, next to any other. I built the design system from scratch around four families: conversational guidance, document and drawing tracing, knowledge management, and root-cause analysis. New features slot into those families instead of needing new UI.
The floor sets the rules: noise, gloved hands and no time to spare. So touch targets are large, steps are few, voice is a main input, and every layout works on web, tablet and phone.
