A Working Feature Isn't the Same as a Trusted One
Leonardo De La Rocha · 26 September 2026
Read the originalClinicians doubted an autosave feature that worked, so the product team paused its rollout and added an indicator that shows the save while it happens.
A company that makes software for clinicians shipped autosave for patient notes, with a timestamp showing when each note was last saved. The feature worked, but clinicians told each other in the company's customer community that they were not sure their notes were safe. The team that owns the feature paused the rollout on its own initiative and added an indicator that shows the save while it is happening.
- The company's design lead, Leonardo De La Rocha, explains the gap. The timestamp said when the note was saved, while clinicians wanted to know whether their work was safe right now.
- The next day, a design review split a button that combined approving a document and moving to the next one. A person now sees the approval land before the screen changes.
- De La Rocha is adding one question to every product review he attends this year: "Do clinicians understand and trust it?"
- For any feature that acts on someone's behalf, he asks what the person sees while it happens and right after, before they move on.
A team adding automation can treat what a person sees during and just after an automated action as a design question of its own. De La Rocha recommends this himself for anything that acts on a person's behalf.
Add the question of whether users understand and trust a feature to every product review, beside the question of whether it works.
Design what a person sees while an automated action runs and just after it ends, such as a saving indicator, before the feature ships.
Derived by Working Surface from the article. Source line: do clinicians understand and trust it
27 September 2026: when AI writes part of the work, people need to see what was made, by whom and from what.