Three years in: what designing for clinicians taught me about trust
Here's a pattern that shows up across clinical software: the product is open on one screen, and a spreadsheet with duplicated information is open right beside it. In an industry where a mistake can have real human consequences, users default to the tools they trust the most, building their own trackers and overviews, regardless of how clunky or time-consuming those tools are.
Trust in clinical software is earned slowly and lost instantly. Three years into designing for clinical trials, every design choice serves one question: will a user trust this system enough to act through it, or will they hedge their bets with supplemental tools? Four principles have come to guide my answer to that question.
1. Make innovation feel safe
Risk aversion in clinical software is not a UX friction to be smoothed away; it is the appropriate mindset for the domain. Patients can be harmed when mistakes are made, clinical operations are audited, and regulatory frameworks do not forgive accidents. The cautiousness clinical users bring to their work is not a quirk to be designed around but the thing that makes them good at their jobs. Innovation in this space cannot rely on users embracing change for its own sake; it has to win them over by leaving their sense of safety intact.
As a designer, it is tempting to reach for entirely new patterns and disrupt existing workflows in pursuit of a better experience. But disruption itself can undermine the sense of safety that comes from industry-standard practices. A product that looks radically different can feel exciting to a designer or product manager, and alarming to a clinician at the same time. Innovation in clinical software has to be earned by maintaining psychological safety, and in my experience, that safety comes from four things: reliability, compliance, feedback, and familiarity.
Reliability and compliance are obvious: a system has to do what it says it will do, every time, or users quietly stop trusting it. Regulatory processes and requirements should be embedded directly into the flows themselves, so that the user does not have to take compliance into their own hands. There should be no anxiety on the user's part about whether a new tool or feature is compliant. Feedback is closely related but more subtle: users need to know what just happened, what happens next, and what they are responsible for at any given moment.
Familiarity is the trickiest of the four, and the one that took me longest to understand. Most clinical users have come up through systems that look as though they were built in 1998 (dense, form-heavy, rigid), and those systems have shaped what "safe" looks like to them. The craft is to make something meaningfully better feel familiar to use: to honor the mental models users already have, to introduce new capabilities as augmentations rather than replacements, and to let users find the improvements at their own pace. The only way forward is incremental: small, consistent wins stacked up over months, not a redesign that asks users to leap.
2. Support clinical judgment, don't replace it
If the first principle is about earning a user's trust in the system, the second is about the system respecting user expertise. This is particularly pertinent when it comes to AI, levels of automated decision-making, and human-in-the-loop processes. Real clinical work is variable; it requires judgment and interpretation that cannot be hard-coded into systems.
A suspect datapoint is sometimes accurate. Two reasonable clinicians can assess a clinical event quite differently. A system’s design needs to be able to handle these types of judgment calls. When the system cannot accommodate deviations from the “norm”, the clinician gets stuck, and both the patient and the data suffer. Instead of refusing an action or entry, a robust system flags it and requests a rationale, which is captured and folded into the audit trail. The friction of documenting rationales and generating an audit trail is the price paid for clinician autonomy.
Supporting clinical judgment also means considering the availability, salience, and contextualization of information. Medication time, prior test results, related trends, and patient history all dramatically impact clinical judgment. As a designer, I work with clinicians to understand what information is critical to clinical interpretation and decision-making, and ensure that information is surfaced appropriately. Users need to be able to trust that the system provides relevant and accurate information to help them make a decision. This is equally true where AI might be used to speed up workflows: clinicians still need to know what data informed an agent’s recommendation or assessment, as well as maintaining ownership over the final decision.
3. Design for interruption and resumption
Clinical workflows are rarely linear. A clinician's day is full of interruptions: patients, phone calls, questions a colleague needs them to weigh in on, and providing second opinions. Patients themselves may be managing conditions that make it hard to complete a long form or task in a single sitting. A workflow that demands completion in one go is likely to be abandoned, restarted, or scribbled in notes with the intention of being copied into a clinical system later. None of those outcomes is kind to data quality, and all of them push users back toward the spreadsheet they trust.
The starting point, before any UI choice, is to think in terms of jobs to be done rather than interfaces. If a job is interrupted, what information would a user need to resume it? Clinical systems tend to surface all available information rather than the information needed to complete the task at hand, making resumption harder rather than easier. A user coming back to a screen full of context has to wade through it to find the small set of facts they actually need to act on.
Designing around this reality shapes a product in several practical ways. Forms have to be savable in partially complete states, with visible markers showing what is missing and gentle reminders nudging users back to finish them. Multi-step workflows benefit from traffic-light indicators that show, at a glance, what is done, what is outstanding, and what is waiting on someone else. Interfaces need information anchors - design choices that allow a user returning to a screen after hours away to immediately understand what they are looking at: which patient, which event, what they need to know in order to pick back up. Every time a returning user can re-anchor in under a second, the product earns a little more of the trust it needs.
4. Design for shared ownership
As already mentioned, feedback and visibility are essential to trusting a system: knowing what needs to be done, what the next steps are in a patient's care, what paperwork is outstanding, etc. The fourth principle is about how trust extends past any one user - how a team as a whole comes to trust a clinical system. When shared ownership and visibility are missing, it creates single points of failure that degrade trust quickly: A patient needs to be assessed by a second clinician; has that been done? A colleague is on holiday; what is the status of their work, and what is next for the patients in their care? Lab results were pending; have they been collected and reviewed? These are the types of questions that a team needs to be able to answer quickly and confidently.
For a long time, our system had a name on every task, with visibility limited to the task owner. One person owned it; one person was on the hook. When that person went on leave, we layered rota systems on top, and when those rotas were not updated, things fell through the cracks. In a clinical setting, those cracks are not benign. The shift we ended up making was structural rather than purely visual: the team, not the individual, owns the outcome, and outstanding work lives in a shared queue that anyone with the right role can pick up. Accountability is still traceable (who did what, when, and why), but the queue does not grind to a halt because one person is off, and when every task is visible to everyone, the team itself can be confident that nothing is slipping through.
Questions I now ask myself in design review
After three years, these principles help me design for users who are making a rational bet on whether the system can be trusted with an outcome they'll be held accountable for. These principles tend to linger as questions in the back of my mind whenever I'm looking at a design.
This is not a comprehensive list, but hopefully it's useful to anyone designing clinical tools:
- How does this design build on familiar patterns?
- What information is pertinent to a clinical judgment? If a clinical assessment is made, what information might change that assessment?
- Is the information provided appropriately contextualized?
- What happens when the user is interrupted or pulled away mid-task? What information is needed to resume/pick back up?
- What happens if all the information required to complete a task is not available (as is often the case in clinical work)?
- How does the system handle unforeseen edge cases? Will it result in anyone getting stuck?
- Does the user need to reference external documentation / manuals to act compliantly in this workflow, or does the system handle it for them?
- Can a team as a whole understand this workflow and outstanding actions? Or are tasks too siloed?
