Performance-Oriented Design and Guidelines

By Gerd Waloszek, SAP User Experience, SAP AG – March 3, 2010; updated: October 12, 2010 • Original Article

Every morning, my office computer gives me the opportunity to go and get a cup of coffee, while it is starting up – and the coffee machine is not close to my office. At home, there is no such opportunity for using computer start-up time in a productive way, which makes my computer’s start-up time all the more annoying. I have therefore formed the habit of no longer shutting my computer down – I set it to sleep mode instead.

Computer start-up time is not only annoying for users (see also Addressing A "Design Issue:" Start-Up Time), it is one of the many battlefields, admittedly a more technical one, on which technicians and user interface designers are engaged in the fight to improve human-computer system performance. One possible approach to improving human performance at the computer - the one that I wish to advocate in this article - is to base UI design decisions on performance considerations and to define performance-oriented UI design principles, for example, in the form of performance-oriented UI design guidelines. I have already presented this approach in various articles elsewhere on this site. This promotional article aims to turn the spotlight back onto these articles and onto the wider topic of human performance at the computer (the articles are assembled in our Human Performance at the Computer highlight topic). As in my other promotional article in this edition, Universal Usability, I will also try to identify some new aspects.

 

Relationship between Improvements in Technical and Human Performance

UI designers may well be tempted to regard performance issues as a purely technical matter. The technical challenges involved in improving performance are indeed immense, and the removal of technical performance bottlenecks is of primary importance. In fact, there is absolutely no point in addressing other issues before the most pressing technical performance issues have been solved. For example, if a new Web application takes minutes instead of seconds to load pages, then UI designers had better wait until the loading times have approached reasonable values before they even think about improving the UI design. But the "purely technical" view is only partially true. On the one hand, and as the examples show, UI designers certainly need to collaborate with technical teams when addressing the goal of better performance. But there is also a great deal that they can do themselves to improve user performance: by taking into consideration the many ways in which UI design can impact user performance both at the technical and at the user level (for an overview, see Human Performance at the Computer – Part 1: Introduction).

Therefore, in the next step, UI designers and technical people can approach both technical and user-related performance optimization. Technical optimization may involve the use of less complex or fewer controls on a screen to reduce page load times. User-related optimization may involve selecting the design alternative that allows users to be most efficient. However, technical and design decisions are not independent of each other: Design alternatives that lead to different levels of user efficiency may also differ in their technical performance. The best human performance may even be achieved with the design that has the poorest technical performance, and vice versa. Only a close inspection of individual usage scenarios will tell UI designers whether a design improves only one or both performance aspects or, at the very least, whether it improves one aspect without degrading the other one too much.

 

Basing Design on Performance Considerations

If UI designers are willing to base their design decisions on performance considerations, where can they find appropriate guidance? In my experience, there are two major types of guidance for UI designers: imitation and guidelines (or standards). I will focus on the second aspect and hope that imitated designs are based on some kind of guidelines as well. My proposal for an appropriate way of providing guidance is this: Provide UI design guidelines that are targeted at improving user performance at the computer, so-called performance-oriented UI design guidelines.

I have already proposed such guidelines on this site (Human Performance at the Computer – Part 4: On the Way to Performance-Oriented UI Guidelines) and outlined the topics they might include; I will therefore refrain from repeating my proposals here. These guidelines should put user performance aspects first, and each rule should also be accompanied by reasons for its existence. Far from aiming to replace existing UI guidelines, such guidelines can be regarded as high-level or "meta" guidelines against which current UI guidelines can be checked. In the case of conflicts, designers can decide to either modify the current UI guidelines to conform to the performance-oriented guidelines, or to deliberately override them.

 

Where Can We Get Guidance?

Guidelines

Performance-oriented UI design guidelines need not be created from scratch. Existing guidelines already cover a multitude of performance aspects – the relevant rules just need to be collected und placed into a coherent framework. The Research-Based Web Design & Usability Guidelines of the U.S. Department of Health and Human Services provide a good starting point for such a collection and also have the advantage of being backed up by literature. The GUI Bloopers that Jeff Johnson (2007, 2000) collected and described in his books are also a useful source of performance-oriented guidelines, but need to be reformulated into positive statements.

Additional Guidance

