This page lists design guideline suggestions backed by logical reasoning that has often been proven in usability studies. Many GUI designers either ignore or don’t know about many of these basic rules that should probably be common sense.
- Make it “Easy to Learn” and “Easy to use”
- Always label buttons with text by default
- Enable theme capabilities and system theme integration
- Enable customizable interaction methods
- Avoid splash screens at startup
Human-Computer User Interfaces in General
-
Make it “Easy to Learn” and “Easy to use”
What’s the difference?
There are two basic approaches to usability within software user interfaces. Some designers only cater to one or the other, while some cater to neither and some just try to make it look ok without any regard for usability at all. Ideally, you need to provide an “easy to learn” and “easy to use” interface.
An “easy to learn” interface would be that which is very obvious to the user. He or she should instantly know what the interface is capable of and what every possible interaction is going to achieve. In general, you can make a user interface “easy to learn” simply by labeling buttons with text that the user already knows how to read and clearly explains what each button is going to do. It’s easy for interface designers to assume that everyone will understand the UI as easily as the creator, but this is rarely the case. Also see “Always label buttons with text by default.”
An “easy to use” interface would be something that is designed for speed and efficiency. Primary tasks would take very few interactions and would reduce the amount of kinetic energy needed to carry them out. Attributes of “easy to use” interfaces would include placing buttons where they can be activated with the least amount of movement and effort. For example, with a command line interface, a user can have both hands on the keyboard, quickly type a series of commands with very little effort and movement of the fingers, then press “enter” and be done. The computer carries out the commands right away. This is “easy to use” in that it’s very efficient, but it is not “easy to learn” if the user does not know the syntax of the commands required to carry out the intended functions.
How do you do both?
This may sound like a complicated question, but really it’s pretty easy. First of all, prioritize an “easy to learn” interface and consistency with the rest of the system. Software functions should always be as instantly obvious to new users as possible. Otherwise new users won’t use it. You can use consistency to make functions easier to understand. For example, all scrollbars within the system should look and function the same way. All menu buttons should look and function the same way. All keyboard shortcuts should be listed and visible in the same way. All application windows should look and function in the same way. This sounds obvious, but unfortunately many software designers ignore these advantages that are brought about through consistency within the system.
The default “easy to learn” interface should cater to the most average use case scenarios as determined by usability studies or other data metrics.
Now to add in the “easy to use” capabilities, we’ve got to make the UI customizable. Every user may have different priority tasks within your software. If my priority tasks are buried beneath 3 layers of menus, that’s not going to be easy to use or efficient at all. You need to enable the surfacing and prioritizing of most-used functions for each user. This can be done with intelligent user interface designs, but it’s probably best to allow the user to opt-in to customizing the interface herself for her own specific use case scenarios… especially considering good UI designs are so rare these days, it’s difficult to imagine good “intelligent UI’s” to evolve any time soon.
Also see:
-
Always label buttons with text by default
Why?
Users don’t immediately understand ambiguous icon designs that are not already part of their learned language. Forcing users to learn something that could have been communicated with words that they already understand and learned in school is a barrier to entry and a waste of cognitive energy. This has been shown to be true in many usability studies over the decades yet software designers continue to ignore this.
Arguments
Some say that icons are better than text since they don’t pertain to any particular language and people can learn them no matter what their primary language is after repeated use. This is true if repeated use ever occurs, and that’s a big “if”. By littering a user interface with unintelligible icons, you make it so nobody except the designer understands the interface without fairly extensive training and trial-and-error figuring-out. Furthermore, there is no dictionary or structured method of translating these made-up non-standard icons into functions or words that users actually understand.
Another argument is that the icon-based interface design looks cleaner without all of the text labels. That’s also true, but do you want people to just look at your interface or do you want people to use it? Having an understandable interface means people will be much more likely to be able to use it without spending time and cognitive energy on training. -
Also see:
- Yes, icons need text labels
- The Importance Of Labels
- The best icon is a text label
- Icon usability
- Do icons need labels?
- The Obvious UI is Often the Best UI
- Introduction to Mystery Meat Navigation
In the context of hamburger buttons:
The reason we call them hamburger buttons is as an insult to the designer’s inability to clearly communicate the function of the interactive element.
- What’s wrong with the hamburger button?
- Kill the hamburger before the hamburger kills you
- A button that has the word “menu” is clicked 20% more than a hamburger button
- The hamburger is bad for you
- Why and how to avoid hamburger menus
- Apple says don’t use hamburger menus on iOS
- Time Magazine had to launch a tutorial pop-up explaining the hamburger menu
- Why we banished the hamburger menu
- Hamburger buttons could be costing you half of your user engagement
- 3 Good Reasons Why You Might Want to Remove that Hamburger Menu from Your Product
- Hamburger Menus and Hidden Navigation Hurt UX Metrics
- 5 Reasons to Avoid the Desktop Hamburger Menu Icon (It really should be avoided on mobile too for the same reasons though.)
-
Enable theme capabilities and system theme integration
Why?
Graphic user interface design trends change periodically as do the preferences of individual users. Users always prefer a consistent system-wide interface as this increases cognitive ease when performing tasks. Your user interface relevance will have more longevity if it follows the system theme and it will be easier to learn if it’s consistent with the rest of the system.
Arguments
Laziness, budget restraints, and time restraints are often some reasons to skip out on theme capabilities. Some companies want their specific apps to have their own unique “branding” that separates it from the system as a whole, but this is generally not user-friendly since it causes distractions, causes inconsistencies, and increases cognitive energy load.
Also see:
-
Enable customizable interaction methods
Why?
Many GUI designers target one specific usage scenario and optimize the interface for these “most common” tasks instead of offering the user a choice to make their particular usage scenarios more efficient. All user interface designs should have a consistent method of customizing controls throughout the system. This is especially important on mobile apps used on devices with smaller screens and thus less room for showing interactive controls. If I never use the “delete” button in an email program, I should be able to replace it with a more-useful command that I do use more frequently. Most professional-level programs on desktops already include customization options for users to taylor the software to their needs. This is not true at all on mobile apps even though UI customization on mobile apps is probably much more useful.
Arguments
Adding customization options increases the complexity of the software and it’s more work to implement. The majority of normal users don’t learn to customize an application’s user interface because they are already spending enough cognitive energy trying to figure out the default user interface.
-
Avoid splash screens at startup
Why?
In almost all cases, a splash screen that shows the program’s logo for a couple seconds is useless to the user. We already know which program we’re launching, because we activated its icon intentionally. The only thing the splash screen does (from a user perspective) is slow down her ability to actually use the program she is trying to use.
Don’t waste users’ time for branding self indulgence.
Very often we see splash screens that show nothing but an application icon full screen/window. Sometimes we see splash screens that show copyright information and version numbers. That’s slightly more useful, but if you can’t make the application launch right away when the user activates it, then give that information to the user so they know. If your software actually needs a few seconds to load the real user interface, show us a progress bar or other type of progressive animation or actual text information so that we can tell it’s doing something.
Which is the best user experience of the following:
- Your spouse leaves without saying anything to you?
- Your spouse says, “I’m going out to get milk” and then leaves?
- Your spouse says, “I’m going out to get milk and I’ll be back in 20 minutes.”, leaves, and comes back in 20 minutes?
Arguments
Perhaps the useless splash screens mask loading functions that the software has to perform before it can display the actual user interface, and that’s a valid reason, but you can make this much more informative by actually telling the user what is happening instead of being vague and uncommunicative about it.
-
Show and implement Keyboard access keys in the GUI when a keyboard is available
Why?
During the 1990’s boom for desktop personal computing, almost all software programs implemented access keys and keyboard shortcuts in a consistent, easy-to-use manner. On Windows, the Alt key would activate keyboard access for GUI menus and then typing a corresponding letter on the keyboard would activate that menu command. You could easily see which letter you needed to type because it was underlined. This keyboard access interface made it extremely easy to access GUI commands without moving your hands away from the keyboard AND without having to memorize command line interface syntax. You could also easily build motor memory for activating specific functions again without having to use a pointing device. Learning this one “underlined letter” concept for keyboard access to menus and commands meant you could use practically every program more efficiently.
Today, that simple & consistent visual cue for keyboard access in all programs has greatly been lost and that’s a huge detriment to “easy to use” and “easy to learn” usability aspects.
There are Android devices and Apple iPad OS tablets that now support keyboards, but navigating them using a keyboard is very difficult, and that’s bad design.
Arguments
Many software development kits on different platforms probably don’t have a built-in simple way of implementing keyboard access keys and shortcuts, therefore it’s too much work to do it right.
-
Good design should be more important
Why?
For most software developers, good design is not a priority. That’s why we’re stuck with so many poorly designed programs. Making these programs both easier to learn and easier to use will reduce cognitive load when using them and increase the desire to use them.
Arguments
Bad design in software doesn’t really hurt anyone. It’s not like bad environmental design where an unintelligible sign could confuse someone and point them down a path that can be physically dangerous… or bad weapons design where an ambiguous button could mean death.
One comment