Principles of Health Informatics: Usability of medical software

Lecture 19: Usability of medical software
Dr. Martin Chapman
Principles of Health Informatics (7MPE1000). https://martinchapman.co.uk/teaching
Different
book

Lecture structure
Prologue: What is usability?
The Usability Engineering Lifecycle (Part 1) - Design
Lecture 19: Understanding the user, participatory design and guidelines
and heuristics.
The Usability Engineering Lifecycle (Part 2) - Evaluation
Lecture 20: User testing, user assessment methods and iterative design
and follow-up.
Epilogue: Making the lifecycle work

Learning outcomes
1. To be able to understand and apply the five usability principles
2. Be able to perform a Hierarchical Task Analysis (HTA) and
understand its limitations
3. To understand different participatory design methods
4. To be able to recall the 10 key usability heuristics, and
understand how they connect back to the type of user and their
tasks

What is software?
Software is computer code (some of which we’ve seen in this course),
which allows a user to perform a specific task.
It contrasts hardware, which is the physical components of the
computer on which the software runs.
Hardware Software
To answer this question we
first have to ask some other
questions.

What is medical software?
A type of information system
designed to deliver clinical benefit.
We’ve seen a few examples in the
course already, including EHR
software and communication
software.
A key part of an information
system is its human-computer
interface; how we interact with it.
A piece of search software
(designed to mitigate bias)

Recall: Design processes
In Lecture 6 we saw that for an information system to deliver clinical
benefit (i.e. for medical software to deliver benefit), it must be
designed in accordance with a defined process.
Processes should exist for multiple aspects of the proposed system,
including the user interface.

Aside: User Interfaces
User interfaces, or the mechanism by which a user interacts with a
system, can take many forms. We are most familiar with graphical
user interfaces (GUIs; mouse), but we can also have command line
interfaces (CLIs; keyboard) and voice user interfaces (VUIs; voice).
We will mostly consider user
interfaces to be graphical, in
these lectures.

What is (UI) usability?
As the medium by which a software system provides functionality to
a user, getting the design process right for a user interface (UI) is
very important.
An interface needs to follow a good design process so that it does not
inhibit the use of the system that it provides access to.
We will mostly consider usability principles
in respect of user interfaces, but they can
also apply to a system in general.
We call such a UI usable, and indeed a number of
fields exist to examine this idea, including the field
of human-computer interaction (HCI). We can also
expand this definition further…

Five usability principles
There are five general principles that any system should exhibit (in
particular its UI) in order to be considered usable, each of which will
be made specific in different ways across the next two lectures:
1. Learnability
It should be easy for
a user to learn how
to use a system
2. Efficiency of use
It should be efficient
to use a system
We will mostly consider usability principles
in respect of user interfaces, but they can
also apply to a system in general.

Learnability vs. efficiency
There is, in some sense, a
conflict between these two
principles, because a system
that is quick to learn may
ultimately be less efficient.
For example, while a terminal
interface takes longer to learn,
it can offer users more
efficiency in the long run when
manipulating a file store than a
typical file explorer.
No one-size-fits-all
UI; trade-offs are
often necessary.

3. Memorability
It should be easy to
remember how to use
a system Some systems may have a steep
learning curve, but are ultimately
memorable.

4. Errors
Minimal errors in the
system that are easy to
recover from and only
impact efficiency, and no
major errors A typo in a
spreadsheet formula
A corrupted spreadsheet
after using a datatype
incorrectly

5. Satisfaction
A system should be
pleasant to use

Likert vs. Semantic differential scale
We can ascertain satisfaction by issuing questionnaires to users.
The questions within a usability questionnaire typically take two forms.
They either use the Likert scale with discrete answers or a Semantic
differential scale where users can place a rating along a dimension.
Likert scale Semantic differential scale
Strongly
disagree
Strongly
agree
HIX was not a
good module
HIX was a
good module
I think HIX was a good module

Why is usability in healthcare important?
In Lecture 6, we (again) saw how there are levels of risk associated
with the use of software in healthcare.
It all comes back to interventions…
One area of risk is user error, such as prescribing the wrong drug or
dosage of a drug to a patient.
There is a more significant risk of user error if the interface of
medical software has poor usability.

Aside: System acceptability
Usability (of a system’s UI) is part of the wider concept of system
acceptability, some aspects of which have been touched on in
previous lectures.

The Usability Engineering Lifecycle

Recall: Lifecycle models
As we saw in Lecture 6 (again), many software design processes
move through certain stages (e.g. the waterfall model), and the
design of a usable user interface is no different.
As lifecycles, the design of a user interface and the design of a wider
software system are not distinct, with some stages overlapping.
We may, therefore, have already discussed (indirectly) some of these
stages, and will aim to go into more detail here.

