When we talk about improving clinical software, we usually mean changing what it does. New functionality. Better workflows. Faster integration with the systems around it.
Those things matter.
But for the person in front of the screen, the words are not a layer on top of the software. They are the software they experience.
In 2009, Davis and colleagues asked 359 primary care patients what a set of prescription instructions meant. Clinically, every version said the same thing. Correct understanding ranged from 53% to 89%, depending on the wording.
Thirty-six percentage points, decided by a writing choice.
The versions that performed best named the times: in the morning, at bedtime. The versions that performed worst gave a frequency: twice daily, or an interval in hours.
The difference was not clinical. It was linguistic.
A frequency is not an instruction. It is raw material for one, and it asks the reader to finish the job. The better wording had already done that work.
“Write more clearly” is easy advice to give and difficult to act on. It is more useful to understand the specific ways wording goes wrong, four of which come up repeatedly in our own testing.
1. Vocabulary mismatch
The term is correct in the language of the organisation that chose it, but unfamiliar to the person reading it, or means something else to them.
A clinician does not need to know that a transaction was successful. They need to know that their referral has been sent.
2. Ambiguity
Wording carries two possible meanings, with no way for the reader to know which was intended.
A stop date might mean the last day of treatment or the first day without it. Last day of treatment settles it.
3. Generality
The wording has one meaning, but not enough information to act on.
An error occurred leaves the reader unable to tell whether to try again, change what they entered or call someone.
Concise is useful, but not when it leaves the reader to work out the next step.
4. Misstated commitment
Wording suggests a different process from the one the user is about to complete.
Apply for access to your test results suggests a form, a decision and a wait. See your test results suggests immediate access. If the next step is verification, Verify to see your test results describes the interaction more honestly.
None of these are failures of effort. In each case, the wording was chosen by someone who knew what they meant and read by someone who did not.
Wording changes outcomes well outside clinical software too.
Hallsworth and colleagues reported two randomised trials across roughly 20,000 NHS outpatients, testing different wordings of the same appointment reminder. The reminder that stated the specific cost of a missed appointment reduced non-attendance from 11.1% to 8.4%. A version making the same argument without the figure was less effective.
The messages made the same argument. Only one made it specific.
Specificity helps the reader act on what they read. Simplicity helps them understand it in the first place.
The NHS digital service manual makes a related point. Many patients do not reliably understand the word clinician, common though it is among healthcare professionals. The recommendation is to say a doctor, nurse or other healthcare professional instead.
It also notes something counter-intuitive: the more specialist a reader’s knowledge, the stronger their preference for plain English.
Writing simply is not writing down. It is removing work the reader should never have had to do.
During a usability study of DXS Next-Gen, we asked participants to complete a patient referral. One step required them to select the referral and press a button labelled Create Task.
Nine of the fourteen abandoned the task before clicking it.
Create Task accurately described what the system did. But participants expected the button to create a job for someone else in the clinical system we integrate with, where Task already holds that meaning.
The label was not vague. The word was already spoken for, in a system they used every day.
What we took from it was not to write more plainly. It was to learn the vocabulary of the host system.
We changed two things. We relabelled the button Create Form and wrapped it in a banner with supporting help text. We cannot say which change mattered more. But in the next round, with a fresh cohort, task completion rose from 36% (5 of 14) to 75% (6 of 8).
The functionality had not changed. The wording had.
Wording needs to be tested alongside interactions, not written afterwards. In usability sessions, we watch what people do rather than simply asking whether a label is clear: the pause before clicking, the wrong route taken confidently, the task abandoned. Before that, a written standard and a drafting check catch the easy cases, so testing is spent on the ones we could not have predicted.
We also keep terminology consistent. Drift between submit, send and refer for the same action makes a familiar workflow harder to follow.
And we treat wording as part of the safety of the system. An ambiguous instruction can cause real harm, and changing it deserves the same care as a change to the logic beneath it.
The lesson is not that every word needs more scrutiny for its own sake. It is that, in healthcare, language is part of the system.
Misunderstanding is a design finding, not a user problem.
The most useful changes may not be the most visible ones. Sometimes improving clinical software means changing what it does.
Sometimes it means changing one word.
Interested in how user-centred design and testing can help make clinical software clearer, safer and easier to use? Get in touch – hello@dxs-systems.co.uk
