Have You Ever Heard of Performance-Oriented (UI) Design?

By Gerd Waloszek, SAP User Experience, SAP AG – November 13, 2008 • original article (editorial)

I am proud to announce that we published our second highlight topic on the SAP Design Guild today. This year's articles focus on performance, or more precisely, on various aspects of human performance at the computer, including system performance, system responsiveness, human performance, perceived performance, and optimization of design for performance. Since there are already a number of introductions to the highlight topic on this site, including a leading article and an introduction to the topic, I would like to devote this article (originall an editorial) to a specific aspect: In the title, I ask "Have you ever heard of performance-oriented (UI) design?" Let me insist and ask again: "Have you?"

I do not know know what my readers' answers are, but my personal answer is that I hadn't until a few days ago. It was then that I (re?)invented this term while riding on my bicycle to work and pondering performance issues. By the way, I have found that riding a bicycle is much better suited to letting my mind wander than driving a car. What's more, it takes longer when and thus gives me more time to think. Up to that moment, I had been writing about performance-oriented guidelines only, that is, about the rules or recommendations that guide developers and UI designers and help them design user interfaces that lead to better human performance. But I had not thought of performance as the focus of a design orientation or direction in its own right. However, when you talk about performance-oriented (UI) design instead of guidelines, the focus is actually changed or even reversed: "Design" implies that developers and UI designers actively strive for applications with better user performance. Performance-oriented guidelines would retreat into the background and take over the role of a "tool" for designers.

Perhaps you have already noticed that, up to now, I have referred only to "human performance." This week, our project team took part in a discussion about complex screens and how to improve their performance. When I first thought about the invitation to the meeting, I was convinced that performance-oriented UI guidelines would be helpful in the upcoming discussion. However, when I thought a little more, I realized that the target of the meeting was actually to improve the speed of these screens, particularly their loading times. This aspect is, however, primarily determined by technical factors, such as the number and complexity of screen elements, the number of server roundtrips, memory consumption, and so on. Thus, on closer inspection, I arrived once more at the conclusion that performance has a number of different aspects and that all of these need to be taken into account in order to achieve the best possible results.

On even closer inspection, I found that both aspects – technical and human performance – are deeply intertwined and may sometimes even lead to contradictory recommendations. Let me list a few examples that spring to my mind in order to demonstrate the complexities involved:

  • Simple controls may lead to shorter page-load times, but they may also lead to more cumbersome interaction, which slows users down. Which effect is the more relevant one can only be answered by considering individual screens and testing them with realistic usage scenarios.
  • The UI technique of progressive disclosure is a well-known UI design principle. However, it also has an impact on the technical behavior of the system. Revealing screen elements as needed leads to simpler screens that load faster but that require user actions to reveal more information. This in turn leads to the further loading of page elements and thus to additional waiting times. Here, we have a kind of "distribution of work load" phenomenon – the results of which are again unknown until we consider individual screens and test realistic usage scenarios.
  • Server or host roundtrips present one of the major performance bottlenecks, particularly over long network distances. Eliminating roundtrips by using AJAX techniques, for example, can greatly improve the technical performance of an application without much negative impact on the users' performance. (However, the way in which users interact with the system may change dramatically when such techniques are being used, and thus the effects on the users' performance may not be evident in advance.)
  • Rearranging screen elements according to priority and the task at hand may not impact technical performance much, but it can have a noticeable impact on the users' performance.

These examples demonstrate that, in some cases, it is sufficient to regard only the pure technical or the pure UI design aspect. In other cases, the relationships between the two may be complex, and it can be difficult to predict the effects of technical changes on human performance or of design changes on technical performance. Only a close inspection of individual screens will tell designers whether the applied manipulations have succeeded in improving one or both aspects of performance – or at least in improving one aspect without degrading the other one too much.

Eventually, I have come to the conclusion that it does indeed make sense to "open up" the technical section in the performance-oriented guidelines for recommendations that only or primarily affect technical performance. But I would try to keep them at a design level, not a technical one. For example, such recommendations would refer to server roundtrips, the use of certain UI controls, or complexity considerations, but not to technical details, which are the domain of technical performance teams. At a more strategic level, however, I believe that starting a "performance-oriented design" movement would be a good idea. This "movement" or "direction" could foster the idea of designing user interfaces for both good technical and good human performance, and would probably provide more impetus than just another set of (performance-oriented) guidelines – even though these guidelines would definitely be needed as guidance for developers and designers.

 

top top