We will consider a specific UI development model which is called the
Usability Engineering Lifecycle.
This model has two distinct phases, the design phase, which is
covered in this lecture, and the evaluation phase, which is covered in
Lecture 20.
Design phase:
Participatory
design
Understanding
the user
Guidelines and
heuristics
Again, we will consider how this lifecycle
applies to UIs, but it can also apply to
systems in general.

Understanding the user

User characteristics and tasks
The characteristics of the users who will be using the software and
the tasks they are likely to need to perform with it are two of the
most important considerations when designing a user interface.
An understanding of both of those things should feed directly into
the design process.
We will consider how this can be done in the following slides.

User characteristics
A number of different characteristics
of the target user(s) should be
considered, including their experience
in a particular work domain, their
age, and their previous computer
experience.
We can create a chart that
places some of these
characteristics on a scale.

User characteristics
An understanding of these
characteristics can then, for
example, help us set
appropriate limits for the
complexity of an interface.
The complexity of the interface
for a piece of software designed
to teach children how to code
should differ from a full
development environment.

User tasks
As well as understanding a user’s characteristics, it is also important
to understand how they approach tasks (with the latter often being
a product of the former).
This is so that the system being designed can correctly support these
tasks.
It is important to gain an understanding of several things for any
given task: overall goals, current approach to the task, information
needs and how exceptional circumstances are dealt with.

User tasks
Current approach to the
task of writing code:
Goals To learn To deliver a product
Approach Explorative Directed
Information needs High Low
Exceptional
circumstances
Apprehensive Decisive

User tasks
Goals Entertaining Focussed on supporting
efficient output
Approach Visual Ordered
Information needs Lots of clear
explanations
Fewer explanations
Exceptional
circumstances
Help and warnings Detailed error messages
Software can then aim to
accommodate these task
properties
The resulting software
should be, as a result:

Hierarchical Task Analysis (HTA)
While an understanding of these elements is a reasonably systematic
way to understand how a user completes a task, and thus how to
support this task in an interface, there are more formal approaches.
One of these is a hierarchical task analysis (HTA) which aims to
formally and visually determine how a user completes a task.
There are three key steps to a hierarchical task analysis: identify
different tasks, organise those tasks into a hierarchy of tasks and
subtasks, and order subtasks into plans.

Making a cup of tea
0. Make a cup
of tea
Start with a single high-
level task.
We label this as
task 0.

Making a cup of tea
0. Make a cup
of tea
The ‘next level’ of tasks
involved in making a cup of tea
We label this as
task 0.
1. Boil
water
2. Wash
mug
3. Put tea
bag in mug
4. Pour in
water
5. Wait a
few minutes
6. Remove
tea bag

Plan 0 (numbered according to parent task):
- Do 1
- At the same time, if the mug needs to be washed
do 2, and then do 3
- Following this do 4, 5 and (after a few minutes) 6
Making a cup of tea
0. Make a cup
of tea
Now that we have more than
one task we need a plan that
describes the order in which the
user approaches these subtasks.
1. Boil
water
2. Wash
mug
3. Put tea
bag in mug
4. Pour in
water
5. Wait a
few minutes
6. Remove
tea bag

Making a cup of tea
0. Make a cup
of tea
Some of our tasks can’t be
decomposed any further so stop
here (note the line).
1. Boil
water
2. Wash
mug
3. Put tea
bag in mug
4. Pour in
water
5. Wait a
few minutes
6. Remove
tea bag
However some of our tasks can
be decomposed further.
1.1 Fill
kettle
1.2 Wait to
boil
1.3 Switch
kettle off

Making a cup of tea
0. Make a cup
of tea
We can add plans at any level
of the hierarchy
1. Boil
water
2. Wash
mug
3. Put tea
bag in mug
4. Pour in
water
5. Wait a
few minutes
6. Remove
tea bag
Plan 1
- Do 1.1 and then 1.2
- When kettle boils do 1.3
1.1 Fill
kettle
1.2 Wait to
boil
1.3 Switch
kettle off

HTA critique
There is clearly an air of subjectivity to performing an HTA,
particularly in how to connect subtasks with parent tasks.
Working directly with a user to understand their tasks, using
techniques such as interviews, is likely a good way to offset this.
Each time a user says ‘then I do this’, an interview can say either
‘how do you that?’ to identify subtasks, or ‘why do you do that?’ to
identify wider goals.

Participatory Design

Consulting users before and during the design phase
The methods we’ve seen so far to understand a user are designed to
take place before the design process begins.
If, however, additional questions or issues arise after the design
process begins, users should, once again, be consulted.
The consultation of users during the design process
we refer to as participatory design.
Participatory design is said to
have its roots in Scandinavia

