Usability themes in software design

Over twelve years ago, I conducted my first usability test in open source software. This had not been closely examined by usability researchers, with a few notable exceptions including the GNOME usability test sponsored by Sun Microsystems (2001) and several usability tests performed by Nichols and Twidale a few years later.

I remained active in examining the usability of open source software for many years later, and conducted independent usability tests, partnered with open source projects in usability testing, and mentoring others for usability testing in open source software. Over the years, I have identified several usability themes. While these themes come from my work with open source software, they are generally applicable to all software interfaces.

1. Familiar design

An important challenge in any software interface, whether it is for a desktop app, a mobile app, web app - open source or proprietary - is how familiar the interface “feels” to its users.

For example, in my first usability tests with GNOME, we found that GNOME is dissimilar from Mac or Windows, so everyone had to learn how to use GNOME the first time they used it. If you aren’t familiar with GNOME, it is a graphical desktop system; just like Windows is a desktop and Mac is a desktop, GNOME is a desktop for computers running Linux. GNOME has made huge strides in improving the usability of its desktop environment, and continues to improve. But users who had not experienced GNOME before still found it unfamiliar.

Because Mac and Windows are the only options in mainstream computing, users have essentially been “trained” to use these desktops since they were old enough to use a computer. And because the GNOME desktop operates differently from Mac or Windows, testers were frustrated when attempting certain tasks such as changing a default font for an application.

The most serious difference was in how GNOME manages the desktop itself. When asked to create a shortcut to a frequently used folder, many testers first attempted to drag the folder to the desktop. Mac and Windows support placing items on the desktop; GNOME does not.

2. Consistent experience

Users also expect software to act the same across different areas of the software. This theme of consistent behavior was very important to testers. One positive comment in testing is that because all software programs looked and acted very similarly to each other, they were able to apply user interface experience from one program to another. Several testers also reflected that subsequent tasks were easier to perform than earlier tasks because they had developed some level of familiarity due to the consistent experience.

3. Menu clarity

Unlike Mac and Windows, GNOME uses the window “title bar” for other program actions, such as navigation in the file manager or accessing settings via a “gear” menu icon. While testers were initially confused about how to use the GNOME interface due to this difference, most eventually inferred how to use it through trial and error.

Interestingly, many testers associated the black “top bar” on the GNOME desktop to be a separate kind of menu. These participants often attempted to find application features such as “open a file” or “save a file” under the “Activities” menu button in the top bar, despite this menu being reserved for GNOME desktop actions like starting new applications.

4. Obvious results

One theme that remains consistent in usability testing is that if the program does not provide obvious feedback that an action has occurred, users may not realize it has happened.

One recurring example is the “find and replace” feature in many text editors. When testers are asked to change one word or phrase into a different word or phrase in a long document, almost all testers looked for a “find and replace” function. Despite successfully using “find and replace” to change every occurrence in a file, many users believed they had not completed the task because the editor did not explicitly tell them that the changes were made.

5. Visual relationships

In many usability tests, testers relied on the arrangement of icons and other user interface elements to help them complete actions. Testers were confused when buttons and menus were quite distant from the actions they affected.

For example, in early testing from around 2014, the GNOME Software application (essentially an “app store” for GNOME) used an odd arrangement to display information about programs that users could install. In the middle of the screen, GNOME Software showed a large screenshot of the application. Next to the image, Software included the application name, description, license information, and link to the original website. Many testers were unable to find the “Install” button, which was actually located in the upper-right of the window, displayed as part of the “top bar.” GNOME has since redesigned the Software app, making the “Install” button more obvious.

Icons were another challenge. Icons represent concepts and ideas, but these often depend on how the user interprets them. When icons are more concrete to represent a thing or action, such as an icon of a printer to indicate a “Print” action, users are able to successfully perform these tasks. But when icons are more abstract, they become more difficult for users to understand.

Carry these themes into your designs

Familiar design, consistent experience, menu clarity, obvious results, and visual relationships are important themes in software usability. While these themes were found through research in open source software, they are immediately applicable to other software interfaces such as web apps.

Learn from these usability lessons rather than rediscover them. In my experience in usability testing with open source software, I recommend developers should leverage existing software design patterns and remain consistent with other applications on the same platform. Programs should use clearly labeled menus and easily recognizable icons. Finally, the program’s design must provide an obvious response to actions, especially if that result should indicate a failure.