On the Meta-Usability of User Interface Standards - 15 September 2006

Read this article in Chinese (translated by Li Ma, proofread by Long Pan)

Setting the standard

Interface standards provide context-specific guidance for implementing a system based on the task goals and functions within it. A solid standard provides guidance at two levels. At the level of look and feel, it ensures consistency throughout the application or site. To be meaningful in usability terms, the standard also must provide guidance to support a consistent experience at the functional level.

Assuming that a standard is constructed from a task perspective, the benefits are obvious. It’s easiest to demonstrate this by contrast.

Have you been on sites where every section looks as though it was designed by someone else? Look and feel standards eliminate this problem by describing an overall look and feel that is applied to each page. This consistency offers users confidence in their sense of place within the site. Systematically applied, look-and-feel standards support an implicit association between the brand and the full depth and breadth of the tools or resources provided. Things that look the same tend to be grouped together as coming from a single source.

Look-and-feel is only a small part of a good standard, though.

Have you ever been on a site where the search button says “Search” in one place, “Get” in another, “Find” in a third and “Go” in a fourth? (Within one portal, sporting lots of user-selectable portlets, they were all on the same page!) Good standards also provide functional specifications to eliminate just this sort of inconsistency. Standards identify key interaction types and describe patterns across them to make sites easier to learn, predict, and use.

Clearly end users benefit from well-designed interface standards. However, organizations benefit as well. Organizations benefit from reduced production costs and more effective use of resources. Production costs are reduced because standards are essentially reusable, template-based building blocks. Developers identify the task a user seeks to execute on a given page, select the template based on that task, and then customize the page to fit the specific context of that task. Most of the taskflow work is done at the point of template selection. Even better, site wide task-level consistency is achieved by simply teaching developers to select the right template.

Resource use is optimized because reusable templates allow time-strapped developers breathing room to focus on more interesting and challenging problems. The return is even greater in production teams where content developers accidentally became Web page implementers. For these teams, templates allow content developers to focus on content, rather than decisions about relative font sizes.

Here’s the standard… where are the developers?

Developing an organizational standard is one thing. Getting the developers to use it is often another. There are many social reasons and standards-development process reasons that standards efforts are ignored:

• The initiative may be highly politicized and/or poorly socialized.
• The standard may be built by a single group within an organization rather than through a collaborative effort across the organization. (Here the result is often that the templates are not broad enough to capture the users’ functional needs for other groups.)
• The standard may be too broad to be useful, looking more like a collection of guidelines or best practices than a context specific roadmap to usable design.

Thovtrup & Neilsen (1991) say that for a standard to be valuable it must meet two conditions:

1. It must specify a usable interface.
2. It must be interpretable/applicable by developers.

Put another way, standards also get ignored when their design specifications take too much effort to interpret and apply. To wit, a usability problem with the usability solution.

Think about it. Standards are often thick, word-on-paper requirements documents that, on say page 117, stipulate that the Search shall be implemented as a 35 character text input box followed by an action=submit button labeled… you get the idea. Sometimes there is a picture.

Silent screams and unusable standards

But really, an unusable user-centered design standard? Seems oxymoronic. But it happens. Mosier and Smith (1986) reported an apply-the-standard-in-your-design study in which only slightly more than half (58%) of designers could find the guidance they needed in a collection of interface guidelines. de Souza and Bevan (1990) reported that designers tasked with using a draft ISO standard were not confident how to interpret 30% of the rules and fully violated 11%. (The draft standard was iterated based on this feedback, demonstrating that, like interfaces, standards benefit from iterative testing and design.)

Thovtrup and Nielsen (1991) explored whether the failure to execute the stipulated standards related to the length / complexity of the document in a small lab study. In their study, participants were given a two-page interface standard for a hypothetical company buttressed by an example of a compliant system. Even with this minimal guidance, the compliance rate for the participants’ designs was only 71%. In this study, compliance was evaluated against a checklist of design elements specified in the standard. Perhaps if they had given participants the checklist instead of the standard…

Thovtrup and Nielsen (1991) also report a field study of the usability of interface standards. In their field study, they studied the attitudes of 15 in-house developers, explored attitudes toward, and use of, a 57-page standard at a mid-sized Danish software/service company. In addition, they examined the developers’ ability to recognize deviations from the standard.

In contrast to commonly held beliefs, the developers were generally positive about the need for, and use of, the standard. They clearly indicated a preference for an articulated standard over less rigorous design recommendations, commenting that the formal standard “minimized wasted time” arguing about minor interface details during project meetings.

A picture is worth a thousand words or more.

However, even with this highly positive attitude, the developers had a hard time applying the standard when measured in terms of identifying deviations from it. Participants failed to recognize elements of design that conflicted with the standard. Interestingly, participants also identified design details not addressed in the standard as violations. On closer analysis, the researchers noted that design details incorrectly identified as deviations from the (written) standard, could be mapped back to screenshot examples presented in the standard document. Although the screenshots were intended to exemplify only specific details of the standard, developers assimilated all of the design details of the examples. Concrete product design examples were more influential than the abstract requirements statements.

Queried about the usability of the standard, more than half of the participants said that the rules in the standard were difficult to remember. An equal number suggested that providing good programming tools would enhance the value of the standard.

To have value a standard must be used

This last lament provides insight as to why standards, though welcomed are not readily adopted. Standards, as they are most often presented, define a better world but don’t make it easier to implement. Thus, for standards to be valuable they need to:

Describe usable interfaces.
Describe the interface in an understandable way.
Provide online tools (eg.: templates, graphic libraries, selection matrixes, etc.) that make applying the standard a path of least resistance.
By adding this third condition, we will move from having a standard that’s valuable to a standard that’s adoptable. For a standard to be usable, it has to be useful.

References

• de Souza, F., and Bevan, N. (1990). The use of guidelines in menu interface design, Proceedings IFIP INTERACT’90 (Cambridge, U.K., 27-31 August), 435-

• Mosier, J.N., and Smith, S.L. (1986). Application of guidelines for designing user interface software, Behaviour and Information Technology 5, 1 (January-March), 39-46.

• Thovtrup, H. and Nielsen, J. (1991) Assessing the Usability of a User Interface Standard. Proceedings of ACM: SIGCHI. (New Orleans, Louisiana, USA, Pp. 335-341.

Kath Straub, Ph.D., CUA, Chief Scientist of HFI, looks at how to select the best menu presentation style for a given application.

Every month HFI reviews the most useful developments in user interface research from major conferences and publications. We cover the full range of human-computer interaction, including development, HCI issues, I/O devices, multimedia, documentation, and training. Welcome to Subscribe HFI Newsletter .

Possible Related Articles:

• The Concept of Universal Design
• Five Rules for Communication between Machines and People
• The application of model matching principle in user interface design - Part 2
• The application of model matching principle in user interface design - Part 1
• Easy, Intuitive and Metaphor, and other meaningless words
• The Gap between 25 Seconds and 5 Seconds
• Moving UX into a Position of Corporate Influence: Whose Advice Really Works?
• Meaning of Chopsticks in Asia
• Design for emotion: ready for the next decade?
• Why do people become attached to their products?