Prototypes
As users are (typically) not designers, they are usually not asked to
come up with designs from scratch during participatory design.
Instead, they are usually consulted on system prototypes for ideas on
how to proceed with the design.
What differentiates a prototype
from a full system is a reduction
somewhere, be it the number of
features it has or the complexity
of these features.
Access real data for
a search term.
Search for lots of
terms with no data
Scenarios only work
if the user follows a
certain path

Prototypes in participatory design
For participatory design, the prototypes users are consulted on are
typically not fully functional prototypes but are instead mock-ups,
such as simple screen designs.
Prototypes, in the form of mock-ups, used to elicit feedback on the
CONSULT DSS.

Participatory design methods
Participatory design is less a single approach to assessing users’ ideas
about how to proceed with a design from a prototype, and more a
set of possible methods.
Probe: Questioning
Prime: Immerse users in
domain
Understand: Current
experiences
Generate: Create ideas
or design concepts
Form
Purpose
Elizabeth B.N. Sanders, Eva Brandt, and Thomas Binder. A framework for organizing the tools and techniques of participatory design. 2010.
Form
Form

Participatory design methods
In the CONSULT project, cards, in conjunction with ideation matrices, were
used to elicit feedback on the CDSS prototype seen previously.
Panos Balatsoukas, Talya Porat, Isabel Sassoon, et al. User involvement in the design of a data-driven self-management decision
support tool for stroke survivors. In 18th International Conference on Smart Technologies (EUROCON 2019), pages 117–122, 2019.

Participatory design vs. co-design
Co-design (or co-production) is another term you may hear when
participatory design is mentioned.
In healthcare, participatory
design and co-design are
especially important.
This is, however, a distinct
term, with co-design focussing
much more on users generating
design ideas from scratch,
rather than using prototypes to
generate ideas (and feedback).
We also have other engagement
methods, where users don’t
directly impact the design process.

Guidelines and Heuristics

Guidelines and heuristics
It’s clear that involving users in the UI design process is one of the
most important ways to determine how to proceed with a design.
However, users can’t be involved in the design process all the time,
so how do UI designers work without their presence?
Designers are, of course, trained individuals with experience, but
there are also what we call guidelines or heuristics for the
development of user interfaces which are rules of thumb that distil
good practice for (other) designers to follow.
We’ve already seen clinical
guidelines, which distil good
practice in a medical context.

General, category and product-specific design guidelines
General guidelines (explored here) are applicable to all interfaces,
whereas category-specific guidelines apply only to certain systems
(e.g. window-based interfaces vs. voice interfaces), and product-
specific guidelines only to specific systems under development.
General
Category-specific Product-specific

General design guidelines
To close out this lecture, we’ll briefly go through 10 key usability
guidelines.
Many of these relate back to and depend upon the type of users a
system is aimed at, and their tasks.
1. Simple and
Natural
2. Speak the user’s
language
3. Minimise memory
load
4. Consistency 5. Feedback
6. Clearly
marked exits
7. Shortcuts 8. Good error
messages
9. Prevent
errors
10. Help and
documentation

1. Simple and Natural
A user interface should only present the exact information a user
needs, and no more.
In other words, with a specific type of user in mind, an interface
should be as simple as possible.
Moreover, an interface should
organise content so that the
relationship between elements
can be naturally understood.
Even though it’s not explicitly told to us, we see four
columns here (not two rows) due to the similarity principle;
types of shapes form groups.

2. Speak the user’s language
The language used in a user interface shouldn’t be based on the
technical language used by the system itself, but should instead be
based on the language used by users.
Using familiar metaphors is a good
way to achieve this.
Need to be aware that sometimes
this obscures important processes
(e.g. secure deletion)

3. Minimise memory load
Interfaces should allow users to recognise and work with existing
things, rather than having to remember things directly.
This happens subtly throughout many modern interfaces:
Leaving file names in place when renaming
allows us to add to the name, rather than
typing a modified name from scratch.
We take menus for granted, but they save us having to type in where we want
to go in a program directly.
Form descriptions reduce the burden of
remembering what data is acceptable, and
things like required units.

4. Consistency
The same information should be presented in the same location
within a system, and interactive elements should be formatted in the
same way to facilitate recognition.
Probably one of the most
important heuristics.
(How to break both these rules)

5. Feedback
A system should, via its interface, always inform the user about how
their actions are being interpreted, and, critically, about what the
machine itself is doing.
This is especially important when there are processing delays:
0.05 seconds* 0.5 second* >5 seconds*
Acceptable delay Noticeable delay Delay that requires
feedback
*adjusted from the original
source to account for
improvements in processing time

6. Clearly marked exits
Users are very likely to make errors when using an interface, and
mechanisms for recovering from those errors should be put in place.
Making these ‘exits’ visual also reduces memory load.

7. Shortcuts
Most of our heuristics relate to accommodating novice users, but we
should also accommodate expert users too. One way to do this is to
provide shortcuts.
A good example of a shortcut is code completion.

