Performance – Merely A Technical Problem?

By Gerd Waloszek, SAP User Experience, SAP AG – Updated October 13, 2008

Photo of Gerd WaloszekTwo years ago, in the last editorial for 2005, I asked "What Matters Most?" and took a look at the most severe obstacles to usability. In this editorial, the final one for 2007, I would like to gloss over a related topic, namely "What influences performance at the computer?" When I look back to the 2005 editorial, I find that waiting times and system crashes were the primary factors. On closer inspection, however, it shows that the performance issue encompasses a great deal more than just technical factors.

Performance, or efficiency, is definitely a high-priority criterion for the design of user interfaces. However, I would argue that performance is not the primary goal for users, as the following quote from Peter Drucker shows:

  • There is nothing so useless as doing efficiently that which should not be done at all (Peter Drucker).

Having clarified this point, we can move on to the question: "How can we improve performance?" In order to attack this issue successfully, we have to understand which factors can influence performance. An initial approach to this matter might be:

  • First, there is the technical side, which can be tackled by technical optimization, such as improving database access, data structures, and the code, making page graphics smaller and/or decreasing their file sizes (or doing without graphics at all), and so on.
  • And then there is the human side, which can be tackled by usability methods. Usability strives to improve human performance by, for example, optimizing the offered functionality, streamlining the work flow, structuring the screens, and so forth.

Thus, computers and humans form an "android" system for which performance has to be considered as a whole. Good technical performance does not necessarily imply that the system as a whole will perform well if other factors are not optimal. On the other hand, a well-designed interaction may be ineffective if the system suffers from long waiting times or crashes repeatedly so that users lose their work. However, this picture is still too simple. Interaction design is tricky because it cannot be isolated from the technical platform on which an application or Web page will run. Often technology and interaction form an unhealthy alliance that is responsible for severe performance issues. In addition, human users introduce further complexities based on how humans process information and perceive their environment. In the following, I will discuss five factors that influence performance. However, in an editorial, I can only gloss over these factors, so please regard this as a first approach to a complex issue.


Factor One: Technical Factors (Optimization)

Technical optimization is important and "goes without saying." As I am a usability person, I do not want to go into detail here – we all know that technical optimization lays the foundation for good performance (including crash-free performance).


Factor Two: Interaction Design

A major element in the work of usability people involves streamlining the users' interaction with computer systems. I would like to differentiate between two cases: (1) "pure" interaction design, and (2) cases where interaction design and technology form an unhealthy alliance. I will explain what I mean by this below.

"Pure" Interaction Design

This case is fairly simple to deal with: Usability engineers strive to optimize work processes by asking and observing users, developing scenarios, building prototypes, and creating designs with the users and their tasks in mind. Typically, they work with the "givens," that is, the given technological platform, control libraries, and other constraints. User performance can be hampered by bad design, such as using inappropriate screen controls, making work processes too cumbersome, asking for unnecessary data input, or hiding often-used functionality – the list of possible design errors is long and the object of many design articles and columns.

Interaction Design versus Technology

Far less attention is devoted to the fact that certain technologies build up specific obstacles to good performance. One might argue that, as the respective technology has to be used there is no use in complaining about technological constraints. While this is certainly true, these constraints need not be accepted as "eternals laws." Not only makes it sense to at least remind oneself of these constraints from time to time, but also to look for alternatives. Here are a few examples of such technically-caused "performance killers:"

  • Database applications: Queries cannot be cancelled; thus, users may have to wait a long time for the result of a query that they started by accident (typically, there is no indication of the duration)
  • Database/Web applications: Instead of keeping data locally at the front end, data has to be reloaded. This makes a "round trip" necessary, resulting in a delay, possibly a page refresh, etc.
  • Web applications: User interactions cause page refreshes; these are visually disturbing, cause delays, and often destroy the work context because the page has to be scrolled down again or a selection selection repeated
  • Web applications: Running Web applications in a browser environment means that UI controls have to be "reinvented" in HTML or other technologies, often resulting in inferior and much more cumbersome handling
  • Web applications: Running Web applications in a browser environment means that the context menu cannot be used, resulting in non-standard alternatives, which lead to errors and slower performance

There is some truth in a statement I once heard from usability gurus, namely that the Web has thrown usability back for decades. Therefore, it is not only important to be aware of the issues, but also to look for better alternatives. The hype surrounding AJAX is partly due to the fact that it allows us to design Web applications whose behavior closely resembles desktop applications. In addition, standards are needed to regulate the interplay between the browser environment and the applications that run in it. Many more items could be added to this list.


Factor Three: Information Design

The relevant factors for user performance do not end with interaction design. Information design can also have a major impact on performance. Here, I would like to point to the following two design aspects:

  • The design of single screens or pages
  • Navigation between screens or pages

