Feb 26 2013

Neuroscience of User Friendly

You are currently browsing comments. If you would like to return to the full story, you can read the full entry here: “Neuroscience of User Friendly”.

Share

23 responses so far

23 Responses to “Neuroscience of User Friendly”

  1. Bill Openthalton 26 Feb 2013 at 8:49 am

    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. deciuson 26 Feb 2013 at 9:05 am

    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. dohashion 26 Feb 2013 at 9:05 am

    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.

    http://www.nngroup.com/articles/mental-models/

  4. skrileon 26 Feb 2013 at 9:09 am

    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. Murmuron 26 Feb 2013 at 9:20 am

    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. Flailon 26 Feb 2013 at 9:37 am

    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. MWSlettenon 26 Feb 2013 at 9:51 am

    Steve,

    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. Steven Novellaon 26 Feb 2013 at 10:06 am

    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 Openthalton 26 Feb 2013 at 10:07 am

    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. Murmuron 26 Feb 2013 at 10:19 am

    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. dkilmeron 26 Feb 2013 at 11:22 am

    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 Openthalton 26 Feb 2013 at 11:42 am

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

  13. SARAon 26 Feb 2013 at 12:23 pm

    @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 Dogon 26 Feb 2013 at 12:26 pm

    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. locutusbrgon 26 Feb 2013 at 1:02 pm

    Steve
    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. denisexon 26 Feb 2013 at 5:13 pm

    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 Openthalton 26 Feb 2013 at 6:43 pm

    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. dogugotwon 26 Feb 2013 at 7:29 pm

    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. petrucioon 26 Feb 2013 at 9:59 pm

    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. eiskrystalon 27 Feb 2013 at 4:24 am

    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.”

    and

    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. eiskrystalon 27 Feb 2013 at 6:29 am

    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. The Other John Mcon 05 Mar 2013 at 7:40 am

    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. norrisLon 11 Mar 2013 at 1:01 am

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

Trackback URI | Comments RSS

Leave a Reply

You must be logged in to post a comment.