The Three Pillars of Human Performance at the Computer – Which One Fits Best?

By Gerd Waloszek, SAP User Experience, SAP AG – November 13, 2008; updated: October 12, 2010 • original article (editorial)

When talking about the performance of computer systems or applications, we soon realize that we have to consider an "android" system. That is, the performance of the whole system, not only the performance of its components, namely, the computer system and the human user.

So, we might ask, "Is there an approach that takes the whole system, the computer and the user into account?" In this article, I will look at this issue more closely.

Sometimes the android system needs help from the outside

Figure: Sometimes the android system needs help from the outside

When looking at definitions of performance, I found the following three buzz words:

  • (System/computer) performance
  • Human performance
  • Responsiveness

I will take a look at these three terms in sequence and check, whether they can provide an answer to my question from above.

 

System Performance

Let's first look at system or computer performance. Basically, it means speed. Relevant questions are:

  • "How fast is the computer (or its CPU)?"
  • " How fast is the disk, the local network, the wide-area network?"
  • " How fast does the user interface render?"

These are primarily technical questions. According to Jeff Johnson (2007), computer specialists think that all these times should ideally be zero, or at least as close to zero as possible. So they try to optimize the system in order to bring them down to zero. They optimize algorithms, system throughput, the network, the visual rendering, and so on. But as Jeff points out, they typically never reach their self-established high goals, and he argues that they optimize in the wrong places. Nevertheless, performance optimization is very important and the fundament for everything else. However, apart from some optimizations of the visual design (for example by reducing the size and number of images or simplifying the layout), there is little for UI people to do here.

 

Human Performance

On the other hand, when we turn around and look at the performance of the human users, we have to take into account the characteristics of humans, their abilities as well as their limitations. This applies to perceptual and cognitive abilities, and also to some degree motor skills. Last but not least, motivation plays an important role for users, which leads us to the "user experience" aspect of computer systems and applications. We also have to consider much larger time ranges – now we talk of seconds, not milliseconds.

Soon, we come to realize that design in its many facets has indeed a high impact on human performance – provided that the technicians did their homework and that the system runs smoothly and error-free (see my editorial What Matters Most?). It's all in there: Interaction design, information design, visual design, and the acknowledgement of subjective factors. The subjective factors can guide us to invent "perceived performance tricks," which let the computer appear, that is be "perceived" to be, faster – even though it may actually become a little bit slower technically.

Here are a few examples that demonstrate how the different design directions influence performance (for more information, see my article Performance – Merely a Technical Problem? (former editorial)):

  • Interaction Design: The incorrect use of controls puzzles users and slows them down
    Example: Using checkboxes instead of radiobuttons
  • Information Design: Terminology that users do not understand slows them down
    Example: Field labels using technical jargon instead of domain-specific language
  • Visual Design: Low contrasts or hard to read fonts slow users down.
    Examples: Gray text on an only slightly lighter background; tiny fonts
  • Perceived Performance Tricks: Make the computer feel faster, even though it may actually become slower technically
    Examples: Incremental page load; users can abort long-lasting processes and start new ones

Here we also enter the UI guidelines and standards domain. Typically, UI guidelines do not address user performance directly, although many of the rules or recommendations have an impact on performance. Performance-oriented guidelines would fill this gap and act as meta-guidelines against which current guidelines can be checked. By the way, 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. All in all, while human performance is not a technically agnostic topic – UI people have to live with technical frameworks and platforms – they are mostly on their own with respect to human performance issues.

 

Responsiveness

Finally the term "responsiveness" refers to the question how long users will have to wait for a system response. Relevant questions are:

  • "When will the users be able to continue their work?"
  • " What waiting times do users tolerate?"
  • " When will they become angry – and, eventually, torture or destroy their computers?" This is shown in an infamous video, which was however, a fake?

At first and naive sight, there should be no difference between performance and responsiveness. Isn't it the computer's performance, which dictates waiting times? That is an illusion, as Jeff Johnson points out: performance and responsiveness are two different pairs of shoes.

To illustrate the "performance illusion," let me tell an example from my own experience with computers. There is a factor of nearly 2.000 between the processing speed of my first computer that I bought nearly 30 years ago (an Ohio Superboard with an MOS 6502 running at 1 MHz) and my current one (an Apple MacBook Pro with an Intel Core Duo running at about 1.8 GHz, actually it has even two CPUs!). Does my current computer feel 2000 times faster than the old one? No, it does not – sometimes it feels even slower.

Thus, whereas the technical people put us off with the upcoming release of ever faster computers, their promise seems to never come true. Of course, there are a number of reasons why the promise does not come true. One of them is that computers have much more work to do today than their predecessors in the good old times. These days, everyone has a full-fledged multi-tasking system on his or her desk or laptop. Formerly only large companies could afford such powerful systems. And these systems are always busy: for example, doing some background and housekeeping tasks for us, many of which will remain unknown to us forever. One might also argue – but that is a bit cynical, of course – that as computer users are becoming more and more simpleminded – that is, they are no longer experts but ordinary people – the computer has to take over more and more work, which takes, of course, time and resources.

Back to the original question: Why is there a difference between performance and responsiveness? The answer is that the simple picture that I presented above is only true if we had to wait until the computer has finished a task completely and then hands control over to us – as in an (uninterrupted) human dialog. But with modern multi-tasking systems and advanced programming techniques this requirement is no longer valid. Computers can shift processing priorities, rearrange requests in the event queue, delay them, and delete those that have become moot. As computers are idle most of the time anyway, and waiting for the users, they can look ahead and calculate in advance or in the background what may be needed in the future – there are many options. Or they can simply present unfinished results, as in the case of page loads, or display results where only the visible part is final.

Instead, computer applications often block user input, display empty screens, or let users agonize in front of the screen, not knowing how long a requested operation may take. As we can see, there is a lot of work for both technical as well as UI people to do. While the technicians focus on advanced programming strategies and software architectures, usability people can tell them how long users will be willing to wait, particularly considering the type of task (or UI event), from when on the users' focus of attention will shift to other things, and from when on they will get annoyed or become angry. UI people might also hint at "perceived performance tricks," which the technicians might employ and which, even though they may make the machine a little bit slower, can provide users with the illusion that the computer is faster. This would lead to higher user satisfaction, greater motivation, and thus eventually to better user (and android) performance.

 

Conclusions

Human performance at the computer has many facets. It is not just a pure technical problem, for example, not just one of speed. When human users come in, other aspects also play a crucial role. One is proper UI design, others include user control, system feedback, and the users' tolerance for waiting times – or the lack of it. Responsiveness seems to be the concept that is most appropriate to tackle performance issues from the user experience as well as from the technical side. At the responsiveness corner there are many tough challenges awaiting both sides. Let's hope that attacking the responsiveness issue will bear fruit and that the future will not only provide us with computers which are faster, but also with ones which are more responsive, and thus make users more productive.

 

References

 

top top