Some time ago I presented the design principles we use at Saxonia Systems (since 03/2020 ZEISS Digital Innovation) to design and develop user-friendly Software in a blog article. As part of the development of our Custom Usability Index, which can be used to measure the degree of usability of a software project, we as Usability Team took a closer look at those principles and extended them to 13 top categories, which contain multiple usability aspects each. In this article those categories and aspects are explained in more detail and illustrated with examples.
Effectivity: Reach the goal. (Principle 1)
The first and therefore most important rule is the observance of effectivity. An application should enable the user to work effectively by providing a suitable functionality for the completion of his task. The user is not overloaded with information and functions that are not necessary for his use case. Accordingly, dialogs should only contain relevant or frequently used information. Every additional information distracts the user from the important content and brings the risk of reducing relative visibility.
It is therefore necessary to answer the central question: What is the task to be supported? An in-depth analysis of workflows and their comprehension is the key to understand the tasks and goals of the users to be able to evaluate the efficiency of the implementation.
Efficiency: Reach the goal quickly. (Principle 2)
Particular attention also needs to be paid to the optimisation of efficiency. The user should be able to accomplish a task in minimal time. At the same time, the application requires only minimal time to react and execute an action. So, this principal refers to the speed of operation of both users and the system. Indications of users not being able to work efficiently are for example unsuitably used interface widgets, missing default values, misleading search results and high-resolution pictures requiring a fast internet connection.
Signs of low system efficiency, on the other hand, are delayed reactions to input in the form of a “shaking” cursor, slow interface widgets and missing feedback.
Controllability: The user has the power! (Principle 3)
The user has, regarding his authority within the system, control over all actions. He may cancel, pause, and resume actions at a later point in time. It is possible for him to revert an action and, as the case may be, start a new attempt if the result was not satisfactory. To control the application, the user still has the option of using alternative input devices to the mouse, such as keyboard, screen reader and Braille display, according to his personal requirements.
Not satisfying these points will lead to increased frustration for the user.
Customisability: Everything suits the user. (Principle 4)
The application should be flexible enough to support different approaches for the completion of a task. Additionally, the user can customize the system according to his previous experiences, culture and needs e.g. by changing font size, changing the default settings, and setting his own shortcuts. A good example for the consideration of customisability is the online platform http://www.elster.de/, which is used for web based registration and submission of tax returns. After logging in, the user is asked to which user group he belongs to, to better adapt to his needs afterwards.
Consistency: Everything fits together. (Principle 5)
The control of the application should comply with the expectations of the user in every aspect and needs to follow general conventions (platform, style guides, etc.). One part of it is the consistent usage of terms, icons, and layouts within the application and in product families. Process structures also follow a uniform principle. By maintaining consistency, the user can reuse a behaviour pattern once learned. When using an application for example, every user knows (or expects) to find the button to close a dialog window in the upper right corner. When switching to the operating system Mac OS X he has to completely readjust.
Evidence that an application does not behave as expected and consistently includes surprised to confused users and e.g. the use of different terms for one and the same function.
Design and layout: Comprehensible at first sight. (Principle 6)
This principle comprises every aspect of visual design of an application. According to that, the kind of aggregation, layout of the GUI elements and purposely used colours should support the user with recognising links. Information and components are generally presented to the user in such a way, that they can be noticed and that texts can be read easily. Indications of not satisfying this principle are e.g. no obvious correlation between labels and data fields, tiny fonts and low-contrast colours used for front- and background.
Language: Speak the user’s language. (Principle 7)
The application should basically be in line with the user’s language and way of thinking. Text elements should therefore be verbalized clearly and a for the audience understandable vocabulary should be used. Nevertheless, a lot of things are worded technical instead of using the user’s words. The “best” example for it are error reports with a high degree of detail, therefore valuable for the system developer, but not helpful for the user at all. To avoid this, an in-depth analysis of the user’s technical vocabulary is necessary.
Visibility: The user recognizes his possibilities. (Principle 8)
To guaranty the user’s ability to complete his task instead of becoming lost, he needs to know at any time, in which part of the application he is, which actions can be executed and how they are triggered. He also needs to know his system’s status at any time. That is why the main menu should display the user’s current position and e.g. comprehensibly show how to get there using a breadcrumb navigation. Relevant objects, functions and options should be visible to the user’s eye and enable him to find the desired klicks directly. He needs to be able to estimate the effects an action is going to have.
Feedback: The user is told what is going on. (Principle 9)
The system should react to the user’s input at any time and inform him about events actively. In case of an occurring error, a corresponding notification illustrates its reason and suggests a solution to the user if possible. Shortcomings of an application regarding feedback can for example be a missing spinner icon during complex operations. User inputs seem to be ignored by the system and the user experiences the application as “frozen”.
Learn supportive: Easily learnable. (Principle 10)
The system should support the user getting to know the interface and should encourage him to try previously undiscovered features without having negative effects on the user. Especially during first usage the user should be supported when performing complicated actions and limit possible missteps this way. At this point, short tutorials and explaining texts are helpful. A possibility for experimental learning would be a test mode, meaning a separated test section within the application, where all the functionalities can be tested without consequences. Using a test mode, the user is training using the system und learns dealing with it without having to completely execute the processes.
Help and documentation: Help, that helps. (Principle 11)
Help systems should be easily findable or embedded into the interaction. Embedded help is for example implemented by using tool tips, place holder, short help texts and assistants. Are those not sufficient, contextual help like a help panel, getting-started pages and a search function should be the choice. Note that a help system is only supporting the user when relating to the user’s task and listing specific steps to solve the problem.
Error tolerance: Forgive and avoid user errors. (Principle 12)
The system should be designed to save the user from mistakes from the beginning, for example by disabling invalid functions and describing the reason for the restriction. In case of happening anyway, the system should detect invalid inputs or actions. If they are unmistakable, the system can correct the mistakes on its own if possible. Are there multiple possibilities, alternative suggestions are shown. Under no circumstances errors may lead to data loss or even a system crash.
User experience (UX): The software feels good. (Principle 13)
One aspect not yet considered is the user experience (short UX). It results out of the complete experience of the user with the application and is made up of the actual usage, the user’s expectations, and the previous experiences with other systems. The application mediates a feeling of security and reliability, is fun to use and serves the purpose. The system excites the user by not only satisfying specific expectations, but also overshoot them. Principle 13 is mostly fulfilled by sticking to the principles listed above. A slow, inconsistent application with a lot of error messages and crashed will not contribute to the user’s satisfaction. That is why the software should be up to date with the current technology and should support the current control paradigms.
Conclusion
13 important principles for reaching user-friendly, satisfying software were presented in this blog article. Take note, that there is no such thing as the one and only user-friendly solution. How comfortable it is to use an application always depends on the specific use-case and the user group. This is why it is recommended to analyse the users‘ needs and involve them through user tests.
Additional literature
- J. Nielsen‘s 10 Usability Heuristiken (Web)
- B. Shneiderman: 8 Golden Rules of Interface Design, In: „Designing the User Interface: Strategies for Effective Human-Computer Interaction“ (Web)
- DIN-Norm EN ISO 9241-110: Grundsätze der Dialoggestaltung (Web)
- B. Tognazzini, Principles of Interaction Design (Web)
- J. Johnson, GUI Bloopers 2.0: Common User Interface Design Don‘ts and DOs, 2007
- D. Norman, The Design of Everyday Things: Revised and Expanded Edition, 2013
- Web Content Accessibility Guidelines 2.0 (Web)
This post was written by:
