User Interfaces (UI) facilitate the interaction between the user, and the software. They are a metaphor, providing a representation of the program designed for human use. A bad UI can make fantastic software useless, and a good UI can make a program an indispensable tool.
So when designing an interface, a question worth considering is,
What makes an interface good?
In his book "The best Interface is No Interface", designer Golden Krishna (2015) attempts to tackle this question head on. His point is that the user interface is a point of friction between the user and their goals. User's don't actually want to click, tap, or chat with an interface. They want to check their bank balance, communicate with friends, or find out if their patient is allergic to penicillin.
He also points out downsides of modern interfaces - they can be distracting, and addicting. The average smartphone user checks their phone 150 times a day. Doctors are also very conscious of distractions. Bryan for example, who I interviewed has his setup specifically organised to stay focused and on task.
Health is also a concern. Digital screens are essentially a giant lightbulb, and using a screen 8 hours a day is a well-documented cause of insomnia.
Krishna suggests a "NoUI" future, and discussed three principles to help get there.
By 'typical processes' he means the typical processes of the user. By paying acute attention to how the user functions, you can build an experience which works with the user. He gives the example of a product called 'Square' (Square Inc., 2011). Square provides a Point of Sale terminal for the shop assistant to complete transactions, allowing the user to pay via credit card - or their smartphone.
They have a feature called 'auto tab'. You as a user walk into your regular coffee shop. Your phone sends out a Bluetooth signal, informing the Barista that you are in the shop, and that the last ten visits you ordered a cappuccino. After you pick up your desired item, payment is automatically debited and your receipt is emailed to you.
Obviously you'd only use this feature at shops you regularly visit, but consider the change in experience.
When a task has to be repeated commonly, any way to reduce the steps involved is worthwhile. In this example, Square took it as far as possible, and completely removed the user's interaction with the interface.
Computers are incredible, able to process information significantly faster than humans ever could. However, as much as computers serve us - we also spent a lot of time serving them. If an interface is how software communicates to us, then we are the interface between the software and the world. We are essentially their senses - software knows nothing about the reality we live in, other than what we've told them. He argues that software should use digital senses as best as possible, to reduce the need for user input.
Software also creates "digital chores", tasks which the software requires us to do. Passwords to reset, notifications to attend to, files to sort, messages to archive, calendars to update - the digital maintenance of our lives. His argument is that good systems should remove chores, not create them.
Software is traditionally made for the average user - however, no user is average. Software however can adapt to individuals by learning about them. This provides incremental gains, but the more it learns the better it can serve you.
He gives the example of Nest (Nest Labs, 2011), a digital thermostat. It functions like any regular thermostat, you turn the temperature up and down as you please. However, it learns and notices common patterns - perhaps you always turn it up when you wake up at 7 am, perhaps you prefer a temperature of around 19 degrees. Eventually, the thermostat will manage itself.
I think interfaces for EHR systems need to have one key quality - adaptability, for three reasons:
As I explored in Storage, patient's have varying records. A newborn's record looks very different to an elderly cancer patient. And beyond that, what information in that record is relevant will depend on which medical professional is treating them. A doctor in an emergency room will be looking for very different information than an optometrist.
Karsh et al (2010), concluded that a user's needs of their software can change tremendously between clinical role, situation, environment, and institution. When I interviewed Bryan (A GP), he noted that while sharing a single record with other institutions would be useful, a lot of the information would be irrelevant to him - even if it's very relevant to another person treating the same patient.
Ultimately, the interface needs to be designed with context in mind - and therefore, the UI needs to be able to adapt to many different situations.
Designing a user interface to say, prescribe medications, may seem simple. But it's worth considering the impact - A GP could potentially have to prescribe medications 160 times a week. At that scale, it's worth considering efficiency, and safety. This requires constant redesigning, tweaking, and user feedback.
Optimisation is a long process, and requires many iterations, and adaptations of the interface. Having an interface designed for adaption would make the iteration loop of designing, building and then testing - much faster.
As demonstrated by Bryan's interview, GP's will go to great lengths to optimise and customise how they work. Bryan has his setup which he has designed for himself - but not every GP would want to work like that. They're all unique users, with unique preference as to how they should work.
If I as a designer, design a UI which cannot be changed at all, I am forcing my opinions of how to achieve a task onto my users. Ultimately, the design choices I make will affect how the end user will act, as noted by Karsh et al (2010).
"Users are inevitably and often unknowingly influenced by what many HIT designers might consider trivial design details—placement (information availability), font size (salience), information similarity and representativeness, perceived credibility (or authority)"
So, if I make design choices which are unchangeable by the end user, I am essentially forcing my opinion onto medical professionals - despite, not being one myself. Even if the interface is designed alongside a group of GPs, there are still edge cases. Some medical professionals have poor eyesight, some prefer using the mouse over keyboards, some couldn't get any work done without their keyboard shortcuts.
Users are individuals, and the UI must adapt to their unique workflows.
Adaptable interfaces aren't new - here are some examples.
Email is the worldwide standard for sending electronic mail. As users of email, it's accessible everywhere - on our computers, on our phones, and on our watches. While the functionality of email remains the same between platforms, email clients exist for almost any device connected to the internet.
Email was designed with a very clear separation between the server, and the client. The email server provides the functionality of storing and sending email, and the client provides an interface for the user.
This separation works well because anybody can create a new email client, and get users to try it out, without changing anything about the email server. Dislike the layout, want a new feature, want a workflow adapted for your smartphone? Go for it! This model of open opportunity to redesign the end user interface, means end users have a huge range of options.
Atom describes itself as "A hackable text editor for the 21st century". Atom is simply a text editor, designed for programmers. However, what makes it unique is how much users can change about it. Users can write 'packages' which change part of Atom - either simple changes to the interface appearance (such as increasing the font-size), to adding new functionality (such as automatic code checking). Users have customised Atom to provide almost any feature you could imagine - from controlling your Spotify music inside Atom, to specific workflow improvements such as Hey Pane. As of writing, there are 6,244 packages published, which any user can download and add to their editor.
This 'extensible' approach provides some benefits over the adaption of email clients. Firstly, if you just want to make a small change you don't have to start from scratch. In order to make a change to an email client, you have to build an entire email client from the start. Atom provides a simple way to make small changes, without affecting the majority of the software. Secondly, it lets users customise as much as they want. As not all users work the same, Atom's approach of mixing and matching packages means that any user can create a setup which works for them.
Similar approaches have been successful for other pieces of software, such as Chrome Browser Extensions, Sublime Text, or Sketch Plugins.
If interfaces can be adapted by their users down to the smallest detail, they run the risk of becoming inconsistent. If an adaption works in an unexpected way, they become confusing and hard to use - and by letting users customise them down to the smallest detail, you run this risk.
That's the issue design languages solve. A successful precedent is Apple's Human Interface Guidelines. This document describes a consistent look and feel, which all iOS apps must adhere to. It not only has aesthetic requirements, but design principles, and standard interactions. This creates consistency - a date picker will look and act the same in one app, to every other app. This helps make apps easy to use, any user can download and use a new app with limited or no instruction. This is because while the app is new to the user, the UI elements, and interactions, are not.
In order for an interface to cater to the large range of user needs in Healthcare, it must be adaptable. The best way to do this, is with an extensible interface, providing mix-and-match customisation. However, in order to maintain consistency, and therefore ease of use - a design language is required. This language is a set of design principles, interactions, UI elements, and aesthetic choices.