Designing trust in a black box
Overview
In late 2023, AI products were rapidly emerging, but there were few established patterns for how professionals could safely work alongside them.
BeneDocs was an AI clinical documentation tool that helped doctors turn patient notes into structured clinical documents, such as admission notes and discharge letters.
The underlying technology already existed. The product risk was whether doctors would trust it enough to use it in clinical practice. If doctors could not understand what was happening, protect patient information and stay in control of the final document, the AI would feel too risky to rely on.
I led product design from discovery through to beta, aligning founders and engineering around a workflow that translated a multi-step AI process involving de-identification, prompt chaining, document generation and re-identification into an experience doctors could understand, review and control.
My role: Product Designer, leading discovery-to-beta experience design
Collaborators: Founders (Doctor & Nurse), Design, Engineering
Scope: Workflow design, interaction design, systems thinking, stakeholder alignment and design validation
Simplifying a complex AI workflow into a trusted clinical experience
The most difficult part of the project wasn’t designing the interface. It was deciding how much of the AI process users actually needed to see.
Too little visibility would feel unsafe. Too much technical detail would shift attention away from the clinical task.
BeneDocs relied on a sophisticated AI workflow, but prompt chains and model architecture were not what doctors needed to understand to use it safely.
Early discussions suggested exposing more of the workflow to increase transparency, but surfacing the technical process made the experience feel harder to understand. Instead of creating confidence, it raised more questions about what the AI was doing, how long it would take and whether doctors were still in control.
I simplified the experience into a five-step workflow: create or select a template, paste patient notes, de-identify sensitive data, generate and re-identify the document, then edit and export the final output.
This kept doctors focused on the clinical task rather than the AI architecture behind it, while giving the team a practical product framework for design, engineering and beta validation.
The design challenge was not to expose the full AI architecture, but to translate it into a workflow doctors could understand, review and control.
Designing confidence in an unpredictable system
A key challenge was designing for the document generation step.
Behind the interface, BeneDocs relied on a twelve-step prompt chain that produced the final document. Processing time could vary, and the system could not reliably expose where it was in the sequence.
That made common loading patterns misleading.
A progress bar suggesting 70% completion could easily be wrong. An endless spinner risked making the product feel broken.
Rather than relying on percentages, I designed dynamic status updates that gave doctors meaningful reassurance without pretending the system could provide precision it did not have.
The updates focused on three things:
Progress
The system was still working.
Security
Patient information had been de-identified before generation.
Control
The doctor would review and edit the final document before using it.
The goal wasn’t to make the AI feel magical. It was to make it feel dependable.
By focusing on confidence rather than technical transparency, we created an experience that remained trustworthy despite the uncertainty behind the scenes.
Status updates reassured doctors without pretending the system could provide precise progress. Each message focused on what mattered most: the system was working, patient data was secure and the doctor remained in control.
Improving outcomes before generation begins
One of the most important product decisions centred on how BeneDocs learned a doctor’s writing style.
The original approach used a doctor’s first set of notes as the default template. It was technically simple, but risky. A first attempt could contain formatting issues, incomplete structure or a tone that did not reflect the doctor’s preferred documentation style.
I challenged that approach and aligned the team around a more intentional template setup, where doctors uploaded an example document before generating their first output.
This traded a small amount of upfront onboarding effort for stronger first-output quality. For an AI product, that first generated document was a critical trust moment: if the output felt wrong, doctors were unlikely to keep using it.
It also created a stronger foundation for future flexibility, allowing doctors to create and manage multiple templates over time.
Asking doctors to create a template upfront added a small amount of effort, but improved control over tone, structure and output quality from the first generated document.
The outcome
While I left before launch and do not have adoption metrics, the work gave the team a clear beta-ready product direction: translating a technically complex AI process into an experience that made data handling visible, reduced unnecessary complexity and kept doctors in control of the final clinical document.
The project reinforced an important lesson about designing for emerging technologies: users do not adopt products because the technology is impressive. They adopt them because the experience feels trustworthy.
Key takeaway
Designing for AI adoption is not about revealing everything the system does.
It is about giving users enough clarity, control and confidence to trust the moments they cannot see.