Editorials

back  To Overview of Editorials

Editorials 2008

Editorials 2007

Editorials 2006

Editorials 2005

Editorials 2004

Editorials 2003

Editorials 2002

Editorials 2001

Editorials 2000

 

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

By Gerd Waloszek, SAP User Experience, SAP AG – 11/13/2008

Photo of Gerd WaloszekI 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 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:

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