In contrast to consumer applications, many business applications have a hierarchical structure, similar to that of a Website. Therefore, users have to navigate between screens. Designers need to make sure that users find the correct paths and do not get lost. Alternatively, designers can opt to use large screens to reduce navigation. The design of single screens affects the overall clarity of the design: It helps users understand what to do on a screen and how to do it. The overall arrangement of fields and other controls should follow the typical work flow of the user in order to avoid unnecessary searching. Information design for screens also comprises the understandability of labels, group headers, and the screen or page title. All in all, good information design can reduce search time and, often, it determines whether users will accomplish their tasks successfully or fail.


Factor Four: Visual Design

While it is often the first issue that users (and customers) debate on, visual design is not so much at the forefront when we talk about performance. Nevertheless, it does have an influence on performance:

  • Badly chosen colors and/or color contrasts
  • Small or illegible fonts
  • Icons with no obvious meaning

can slow users down considerably. Icons that are too small also increase reaction times (Fitts' law) or even lead to errors because users miss them. Missed icons may even lead to unnecessary page refreshes and loss of context in Web applications.

From time to time, certain design epidemics infest the Web. Some years ago, there was a trend toward underlined text. Just recently, a trend to using gray text and microscopic font sizes could be observed. All of these trends have one thing in common: they slow users down.


Factor Five: Perceived Performance – The Subjective Side of Performance

We would not be human beings if everything worked "objectively." And performance is no exception. There is a difference between objective and perceived – or subjective – performance. Lori Landesman, for example, reported that, surprisingly, people do not rate the loading times of Web pages according to their objective loading time. She wrote:

  • When we began our research, we thought we would find a strong relationship between page download time and usability: sites with faster download times would be more usable than slower sites. We also expected that users would be consistent in their ratings of site speed, and that these ratings would correlate strongly with the actual speed of the sites.
    (From: The Truth About Download Time by Christine Perfetti and Lori Landesman, originally published on January 31, 2001)

Landesman found that, while users rated the speed of different Websites consistently, "there was no correlation between these and the perceived speeds reported by our users." One of the factors that made a site appear fast was that "users successfully completed their tasks on a site."

Thus, we have to find out, which factors make applications or Web pages appear fast and interaction seem smooth – and utilize these factors in our designs. A number of factors have already been identified:

  • Piecemeal build-up of screens or pages that allow users to begin getting information while the page is still building up
  • Reliable progress indicators
  • Plausible waiting times that correlate with specific user actions (in contrast to erratic waiting times)



Performance at the computer is a complex blend of many factors. Technical optimizations that lead to better performance lay the foundation for all other factors, and are indispensable. However, relying or focusing on these alone, is not enough. Developers and usability professionals need to take the following into account:

  • The general architecture of the technical platform – which characteristics of the platform lead to performance bottlenecks?
  • The dependency between the technical platform and the interaction design – where do the technical platform and the interaction design form an unhealthy alliance that leads to specific bottlenecks in user performance?
  • The interaction design – where can interaction be improved within the given technical framework?
  • The information design – where do users find what: how can they get to a specific location?
  • The visual design – which characteristics of the visual design slow users down?
  • The use of "psychological tricks" to improve performance subjectively – how can we make waiting more tolerable (or even imperceptible) and interaction smoother for users?

As there is often an intricate relationship between these factors, we need a holistic view in order to make greater progress in improving user performance.


Addendum: Two Analogies

As an addition to this editorial, I would like to use the analogy of a car to illustrate examples of technical and the more human-related performance aspects. Furthermore, I would like to illustrate the concept of perceived performance with another story.

Using software without optimizing the technical performance is like having a car without wheels – it does not move at all. However, adding wheels to a car does not necessarily mean, that you'll have a smooth ride, or that you can drive as fast as technically possible. You must also be able to start the engine, get the car moving, and drive safely and comfortably.

My brother once told the story of a driver who had to transfer his colleagues and him to the airport. The driver tried hard to get the car to speed and pressed the accelerator pedal as hard as he could, but he drove in the first gear the whole time. After some time, the engine overheated, and the driver had to pull over and stop the car. Not only was it a miserable ride (too slow) but he also did not reach his goal, the airport.

In case of the driver, we do not know why he did not switch gears. Perhaps he had only driven cars with automatic transmissions. If we transfer this example to the world of software applications, we might find that the other gears were buried somewhere deeply in the menu hierarchy, had illegible or unclear labels, or weren't there at all. Interaction design, information design, and visual design are the "set of screws" for optimizing such performance aspects.

Finally, there is perceived performance, which I would like to illustrate with another story: A long time ago, we took a friend of ours for a ride in our car, a Renault R4. I was driving at a speed of about 110 km/h (nearly 70 mph) – the R4 is not a fast car. Suddenly our friend cried: "Please, slow down, I am terrified by the speed!" Well, it could not be the speed that had terrified her, because she owned a Mercedes Benz and was definitely used to drive at much higher speeds. It was the noise and the vibration of the car that made her feel like she was going more than 200 km/h (120 mph).




top top