Feb 26 2013

Neuroscience of User Friendly

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.


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.


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.


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.

23 responses so far

23 thoughts on “Neuroscience of User Friendly”

  1. Bill Openthalt says:

    I’ve spent a lot of my productive life in software, and designed quite a few user interfaces myself (from paper forms to in-browser forms 🙂 ), and I agree with your approach to user friendly.

    All too often the interface design reflects commercial priorities, such as the redesign of the Office tools, which made a whole bunch of productive professionals suddenly almost computer-illiterate. I assume the ribbon worked for those who desgned it, but the “intuitiveness” of the Office interface came from familiarity, not inherent user-friendliness. This leads me to suggest “don’t fix what ain’t broken” to the list of user-friendly design concepts.

    Unless the users are part of the interface design, it will reflect the programmer’s understanding of the problem, which is often far removed from that of the user. I well remember a tragi-comical episode where the company decided to redevelop a terminal. The old terminal had a fast keyboard with a numeric keypad, six large function keys and nice, satisfying key travel and click. The operator listened to the customer, translated the request in a sequence of keystrokes (with the information in a particular order separated by asterisks), and pressed “Send”. It was fast, reliable, and the operators loved it — they also enjoyed their competence, as it took a while to become proficient. Cue in the company brass, who could not operate these terminals if their life depended on it, so when they decided on the design of the new terminal’s keyboard, they came up with a huge slab of colour-coded keys with no tactile or audible feedback, one color per function. The “improvement” was that the operators no longer needed to listen to a complete user request before pressing the keys, and this was going to make data entry much faster. It turned out these keyboards reduced operator performance to the performance of the executive, not vice versa. The need to look at the keyboard also gave the customers the impression the operator was not paying attention, so they waited for the operator to look up before formulating their request. Productivity dropped by half, employee motivation took a nose-dive, and management hailed the keyboard as a huge success because they could demonstrate it. The company no longer exists.

    In this case, the programmers (yours truly included) wrote a memo warning of some of these issues, only to be told the keyboard was already in production, and the gaps between the fields of the original design we commented on would be replaced with non-dedicated keys as this was cheaper to produce (and maybe the keys would come in handy).

    So the problem is not always the programmer, who often has no say in the design, or, for that matter, the tools they are to use (“we are doing this online banking program in XXXXXX because that’s what everyone uses”). Long live the professional manager (I undestand they also infest hospitals :)).

  2. decius says:

    I think the SGU Twitter account was hacked. It’s sending out spam links.

    SkepticsGuide ‏@SkepticsGuide
    Fastest way for processing fat off your body in 2 weeks http://bit.ly/XDmkM6

  3. dohashi says:

    One principle from UI design that might be interesting for you to look at is the idea of mental models. The basic idea is that users form a mental model of how the interface should work. When their mental model matches the interface, the interface becomes intuitive, when it doesn’t the interface is hard to use. To make an interface easy to learn, it has to present itself in such a way as to help the user form the correct mental model for the interface.


  4. skrile says:

    All UI designers should be made to sit, hand-cuffed and gagged, while a novice user tries to perform a simple representative task.

    And yes – I’m a UI designer (among other things).

  5. Murmur says:

    The problem is often that the ease of using something long term is not always really related to how easy it is to learn something, if anything there is an inverse relationship. As Bill’s example above, my experience as a lowly user has generally proven that simple and easy to learn UIs often suffer in the long term, where complicated UIs on first glance, often lead to easier long term use.

    The trick I would think, is designing a UI that is complicated enough so that it doesn’t scare off a first time user, but is also not so simple that long term use is damaged.

  6. Flail says:

    Bill – I enjoyed your example of the Ribbon interface with MS Office, as that is a change that made Office much easier for me to use. I was a novice user when the ribbon was introduced, and it exposed many options I simply never would have found otherwise. Options that I now use regularly and that enhance my productivity. The old menu based system was broke for novice users, and MS fixed it. The cost was that the users that had been using the old menu system for years were ticked off and had to retrain themselves.

    To your other point, its a damn shame that managers are so often the ones making interface decisions for the real end users. As someone that works in software development, I’d kill to be allowed to sit down with end users on a regular basis and have them try out interfaces and make suggestions. Unfortunately, end users don’t pay the bills, managers do.

  7. MWSletten says:


    You should consider adding “support” to your list. No software is ever perfect, and how the development team responds to user criticism is as important as any of the other factors you listed. Indeed, the development team’s response can largely determine how well a given program meets all other criteria.

  8. Don’t get me started on support. 🙂

    I agree, that is a huge issue as well.

    The simplicity vs complexity is one of those tradeoffs I referred to. I often seek out application options that are just as complex as I need them to be, but not more so. For example, in audio editing there is a range of choices. Some are really powerful and probably, once you get really good that them, are extremely usable. But they do far more than I need so it’s just not worth the investment in time.

    Brilliance in programming is coming up with tricks and methods for getting the best of both worlds – easy yet also powerful. This can be accomplished, for example, by building an application so that complexity can be added as an option for those who need it.

    Although – this creates another trade off. I am using an application that has lots of options for different ways of accomplishing tasks, but this causes complexity and confusion. I would almost prefer one good way of doing things, rather than several mediocre compromises in the name of options.

  9. Bill Openthalt says:

    Flail – nice to know the Ribbon works for you. I am not privvy to Microsofts UI (re)design process, and it could well be that their research concluded that for users without the early Windows/Office baggage (let alone for those who, like me, still punched Fortran statements on 80-column cards on an 029) the Ribbon does indeed lead to better knowledge of the product. I did have to support people who were completely lost when it was introduced, which didn’t lead to a favourable bias.

    That being said, the old Office menu system did “age-out” options that weren’t used often enough, so the interface, while commendably brief and clear, did not jog the user’s memory as a good GUI can and should do. This might explain why the Ribbon works better for you. If memory serves, this aging-out was introduced in Office 2003, and it was not well received.

  10. Murmur says:

    Steven said: “This can be accomplished, for example, by building an application so that complexity can be added as an option for those who need it. ”

    The World of Warcraft addon system is a good example of this. I have been told Unix is similar in that it can be customised to the roof, but my one daliance with it ended in complete frustration after a very short period; so I wouldn’t know personally.

    As for the ribbon system, after heavily using excel and access in the early 2000s I came back to it recently and after the initial “You murdered my darlings!” moment, I like it very much and find myself using functions I hadn’t used as often before, much like Flail.

  11. dkilmer says:

    I’m a software developer who for many years did UI work related to healthcare. I don’t disagree with any of your observations, but I don’t think the lack of awesome UIs should be cause for amazement. There are some inherent difficulties that make producing a great UI relatively improbable. Here are some:

    1. Generalizability. Many software applications are designed to serve a broad base of users, even within a narrow “vertical” market. And each lab/clinic/administrator has its own very specific set of procedures, workflow, etc. Often, the UI ends up being optimal for nobody because it’s trying to be acceptably usable for everybody. Your most common tasks are someone else’s least common ones. One lab considers the patient’s name to be critical while another uses some secondary identifier.

    2. Expertise. Programmers are experts in programming. But at best, they are going to be passable users of their own systems. Some of this mismatch can be mitigated by doing a *lot* of communication with users (which users don’t often have a lot of time for), but some of it is just the nature of software development — a programmer is never going to be as knowledgeable as the sum of all her knowledgeable users.

    3. Taste. This is a harder problem than most people realize. Given the principles stated above, there are still millions of possible ways of implementing the UI. And for any one implementation, you will find users that love it and users that absolutely hate it. Again, following good design principles helps, but when you find yourself saying, “Why in the name of Sweet Reason would someone put that option there?!?!?”, remember that some user somewhere else is probably saying, “Ooooh, yay! So convenient!”

    4. Multiplicity. To a programmer, it often seems that the user’s favorite word is “just”. They say, “Why don’t you just make that an option?”, or “Why don’t you just allow me to do this while doing that?”. Every configurable screen, every simultaneous activity, every option, adds complexity to the UI. And every increase in complexity makes changing the code slower and the appearance of bugs more likely. Again (again), this can be mitigated with really thoughtful design. But the tension between usability and internal complexity is a basic tension that can’t be completely resolved.

    5. Tools. This is not obvious to users, but the state of software development tools – especially for creating UIs – is not what you’d call “advanced”. Most tools focus on “widgets”, “components” and “containers”, and the highest available level of abstraction is “layouts”. There are really no tools that fully incorporate good design principles in a way that encourages good design practices. And when such tools exist, they are usually created in an ad-hoc way as in-house modules and practices.

  12. Bill Openthalt says:

    The Unix approach is procedural programming for everyone. Unfortunately, not everyone groks procedural programming.

  13. SARA says:

    @Murmur “The problem is often that the ease of using something long term is not always really related to how easy it is to learn something, if anything there is an inverse relationship. ”

    YES! I managed a group of users that went from an archaic black screen system that did not use a mouse, to a windows based click and type system. It took longer to teach someone to use the old system, but once they were up and running they moved through data entry work very very fast.

    In the new system they were slowed down so much, both by the inherently slower processing time of the system, but more importantly, switching between a mouse and a keyboard, and finally the spread of information from 2 pages to 8. And each page turn required a click.

    What is interesting is that using the mouse was not necessary in most of the instances that the processors chose to use it, but they were ingrained mouse users and so as soon as it was an option they would grab it even though hitting tab 2 or 3 times would be faster. They also preferred drop down menus when short cut keys had been programmed for them.

  14. Bronze Dog says:

    I did some GIS programming for my master’s thesis, and I’m currently learning Java, though right now I’m mostly learning good programming practices in the context of object-oriented programming. My thesis programming was pretty sloppy, but I was mostly focused on getting it to work in the first place. The user isn’t going to see that when they’re editing the garden map, though: Moving a plant works by click and drag. Couple tools to add or edit plants are a click and a windows form to enter its data.

    But another programmer would hate to modify my code, since everything is in everything else’s business, rather than made into self-contained objects. I may see if I can convince the GIS lab to reopen my account so I can tidy things up. I’m kind of rambling, but my point is that in addition to programming for the ease of users, you also have to program for the ease of other programmers to modify your code.

    Microsoft Office ribbon: It took me a while to get used to, but I’m glad it’s there, now. Lot of options I know about that I never used because they were buried in drop down menus.

    Support: Ugh, we all have our problems with poor support. I agree on the “problem with X” error messages that don’t direct you to X to fix it, give you the option to enable/disable X, or whatever it’s asking for. Even worse than that, I’ve seen unhelpful error messages that don’t even tell where the problem is or anything. Even an error number would at least give me something to put into a search engine. A particularly nasty version of that in Windows that annoys me to no end is essentially, “contact your system administrator to fix this unspecified error.” I am my system administrator. That doesn’t mean I know how to fix it or even what to fix.

    One other annoyance I have is when the help index won’t even acknowledge errors except the most basic ones, yet they have error messages for unusual problems that that pop up, necessitating searching the help index. Why don’t they go down the list of error messages that can be displayed and at least give the known/most common/most likely causes of those errors and include that in the help index?

  15. locutusbrg says:

    When it comes to EMR. I think that the programming needs to take a page from the IPAD system,( or android). People learn it quickly and you can add on increasingly sophisticated apps that are flexible to what you are doing. EMR are trying to serve too many masters. Legal, Billing, Government, security and Medical. In my humble non-programmer opinion it seems counter productive to cover all these aspects in one global software. Most of the systems I use are paying homage to the wrong priority. 1. Billing, 2.Legal, 3.information, 4. functionality. I lack the knowledge to implement this or even point out the shortfalls. There needs to be a baseline software that is shared by all. For example apple OS is different than android or windows. Yet it shares a lot o common UI points. Makes it easy to use and even easy to switch from one software to the other. There is nothing like that I have seen in EMR.

    From that standpoint maybe it is the purchasers(business managers) that are driving the useless aspect of the software.
    You could solve this like apple has done with the app market. Not the only answer but a good one.

  16. denisex says:

    It is unlikely the programmers that are the problem. Programmers these days are very commonly brought in after very detailed specifications have been written and signed off on and are therefore virtually written in concrete. Their job is to code what they have been handed, which has been written primarily by requirements analysts working with business users – who in this case should be doctors.

    The software design process is really hard. All the methodologies have severe drawbacks and limitations. There are usually too many people involved and the process is too inflexible, because making it flexible would make it too hard to manage and control. The focus is on controlling costs and meeting deadlines, everyone operating under intense pressure. Past the earliest phase, there just isn’t time to worry about improving the product; delivering something that’s good enough on time is all.

    I did software development for twenty-five years. The pendulum swung many times between the design being created by the developers and being created by the business community, with neither one being noticeably better than the other. User interface design ought really to be done by well trained specialists, but it rarely is. It ought to be a college major by itself.

  17. Bill Openthalt says:

    Re appstore: one also has to factor in the size of the potential market, and the size of the developer community. In the case of IOS and Android, there is a huge potential market, leading to thousands of developers, each trying to outdo each other. The vast majority of the apps has a lousy interface (especially those developed by large organisations), but there are so many in each category the best ones are pretty good.

    In small markets, all the developments have to come from the manufacturer. There is no incentive to improve the interface beyond the changes already decided for the next release. In addition, the actual implementation is often the only intellectual property of the firm. There is little documentation of the core functionality, the original developers are no longer available, and the current generation is scared to break the application when they fiddle with the core. The result is that they layer a richer, more complex application on top of the old one, and hope the new, faster processors will suffice to power their bloated monster. The sad thing is that this is not a new phenomenon.

  18. dogugotw says:

    So I pretend to be a developer at work. I came to development from a bit of an oblique angle so I’m not classically trained in either writing code or doing interface design. Some time back, I read about hiding everything not relevant ‘now’ from the user, ala
    “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.”

    GREAT idea so I started modifying my UI’s to do just that. FieldX depends on the value put into FieldY, hide X until Y is entered. Another example is to hide the ‘submit’ button until all the required information is entered AND to make it clear what info is required for the submit button to be valid. UI is cleaner, easier to see, nothing the user can’t do, no way for them to trip up and get confused! Yeah!!!!!!

    Turns out, users got confused. ‘Where’s the submit button’? ‘Why can’t I see FieldY?’.

    It turns out that successive disclosure is more complicated that I was lead to believe and ‘intuitive’ is hard to define.

    For the most part I fully embrace your concepts, especially the bits about talking to the end users. The art of any project is trying to find that person in the office around the corner, down the hall, who works on every 3rd Thursday who just happens to be THE power user…

  19. petrucio says:

    I’m speaking as both as programmer AND one that has worked on medicine software in the near past, and with it’s UI directly. I can confidently say that the state of the ‘user-friendlyness’ of the medical imaging software used at the time was attrocious. The software was being completely remade for the next version, and so it was a good opportunity for vast improvements in that area.

    But I gotta tell you – medics are one hell of a tough nut to crack – they HATE IT when you change something they’ve gotten used to. It’s like the MS Office problem on steroids. The more geeky medics like Novella liked the changes and adapted quickly, but in the end we had to implement a ‘legacy’ mode of operation, or a decent ammount of medics would refuse to change to the new version, which would increase support costs.

    And I mostly agree with everything you said, and when you said programmers would come here to defend their honor – for me at least is the contrary: I think most programmmers hate thinking about these problems and are HORRIBLE at thinking about the software from the user’s perspective. Often they don’t think this is their problem – good programmers should care about the software as a whole, not just about the programming parts; but these are hard to find.

  20. eiskrystal says:

    My pet peeves are pointless warnings…
    “Warning did you want to do that?”
    “Well I did click the button, is there a reason I didn’t want to. Perhaps in the next version you can update your warning to tell me.”


    When I hold my mouse over an icon with some random pictogram, it would be useful if it told me what the button does. Because the pictogram means nothing to me.

    Oh, and brick-thick icons that i don’t need that take up valuable vertical real estate. My first job in Word/Excel is to delete icons until I can actually see enough of the main screen to use it.

    …and don’t get me started on out of date tutorials. “Just click the button that we renamed and moved several versions ago”.

    I’ll stop now, before I start hyperventilating…

  21. eiskrystal says:

    Turns out, users got confused. ‘Where’s the submit button’? ‘Why can’t I see FieldY?’.

    Makes sense. Randomly hiding buttonsmeans that users can’t then see the process of activity as a whole. It’s disorientating. Like walking down a dark corridor with only a very small candle. It also means that as new boxes and buttons appear, they might make your layout jump about. I always try making them grayed out or having the next action graphically diminished in some way instead.

  22. One of the major issues I always seem to run into when doing human-computer-interaction studies or Human Factors studies, is that what people say they prefer and what actually helps them (improves their performance) are often two different things.

    A lot of times we just have to go forward with what we know works better even when people are protesting how much it sucks…until they get used to the idea and realize it’s helping (if indeed they ever come around). One of the more interesting quirks of humanity. We don’t actually know what’s good for us, even if we pretend that we do know and are adamant about it.

  23. norrisL says:

    Not sure if any of the prior comments make THIS comment, but the answer to the paragraph titled “Intuitive” is “go buy a mac”

Leave a Reply