I have been involved in assessing and implementing several medical informatics applications, as electronic medical records (EMR), expert systems, and other software applications are becoming more common in my field. For this reason I have had to explain to others specific details of what I mean by “user friendly.” I’m a nerd, so I just like becoming super reductionist about such things. It also occurred to me that there are some findings of neuroscience that are relevant to the question.

In colloquial terms “user friendly” means a software application that is easy to use. There are several aspects to ease of use, however. I am coming at this from the perspective of an experienced user, not a programmer, so consider this a (somewhat cranky) user’s guide to being user-friendly. The types of issues I list below are actually all related and interact with each other, but I find it helpful to consider them as distinct issues.

Intuitive

One aspect is often referred to as “intuitiveness.” An application is said to be intuitive if it is easy to figure out how to use it without specific instructions, reading the manual, or extensive prior specific knowledge. Functions should be labeled in plain language that makes their use obvious. Remember all the jokes about Windows users having to click the ‘Start’ button in order to shut down the computer?

Common tasks should be anticipated and made easy. This means I should not have to hunt through several layers of drop down menus to get to the function.

Applications should not be any more complicated than they absolutely have to be. If extra but little used functionality is desired, these should be options for advanced users but not get in the way of the most common use. Most extra bells and whistles should be turned off by default, so that experienced users can turn them on, but the average user won’t have to slog through them.

Efficient

Programmers should consider what tasks users might want to accomplish and how they can do so with the “fewest number of clicks.” This type of click efficiency is essential for applications (like an EMR) where the user may be performing the same tusk dozens or hundreds of times.

There are various ways to minimize clicks. Place the most used tasks or options on the top level interface, so that users do not have to go through menus to get to them. Avoid unnecessary confirmations, or at least make it easy for users to opt out of such confirmations. I would only require confirmations for events that cannot be reversed and would be significantly problematic if they were executed by accident.

Allow common activities to be done “on the fly” – meaning that they can be performed during the more basic task without changing screens or modes in some way.

Be Helpful, but Not Too Hepful

Many programs do what I call ‘hand holding” – they have “wizards’ or other tools that help users perform complex tasks by walking them through it. These are great. But they can get overwhelming and also become a hindrance if overused or not used properly.

For complex applications I tend to see “warning fatigue.” So many popups and warnings are occurring, and are roadblocks to my progress, that I end up clicking through them with less and less attention over time. This means I am likely to miss a warning I am really interested in.

Sometimes helpful hints are just one more roadblock to click through. One solution is to put such optional hand-holding off to the side and not make it a roadblock – something that stops my progress until I deal with it.

At other times I feel a complex program does not hold my hand in ways that I would like. For example, how many times has an application given you a non-specific warning, “There is a problem with X,” but it doesn’t tell you what exactly the problem is or how to fix it. Even better – if I really need to fix X before I can move on, why not take me there automatically and tell me exactly what I need to do (assuming the software cannot solve the problem by itself in the background). Sometimes I feel like, you obviously know what the problem is, so why not just fix it, or at least give me a button that takes me there and makes it as easy as possible.

The User Interface and Information Control

Recently this has been the biggest peeve of mine, and also one that is highly informed by neuroscience – thinking about how information is presented on the screen. There are some basic principles of design that I feel were worked out 20 years ago but still are flagrantly violated even by new applications.

Neuroscientists have widely documented a phenomenon known as interference – your performance on one cognitive task will be diminished by anything else that uses cognitive resources, even those that are not particularly demanding – extraneous sensory information, for example, or trying to multi-task. This is why it is unsafe to talk on the phone while driving.

A user interface should be designed, therefore, to minimize cognitive interference. This is especially true of applications that are meant to be used during some other task. When I am writing this blog I am doing nothing but writing this blog. When I am using an EMR, however, I am also engaged in the cognitively demanding task of relating to my patient and practicing medicine. Every bit of my brain that I have to spend navigating a piece of software interferes with the very tasks that software is supposed to be supporting.

Related to this, there is other research that demonstrates that extraneous information causes interference and reduces performance.

What this means in practical terms is that an optimized user interface should have on screen only the information that is currently needed by the user, such as the specific task in which they are engaged and essential navigational control. I should not have to hunt through a tangle of information to find the bits that are important to my current task.

In addition, information should be formatted and organized in such a way that my eye should be drawn to critical information and should scan easily to find information or controls for which I am looking. There are many tools to help with this – bolding, font size, and placement of information on the screen.

For example, when I am reading a radiology report I am always interested in two critical pieces of demographic information – the patient’s name and the date of the study. I don’t care as much about the patient’s medical record number, the name of reading radiologist, and other details. It’s all important and needs to be there, but I want the most important information to be bold, in the upper left hand corner or otherwise easy to locate. I hate hunting around a report for a piece of information that should be prominent.

During a recent talk on video production (to help with some web videos we are making) I learned that good directors/editors will often make sure that the action of one scene occurs in the same place on the screen as the beginning action of the next scene. Therefore the viewers eyes will immediately be where the director wants, and the viewer won’t have to hunt around the screen to find the action. This leads to an enjoyable and more powerful movie experience, even if you don’t realize exactly why.

The same is true of information on a software application – the programmer should think about how the user is going to be using the software, and always, for example, placing the same kind of information in the same location on the screen.

How the information is presented also influences how easy it is to interact with (not just find) that information. When I am trying to rapidly click through a long series of choices in order to document information, where I need to click should not be jumping all over the screen. Also, the same type of choices should be in the same relative position. For example the choice that is equivalent to the “normal” or default choice should always be the top or first choice on a drop down menu, and should not be jumping around in relative position.

The Application Works for Me

Finally, I would like programmers to remember that the application is supposed to be working for me – I do not work for it. Often I find that I am jumping through hoops to meet the needs of the application, rather than the application performing functions that are designed to help me complete my task. I know that sometimes tasks simply need to be performed by the user, but sometimes the user is used as a solution to a need that the software can and should be meeting on its own, or least with minimal inconvenience to the user.

Conclusion

A lot of what I said may sound like common sense, but it is amazing to me how often these principles are violated, simply because they were not considered, or because they were not prioritized. Sometimes there are unavoidable trade-offs, but that should be viewed as a challenge to the programmers, not an excuse for laziness.

I am not ignoring or underestimating the complexity and difficulty in crafting a software application. I suspect the comments will attract programmers who wish to defend the honor of their craft. I am not impugning all programmers – I know enough of them personally to understand the challenges they face. I also have used excellent applications that are elegant and intuitive in their design and functionality. I know that users have their issues as well, and that the programmer-user relationship is a two-way street.

What I have been discussing, however, is my experience (that of a neuroscientist and experienced user) when applications fail.

Perhaps what is needed is a checklist (ala the Checklist Manifesto) for programmers to remind them to specifically analyze their software for the above features (and others, as mine is sure to be an incomplete list). I suspect such lists exist in programming books and manuals, but I do have the urge to post such a list right above the computers of those programmers who are responsible for some pieces of software I am forced to use.