In online discussions around digital clinical systems there are some evergreen positions that have recently resurfaced...
Why can't my EPR be just like my Apple/Google/Other product. These "just work" and don't need to be taught to users...
Any clinical system that needs users to be trained is too complex and shouldn't be used...
Whilst I understand the system frustrations that generate these opinions, I really don't think they are helpful. The abstract notion of perfect usability being an absolute requirement lessens the value of incremental progress and sets such an unachievable goal that there is a risk of devaluing any improvements made along the way. As an early disclaimer, there are clearly people able to better articulate the detail of these issues (@thmswebb is 100% worth a follow). However, these are some thoughts which I hope helps to explain my view and and offer something more constructive in the debate.
Issue 1: Healthcare is delivered in a complex adaptive system
Complex adaptive systems have three key characteristics:
- The people within the system can all differ in their approach to decision making and these approaches can change over time
- People working within the system interact with each other which creates...
- Emergent properties of the system ie. For given inputs, the outputs can (and will) vary over time
If we fail to appreciate this complexity we become vulnerable to consequences that have not been considered. These can be potentially disastrous. This risk is enhanced by our love of linking cause and effect, typically from a position of retrospect, without a full appreciation of the surrounding issues.
Appreciating and embracing this complexity is critical to understand problems at the level where they can be solved, avoid reflex responses, and to make choices that benefit multiple stakeholders.
An iPhone or similar device is fundamentally a piece of consumer technology that needs to meet the needs of a single user and has the opportunity to define what outputs that user can achieve.
Issue 2: Expert staff need autonomy (and patients need them to have it)
Do we want digital systems to be an enabling tool to support our activities, or an implementation tool that tells us how to work? The reductio ad absurdum for a system that needs no training is one that removes all decision making ability from the user. For this to be efficient we need to be certain that we can map all clinical scenarios and all patient needs (spoiler, we can't). Systems that allow users to meet the needs of anticipated and unanticipated edge cases will always need training. There's a reason that the cockpit of an A320 looks complicated and requires pilots to undertake training and retraining.
From a psychology perspective, autonomy is only one part of the basic needs that form the self-determination theory. Our systems also need to allow relatedness to support connections with others, and competence (we can gain satisfaction from a feeling of developing mastery over something that initially feels like an overwhelming challenge). From a design perspective these needs must be reflected:
- Design must allow users to have control to allow for a feeling of autonomy
- Relatedness can be created by avoiding unrelated or unhelpful messages and prompts and by allowing users to be understood in the manner that they choose, not how the system defines
- Competence can be created through better training within systems with pull revelations that show contextual, task relevant information being the gold standard.
Issue 3: Not every Apple / Google product is perfect
I type this from the perspective of someone deep in the ecosystem. However, not every piece of Apple software is equally successful. Yes the global navigation on early iPhones was a triumph of simplicity (though the removal of the home button removed some of the intuitive design and did need users to be re-taught). However, there is a huge amount of valid critique of iTunes/Music for poor design.
Here, an important driver is the fact that this product tries to meet the needs of two very different groups: firstly, those who have collected, curated and organised music collections in any format over their lifetimes and want their digital experience to mirror this; and secondly those who are more casual listeners and more orientated towards streaming. This creates complexity which creates compromise which impacts usability.
Issue 4: Apple still offers training
Great, you've had iPhones of various generations for the last 10 years and have spent this time getting so comfy with it that you can't imagine the interface ever not feeling natural. You've incrementally learned new features over multiple iterations of iOS (not all at once).
Like it or not, that is a position of experience and privilege. No matter how easy you, I or anyone else thinks something is, other people won't have the same experience. If you think everyone can pick up an iPhone and immediately use it to it's full potential, you're wrong. I know that and, more importantly, so does Apple, which is why they offer free training to anyone who buys a new iPhone Don't let your own competence diminish the learning needs of others.
Irrespective of the issues above, the idea that we can, should and indeed must improve the usability of digital health tools is still correct. Doing this means recognising there are design and configuration opportunities as well as training opportunities.
Opportunity 1: Correlation is not causation and usability is not just simplicity
Clinical staff generally feel happy with the concept that correlation does not mean causation. We need to help people get comfy with a similar view, that simple does not necessarily mean usable. Usability has many domains: navigation, familiarity, consistency, feedback, visual clarity, flexibility, efficiency (and I'm sure there are more). Our focus must be usable - get this right and the appropriate level of simplicity will follow.
Opportunity 2: Beware the Merchants of Complexity
Coined by David Heinemeier Hansson, this phase was first used to describe external agencies selling cutting edge solutions that promise to solve every problem but fail because they simply cannot be implemented.
A modern digital team should help avoid this trap, not guide organisations into it. We must be honest with how much complexity staff, application managers teams, interface leads etc. are capable of absorbing. Digital teams should advocate for the right level of complexity at the right time and help organisations earn their complexity as staff skills evolve.
If we accept that the right amount of technology required to solve a problem is the least amount, then the same mantra should be applied to complexity and simplicity. Good design will make complex tools as easy to use, accessible and as safe as possible - it won't solve all problems for everyone all the time, nor will it remove all complexity. If is false equivalence to believe that just because a tool or system is not a perfect fit for your (changing) needs 100% of the time that this means it is poorly designed.
Opportunity 3: Spend more time on user testing
I like (actually love) the concept of two broad themes of usability issues:
- Perceptual issues "I didn't know what button to press" or "I couldn't work out how to xyz". These issues should be identified in early design tests.
- Domain based issues "In my workflow I actually needed to go from A->D then back to B ignoring C because appropriate clinical reason". These problems are about designs that don't have perceptual issues, but still don't work for the people using them. These issues are more complex.
Testing needs to make sure the jobs that people are doing within the system are considered. This means more upfront engagement and discussion and post go-live feedback loops. There is more and more talk of the value of design thinking in healthcare - domain based problems are a great example of why this is so important. Understanding the problems, process and outcomes before the solution is defined reduces the risk of these problems impacting people in a real-world environment.
Opportunity 4: Liberate data and users from monolithic solutions
A system that tries to be everything to all users will never be able to deliver the level of experience, flow and intuition that users want. I practice in a sub-specialist field and understand that my niche requirements are unlikely to impact buying decisions and therefore are even less likely to impact development plans. However, moving towards the next generation of EPR and embracing a digital ecosystem with a separate data layer will be a critical lever in making it viable to build systems to fit these edge cases. Separation of data from application can allow developers to deliver solutions that optimally address specific clinical issues without losing the value of a holistic record. This will increase the likelihood of a solution that 'just works' being delivered.
As a closing note... None of this means we should stop trying to improve usability. All of this means that we need to remember that usability is not a synonym for simplicity.
None of this means progress should be devalued for not delivering perfection. All of this means that we need progress towards a more appropriate digital architecture.
I'm sure I've missed some topics and failed to appreciate the depth others. However, I genuinely hope that this drives some thoughts about how we can make a case for better.