In addition to guidelines, empirical studies can provide further guidance on performance-oriented design. This is particularly appropriate for more complex design questions, which are usually not covered by the design rules in guidelines. For example, guidelines rarely discuss design at the level of comparing design alternatives for a given usage scenario. User interface patterns may well encompass such scenarios, or at least certain aspects of them, but they are not usually designed according to performance criteria. With respect to the performance provided by different design alternatives, the following two – complementary – approaches spring to mind:

  • The technical performance of screens or pages, such as loading time, refresh after certain changes, and so on, can be measured and compared
  • The user performance for these scenarios can also be measured and compared

By comparing both sets of data, it is possible to derive recommendations and to rank the design alternatives according to how they affect technical and user performance.

 

Digression: Why Should We Improve Performance at All?

Finally, I would like to digress a little and ask the heretical question about why UI designers should devote their energy to performance issues by, for example, applying performance guidelines. The "performance" topic never seems to have been en vogue in the UI design field and appears to clash with current user experience concepts.

Performance: User Productivity or User Experience?

I have repeatedly argued that performance issues are the number one usability problem. While this may be an extreme point of view, most people will probably agree that poor performance is one of the most serious usability issues. This alone would justify UI designers investing time to deal with them. Interestingly, there is not much coverage of this topic at conferences, in books – Jeff Johnson's and Ben Shneiderman's books are notable exceptions – or in guidelines. I can can only speculate about the reasons for this paradox. I already mentioned that UI designers may regard performance as a technical, rather than a design-related matter. Striving for better performance may also not be inline with current "experience design" trends, because it is reminiscent of old-fashioned Human Factors concepts that primarily aim to increase user productivity. On the other hand, performance has a lot to do with a user's experience: Poor performance can have a devastating impact on the user experience, whereas good performance increases user satisfaction and motivation and thus leads to a better experience.

Perceived Performance and Perceived Quality

It has also been found that "perceived" performance may have more relevance for users than objectively measurable performance (see Human Performance at the Computer – Part 3: Perceived Performance), once again an argument that performance is closely connected with the users' subjective experience at the computer. Last but not least, performance aspects are also quality aspects. While quality may be seen as an objective criterion with regards to aspects that can be measured, it also entails a subjective component, as the current hype surrounding branding and design reveals (life style advertising; see also Is There such a Thing as Perceived Quality?). Quality is closely related to user experience, too, because users want quality, are sensitive to it, and using a quality product definitely enhances their experience. Performance, be it objective or perceived, is definitely also an ingredient of quality because it points to a well crafted product. Therefore, on closer inspection, the conflict or contradiction between user productivity and user experience vanishes into thin air: Improving perceived and objective performance – and thus quality – definitely makes for a better user experience.

 

Where Next?

The next step would be to set up a project (or series of projects) that aim to develop performance-oriented design principles or criteria. Having such principles or criteria at their disposal, UI designers could check the validity of this approach and even make comparisons between applications that were developed with and without applying such guidelines. We will, eventually, have computer systems that allow us to be more efficient and thus provide a better user experience – but it may be that we then no longer have time to go and get a cup of coffee during computer start-up.

 

References

  • U.S. Department of Health and Human Services (2006): Research-Based Web Design & Usability GuidelinesComplete guidelines (PDF)
  • Jeff Johnson (2007). GUI Bloopers 2.0: Common User Interface Design Don'ts and Do's. Morgan Kaufmann Publishers. (Chapter 1: First Principles; Basic Principle 8: Design for Responsiveness; Chapter 7: Responsiveness Bloopers) • GUI Bloopers checklist (PDF version) • Review
  • Jeff Johnson (2000). GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers. Morgan Kaufmann Publishers. (Chapter 1: First Principles; Principle 7: Design for Responsiveness; Chapter 7: Responsiveness Bloopers) • Review
  • Ben Shneiderman & Cathérine Plaisant (2009). Designing the User Interface (5th Edition). Pearson Addison-Wesley (Chapter 10: Quality of Service, p. 405ff) • Review
  • Ben Shneiderman & Cathérine Plaisant (2004). Designing the User Interface (4th Edition). Pearson Addison-Wesley (Chapter 11: Quality of Service, p. 453ff) • Review

 

To top top