8. Good error messages
Error messages should follow four simple rules:
1. Phrased in clear language (as per heuristic 2)
2. Precise
3. Help the user solve the problem
4. Keep the user calm
Modern CLI tools can try and guess
what input you may have meant.

9. Prevent errors
There is not a need for error messages if errors can be prevented in
the first place. As discussed, while errors are, to some degree,
inevitable, steps can still be taken to reduce them.
Software that has different modes
is generally considered to be more
error prone because the user both
has to recall a command and
ensure they are in the right mode.

10. Help and documentation
Although our goal is to make a system that is useable enough that
additional help and guidance isn’t needed, in reality this may not be
the case, so supplementary documentation is often required.
At present, a majority of sophisticated
tools exist to generate (user)
documentation.
They are often built around a model of
documentation use by users, which
includes searching the documentation,
understanding it and finally applying that
understanding.

General design guidelines to usability principles
For consistency, we can (roughly) map each of these guidelines back
to one of the five usability principles.
1. Simple and
Natural
2. Speak the user’s
language
3. Minimise memory
load
4. Consistency 5. Feedback
6. Clearly
marked exits
7. Shortcuts 8. Good error
messages
9. Prevent
errors
10. Help and
documentation
Learnability, efficiency, memorability, errors and satisfaction
There’s an exercise on these waiting
in Lecture 20…

We will consider a specific UI development model which is called the
Usability Engineering Lifecycle.
This model has two distinct phases, the design phase, which is
covered in this lecture, and the evaluation phase, which is covered in
Lecture 20.
Design phase:
Participatory
design
Understanding
the user
Guidelines and
heuristics

Summary
Useable software doesn’t inhibit a user from completing tasks. In
healthcare, this means that software doesn’t hinder (or, conversely,
avoids errors in) the delivery of interventions.
Users are at the core of designing useable software, and they should
both be understood and involved in the design process, where
possible.
In the absence of user input or inherent expertise, design guidelines
or heuristics can help guide designers towards useable software.

References and Images
Enrico Coiera. Guide to Health Informatics (3rd ed.). CRC Press, 2015.
Jakob Nielsen. Usability Engineering. Morgan Kaufmann, 1993.
Bella Martin. Universal methods of design 100 ways to research complex problems, develop innovative ideas, and design
effective solutions. Rockport Publishers, 2012.
https://appleinsider.com/articles/19/06/30/the-worst-apple-designs-by-jony-ive-according-to-the-appleinsider-staff
https://readthedocs.org/
https://www.flaticon.com/
https://blog.schoolofcode.co.uk/shortcuts-how-i-gained-those-extra-10-seconds-929b6fe4cb53
https://www.macrumors.com/2017/10/03/amazon-alexa-messaging-calling-uk-germany/
https://www.rideto.com/blog/road-signs
https://www.educba.com/errors-in-excel/
https://www.excel-easy.com/vba/examples/debugging.html
https://www.forbes.com/sites/jackkelly/2022/11/21/tiktok-is-one-of-the-few-tech-companies-aggressively-hiring-could-
regulatory-scrutiny-impede-its-us-presence/

References and Images
https://indianexpress.com/article/parenting/learning/concept-based-learning-make-children-future-ready-5626611/
https://headtopics.com/us/how-to-learn-to-code-our-beginner-s-guide-to-coding-programming-36371972
https://code.visualstudio.com/docs/languages/typescript
https://news.mit.edu/2013/scratch-two-released-0514
https://www.dailyedge.ie/tea-drinkers-list-1108903-Oct2013/
https://www.worldatlas.com/articles/scandinavian-countries.html
https://uxdesign.cc/difference-between-co-design-participatory-design-df4376666816
http://t3.gstatic.com/images?q=tbn:ANd9GcSm4BIJ6nkfLBl8ml4qWaHbtvoza0_yZg7YgZpUxD0IaKYNGEfE
https://www.ferris.edu/it/howto/diskcleanup.htm
https://www.microsoft.com/en-gb/microsoft-teams/group-chat-software
https://blog.backslasher.net/copying-files-in-powershell-using-windows-explorer-ui.html
https://www.engadget.com/2012-07-10-vim-how-to.html
https://news.knowledia.com/US/en/articles/the-escape-artist-s-guide-to-quitting-vim-
52045eba1bf00e46a8f6981431dfa35ed3a7569b

Principles of Health Informatics: Usability of medical software

Recommended

Recommended

More Related Content

Similar to Principles of Health Informatics: Usability of medical software

Similar to Principles of Health Informatics: Usability of medical software (20)

More from Martin Chapman

More from Martin Chapman (20)

Recently uploaded

Recently uploaded (20)

Principles of Health Informatics: Usability of medical software