|Human Performance at the Computer – Part 1: Introduction|
|Human Performance at the Computer – Part 2: Making Applications More Rsponsive|
|Human Performance at the Computer – Part 3: Perceived Performance|
|The Three Pillars of Human Performance at the Computer – Which One Fits Best?|
|Performance – Merely a Technical Problem?|
|Waiting at the Computer: Busy Indicators and System Feedback – Part 1|
|Waiting at the Computer: Busy Indicators and System Feedback – Part 2|
|Waiting at the Computer: Busy Indicators and System Feedback – Part 3|
|Research-Based Web Design & Usability Guidelines|
|GUI Bloopers checklist (PDF version)|
By Gerd Waloszek, SAP User Experience, SAP AG – October 14, 2008; updated: October 12, 2010
In this series of four articles I would like to investigate the topic of human performance at the computer, introduce new insights, and discuss performance-related issues that can be addressed by UI designers – including the concept of perceived performance. In this article, I would like to focus on the aspect of improving the users' performance. In the following, I will point out that user interface design plays a critical role in this endeavor, and I will propose to establish "performance-oriented" guidelines, which support UI designers and help them improve the user's performance – or, at least, prevent them from degrading it.
Probably everybody is aware of the fact that the user interface design of a software application has an impact on the user's performance. Just think of replacing all letters in screen texts with Xs: Nobody would be able to use such an application successfully. That's trivial, of course. Not so trivial, however, is to find out which design aspects influence the users' performance either positively or negatively. Therefore, designers need guidance for creating software applications that can be used efficiently, but what can guide their design activities? From my experience, I found that there are two major guides for UI designers: imitation and guidelines (or standards). I am still convinced that most software applications are designed without designers explicitly reading guidelines – they just imitate existing screens, applications, or Web pages. On the other hand, these designs are also created according to some implicit guidelines, borrowed from the imitated software (maybe several software generations back). In the end, we arrive at guidelines either way, and that's what I eventually want to point out.
Software is developed according to some user interface guidelines, be they platform-specific, company-specific, or general; often several layers of guidelines have to be observed. However, if you take a closer look at such guidelines, you will rarely find that they cover performance issues explicitly. Typically, they are structured like grammar, telling designers how to use certain user interface components, how to put the pieces together, what to do, and what not to do. But none of the UI guidelines that I have encountered were explicitly devoted to user performance, or provided any justifications for why the "grammar" described in the guidelines was as it was. What is really needed to improve the users' performance at the computer are performance-oriented guidelines, guidelines that put user performance aspects first and provide reasons for the existence of the rules. Such guidelines are not intended to replace the existing "grammar-like" UI guidelines. They can be regarded as high-level or "meta" guidelines against which current UI guidelines can be checked. In the case of contradictions, the current UI guidelines can either be modified to conform to the performance-oriented guidelines, or the designers decide deliberately to override the meta guidelines for technical, consistency, or other reasons.
Do we have to invent such performance-oriented guidelines from scratch? Not at all. There are guidelines out there, which already cover a multitude of performance aspects – you just need to collect them und put them into a coherent framework. For example, the Research-Based Web Design & Usability Guidelines of the U.S. Department of Health and Human Services provide a good starting point for performance-oriented guidelines. They also have the huge advantage of being backed up by literature – there is no need to engage in debates about them. At a first look, it seemed to me that only a few rules were directly related to performance issues. At a closer look, however, many more rules proved relevant in the context of user performance. Another useful source for performance-oriented guidelines are the GUI Bloopers that Jeff Johnson (2007, 2000) collected and described in his books. Although these are formulated as negative examples, they can be reformulated and used as guidelines.
In retrospect, it was interesting for me to realize how a distinction that I made fairly early in my involvement in performance issues (see Performance – Merely A Technical Problem?), shifted in importance and finally found its place in an unexpected area: I realized that the factors that I had identified as influences on performance are not so useful for attacking technical performance issues. However, they enable you to organize recommendations or guidelines, which can lead user interface design in the direction of better human performance. These factors can act as organizing principles for some future performance-oriented guidelines and are:
A design tidbit article is not the right place for presenting long lists of proposed guidelines. It can only stimulate the awareness for the topic of performance-oriented guidelines and provide some hints on what these might look like and on which foundations we might build. In the following, I will briefly discuss each of the above-mentioned influence factors and present a few examples of possible performance-oriented guidelines. Also note that rules may be relevant for more than one factor.
Guidelines in this section are not so much targeted at UI designers but more at developers and other technical people. One should also note that there will be rules that cannot be adhered to simply because of the restrictions of the technical framework that is being used. I am also aware of the fact that many technically-oriented colleagues know these guidelines well and try to follow them.
Many delays are caused by technical characteristics of the platform on which a software application is running. Server roundtrips, screen refreshes, and page reloads are examples of such technically-caused delays, and performance-oriented guidelines would recommend to avoid these. A related recommendation would be to store data at the front end in order to avoid server roundtrips and to enable faster human-computer interaction. However, such recommendations have their limits, making decisions for one solution or the other hard. For example, data sets may be too large to be stored at the front end.
An important recommendation in this area is to keep and restore the users' work context. For example, it is tedious if users operate on list elements, which are distributed over several pages, and are returned to the beginning of the list after each operation on a list element. This is annoying for the users because they may have to step back to the original position in the list in order to verify the results of their actions. Here, too, technical restrictions may, however, prevent a satisfying solution.
Rule 1: Avoid server roundtrips.
Reason: Server roundtrips slow users down because a roundtrip causes a delay that can last several seconds, sometimes even longer.
Example: Reloading a page after a minor change in the UI.
Rule 2: Keep the user's work context or restore
it after operations that destroyed it.
Reason: If the work context is destroyed, users need time to re-orientate and return to the screen element that they were working on.
Example: Returning users to the beginning of a list (and the first page if the list stretches over several pages) after an operation on a list element.
In this section we look for guidelines that help to improve the human-computer interaction within the restrictions of the given technical framework. Interestingly, the first guideline that comes to my mind, is the recommendation to conform to guidelines. That sounds self-evident but it is not, as I repeatedly found during my professional life. A typical example of this attitude is that developers or UI designers misuse controls or icons. Sometimes they do so according to their personal taste, sometimes in order to achieve effects that are not possible otherwise. A related recommendation is to conform to the users' expectations, which actually encompasses the first rule because misused controls contradict the users' expectations.
Other guidelines in this section are related to task performance. For example, they relate to:
Furthermore, performance is largely affected by the way how users have to enter data, such as dates, states, or currencies, into forms. Depending on the technical framework, there may be many options available that speed up data input.
Rule 1: Use correct controls.
Reason: Users have expectations about what control is used for which purpose. Using wrong controls puzzles users and slows them down.
Example: Using checkboxes instead of radiobuttons
Rule 2: Use controls correctly.
Reason: Users have certain expectations about how a control works. The incorrect use of controls puzzles users and slows them down.
Example: Using a group of radiobuttons with no initial value
Information design seems to be the most neglected aspect of UI design, particularly with respect to user performance. Actually, it can turn out as the most important one, because wrongly chosen words can be the reason why users fail at the computer.
I would like to distinguish between two aspects of information design:
Of course, both aspects are not independent of each other. In the following, I will present examples for both.
Rule 1: Tell users where they are, and what they can do
Reason: Users need orientation. Otherwise they lose time because the start to flounder and try to regain orientation.
Examples: Missing window titles, missing screen/page titles, missing group box titles
Rule 2: Tell users where they can go, and what they can
Reason: Users need orientation. Otherwise they start to flounder and lose time for getting oriented and finding what they need to accomplish their task.
Examples: Links with identical labels, links with meaningless or misleading labels
Rule 1: Use user-oriented terminology.
Reason: Terminology that users do not understand slows them down or lets them even fail to accomplish their tasks.
Example: Field labels using technical jargon instead of domain-specific language
Rule 2: Use descriptive/meaningful and consistent labels
for screen elements (fields, titles, headings, link, pushbuttons, etc.).
Reason: Users typically scan a form quickly. Meaningful labels support this habit. Being forced to speculate about the meaning of labels slows users down.
Examples: Links with identical labels, links with meaningless or misleading labels
Often, the visual design of software applications gets the most attention and may lead to heated debates. On the other hand, the majority of people regard it as a matter of taste, not one of performance. However, a bad visual design can slow the users' performance down considerably. Performance-oriented guidelines should answer the question, which characteristics of the visual design slow users down, and which are helpful.
Rule 1: Use sufficient (black & white/color) contrast between
foreground and background information
Reason: Low contrast slows users down because users need longer to extract the relevant information.
Examples: Gray text on an only slightly lighter background, similar colors for text and background
Rule 2: Use readable fonts
Reason: Hard to read fonts decrease the reading speed and thus slow users down.
Examples: Tiny fonts, unusual fonts
In this section, one important question is: How we can make waiting more tolerable or even imperceptible for the users? Thus, we are already facing the situation that further speed and responsiveness improvements are not possible. The typical answer to increasing the users' tolerance is giving them feedback. If a delay lasts longer, the feedback should be more qualified and inform users about the reason and the expected duration of the delay. For details see my series of articles Waiting at the Computer: Busy Indicators and System Feedback. Hiding waiting times is more difficult and is typically approached using methods for improving the responsiveness of a system.
Another question in the context of perceived performance is: How we can make interaction appear faster for users? It has been shown that this is the case if the interaction appears more natural and like in the real world to users. For example, smooth animations lets users judge systems as performing better than abrupt changes.
In both cases, we might argue that perceived performance depends on what users see. It also depends on what users know. Users are able to take the computer's work load into account and are more tolerant for waiting times if they know (or expect) that the computer has a lot of processing to do.
Finally, users judge a system's performance as better when they can continue work earlier and when they can accomplish their tasks successfully. The second item relates to UI design in a very general way. The first item once again touches the aspect of improving responsiveness. As we can see, a number of recommendations given under the label "perceived performance" are actually methods to improve a system's responsiveness. Often, it is not easy to keep both aspects apart.
Rule 1: If users have to wait, provide feedback.
Reason: Users need orientation and want to know what the computer is doing.
Example: Provide busy indicators for short delays (wait cursor, wait animation), provide informed feedback for longer delays (progress indicator, system message).
Rule 2: If users have to wait for a second or longer, include
the cause and duration of the delay in the feedback.
Reason: If users have to wait more than three seconds, they perceive the system as slow, their focus starts to wander and gets lost after about 10 seconds. After about 15 seconds users get annoyed. All these factors impact the users' performance negatively.
Example: Provide a progress indicator or at least a system message for longer delays.
Rule 3: Design applications in a way that users can accomplish
their tasks successfully.
Reason: Users judge a system's performance better and thus are more satisfied and motivated if they can accomplish their tasks successfully.
Example: See report by Perfetti and Landesman (2006)
There are many ways to make software applications perform faster and more responsive. First of all, technical options have to be pursued to improve a system's performance and responsiveness. But that is only half of the truth, because we have to deal with a human-computer, that is, a hybrid system. A closer look reveals that UI design aspects, such as interaction, information, and visual design play an equally important role for human performance at the computer. Performance-oriented guidelines can be an approach to making UI and visual designers aware of problem areas and help them not fall into traps that severely hamper the users' productivity and joy of use.
When establishing performance-oriented guidelines, we also need to reflect what their status might be with respect to existing company- or platform-specific guidelines. In my opinion, they should have the status of high-level or "meta" guidelines against which current UI guidelines can be checked. There must also be resolution mechanisms, which in the case of contradictions tell designers which guideline to give priority. One possible outcome might be that the designers deliberately decide to override the meta guidelines.