Institutionalization of UX: A Step-by-Step Guide to a User Experience Practice, Second Edition (2014)
Part II. Setup
Chapter 5. Interface Design Standards
You can have interface design standards for browser-based applications, mobile devices, USSD (low-end phone), voice response, and other platforms.
If you look at any application or environment, you can likely identify a few screen types that account for approximately 85% of all screen development. Templates are representations of these key screen types and can be used as the “DNA” on which the entire application is built.
In addition to templates, a design standard should include general presentation and operation rules.
Interface design standards save development time, maintain consistency in designs, improve usability, and make maintenance easier.
There are a number of ways to create a design standard. Developing one from scratch should be a last resort.
Design standards can be applied to a website as well as to all of an organization’s public sites, extranets, and intranet.
Don’t develop standards unless you have a clear plan and resources for disseminating, supporting, and enforcing those standards. The completion of the standards is the beginning of the real process.
When teaching classes on design standards, I always start by asking how many people are excited by the prospect of doing all their future design work under a strict set of standards. Few people respond with enthusiasm. Many feel that design standards will be a terrible restriction, and implementing a standard feels like eliminating creativity. In reality, standards (both methodological and design) are like the well-known melodies in jazz (which musicians also call “standards”). Jazz standards provide a baseline melody, which the artist uses as a starting place from which to begin tasteful improvisation. Interface design standards are essential to provide a similar starting place and format. But it takes a great artist to work within the standard and make something worthwhile, just as it takes a great musician to work within the standards in jazz and create something special.
This chapter explains what interface standards are, explores why they help a usability team be efficient, and describes the content and characteristics of effective standards.
What Is an Interface Design Standard?
As you create a user experience engineering infrastructure, there is probably no more critical component than interface design standards. Done right, these standards help users who visit your page feel like they have interacted with a page like it before. With standards, the development is faster and maintenance is easier. But these design standards are not methodological standards, not software coding standards, not style guides, and not design principle documents.
Methodological standards, such as those described in Chapter 4 on user-centered design methodology, describe the process for design but do not specify precise design conventions.
Software design standards apply to the design of the underlying software. They do not address presentation-layer design conventions at all.
Style guides are usually like the style guides for writing a manuscript—they document specific fonts, colors, and the proper use of images and may even state the tone for the text. They may make suggestions on other topics, but they do not ensure full design consistency. These types of guidelines are useful, but they are not synonymous with design standards. Basically, a style guide documents rules for presentation style, but it does not get down to the level of specificity necessary to give the user the experience of real operational consistency. The style guide does not dictate the navigational and operational details of each screen, nor does it indicate which button is used to go forward—and we do need rules down to the level of selecting OK, Enter, or Continue for the button names.
Organizations often want to document design principles, essentially in the hope that such a document will tell designers how to do good interface design. In reality, design principles do not address the specifics needed to ensure design consistency. In any case, people rarely read documents of that sort. It is usually better to spend money on training rather than on writing a design principles document.
Interface design standards establish very specific requirements for the way screens look and operate. The key to these standards is the idea of a reusable screen type, pattern, or screen design template.
Types of Standards
You do not need a different standard for every system. You can create one standard that covers an entire range of applications in a given platform, such as a browser. A browser, for example, is used for both public and private websites—but that does not mean that you need different standards for each of those environments. A form can be designed with a set of conventions (such as how to show required fields), and those conventions can apply nicely across a wide range of systems and environments. If the interactive environment is different, however, you will need another interface standard. For example, a browser interface has different conventions from a thick client, a mobile application, and a voice response system. Each of these requires a separate standard. The browser standard can be extended to cover browser-based interactions on tablets and smartphones using responsive design, but then you need a browser standard that covers responsive design.
You do not need a different standard for each type of application. There might be cases where you have very different users and scenarios between applications, of course. You might find that you have scientists using one application and high school students using another. Do these two populations need a different design for data entry forms? They really don’t need different standards. We can pick one name for Enter and decide if the field labels will be followed by a colon. Such a decision can be applied across both of these populations without difficulty. There may be some screen types in the standard that are appropriate for scientists but not for students. A complex tree view, for instance, might be a bit difficult for the students to understand, in which case we would simply not use that screen type for a younger population.
Screen Design Templates
If you look at any given Web environment, you will find a limited number of page types that account for approximately 85% of the total development time.1 Some of the most common page types are home pages, forms, wizards, and database maintenance pages. The number of page types is not infinite; you might need a total of 10–15 page types for an entire environment.
1. This figure is based on HFI’s 20 years of experience in user interface design and standards development.
Ideally, you will develop templates of commonly used page types and then modify them to create the specific instances you need. For example, on a form you would change the headers and field labels, but you would not need to change the Enter button name or the conventions of left alignment and required field marking.
The templates you create will become the foundation of your template-based standards; these standards can be developed for computer software screens as well as webpages. Figure 5-1 shows an example of a template for a wizard. This template reflects good design practices, even for the parts of the interface design that are not standard, and will be customized by developers when using this particular wizard. A template should include accompanying documentation on when to use a page type, rules for the parts of the page that are standardized, a prototyping tool (allowing the template to be quickly converted into an individual page or screen), and reusable code.
Figure 5-1: Example of a reusable standard page template for a faceted search, taken from UX Enterprise
Instead of creating each page from scratch, the developer can consider the user’s task and then select the template page or pages that support that taskflow. As a consequence, he or she can work at a higher level instead of a very detailed level. Identifying the type of page needed and choosing the best template, the developer can decide whether to use a menu, a display table, or a wizard and then copy the conventions for the page type. If necessary, the developer can create hybrid pages that combine multiple types. Without a design standard, developers must invest time in creating everything from a name for each button to navigational features. The names and features they select are often ergonomically unsound, and the user is left to try to figure out the meaning of the buttons on each page. This problem is why a design standard needs to be specific about these types of details.
The templates serve as the “DNA” for all designs, so they must provide an example of quality design in all respects. At the same time, you need to identify and document those aspects of the template that are actually standards. Standards fall into two categories: basic standards and optional standards.
Basic standards are elements that you must have to use a given page type. They include the features that will identify the page type to the user and the universal ways of operating the screen.
Optional standards are a little more complex, but are required to make the standards work. They are elements that may or may not be needed. For example, on a search page, you may or may not require a link for an advanced search. The optional standard says that if you don’t need an advanced search, you can leave it out. If you do need this feature, then you must call it “Advanced Search” and place it in a consistent spot on the page. These rules need to be documented so that developers can look any item up and know what is actually required.
Improvements in technology for applying reusable code and content management have made the template concept work even better. These technologies make it easy to use program modules to support a given function on multiple pages. Once a defined page type exists, developers can readily write code to support it. In turn, designers actually need to do even more work if they want to violate the standard—they have to go into the reusable module and edit it.
The screen template approach described in the preceding section works by describing overall screens and then having designers modify those screens with task-specific content. An alternative “pattern” approach attempts to provide smaller standard modules—an address, calendar, or carousel, for instance—that can then be combined to create a screen. While this design practice is certainly efficient, it comes with a catch.
Organizations that create a half-dozen commonly used patterns do very well. Other organizations, however, may try to create components to handle almost all of their interface design needs. In most cases, this amounts to hundreds of items. After some time, it becomes quite difficult to find the pattern that you need, particularly as you develop more variations of those patterns—with the result that the patterns stop being used. We recommend limiting your pattern library to a couple of dozen designs, not hundreds (see Figure 5-2 for an example of a reusable pattern).
Figure 5-2: Example of a reusable pattern for a calendar component, taken from UX Enterprise
Other Contents of a Design Standard
While page templates are the core of a good design standard, other sections and materials are needed as well. Some requirements and issues, such as those listed here, arise with all page types:
• Header and footer designs
• Error handling (pop-ups, inline error messages, embedded messages, graphic treatments, and formats for message wording)
• Button labels (guidelines such as “Use ‘Next’ button to get the following page” and “Do not use ‘Forward,’ ‘Continue,’ ‘OK,’ ‘Up,’ or ‘Down’ buttons to get the following page.”)
• Justification of text
• Alignment of labels and data fields
• Formats for data (such as addresses and phone numbers)
• Restrictions on color usage
There is some overlap between style guide issues and design standards, of course. In many cases, the entire contents of the style guide can be incorporated into the general principles section of the design standard.
The Scope of Design Standards
It is important to note what is not included in the design standard. Except where there is a need to create a unified style and theme, it is best to leave significant design freedom to the developers. For example, an intranet may include hundreds of sites, and many will require different themes. The design standard should generally address only the elements critical to the user’s recognition and the operation of each page type—or restrictions needed to ensure a consistent brand perception.
It is important not to mix up the design rationale with the research behind various decisions within the design standard; this would create an unmanageable amount of work and a vast body of information when developing standards. Such documentation can overwhelm developers and other users of the design standards. The design standard should describe only the results of all this research. The full research and rationale can be archived in books or explored in training.
Some design standards go so far as to document the windowing environment or browser operation. In our view, it is a waste of time to document third-party environments, operations, and purchased facilities like e-mail clients, along with anything you will build only once. For example, standards for the design of a staff directory aren’t necessary because these standards apply to just that one application, and it is a one-time deliverable. It is far more efficient simply to develop specifications and build the directory instead of writing a standard that will guide the specification.
Another pitfall in this standardization process is the specification of underlying technology and coding practices. There is no question that technical standards are needed, but the design standards specify requirements for the presentation layer. While these requirements must be carefully reviewed to ensure that they can be implemented, there is no reason to make the presentation-layer standards dependent on the technology. It is wise to code the presentation layer separately. It is also wise to keep standards for middleware, databases, and coding practices separate from the design standards.
An interface design standard can cover a single application or a suite of applications, or a single Web site or a family of sites. For example, a financial institution might have a site for retail banking, a site for commercial banking, a brokerage site, and a corporate site. These sites might have different headers and footers. Different style guides might dictate different colors. But at the end of a form, all the sites should use the same word to say Enter rather than referring to the same function by different names (e.g., Enter, Submit, OK, Continue, Go). A single standard can cover a whole family of sites, such that when customers go from one site to another, they see that the company is consistent in its practices.
It is also possible to have a single design standard cover public Web sites, extranets. and the intranet. While some activities provided in the intranet could never be offered to the public—complex database maintenance, for example—there is a considerable advantage in using the same interface design conventions in multiple environments, such as for single functions or content modules. For example, current product features must be seen by the public—yet marketing staff, customer service representatives and suppliers must view those features, too. If the design standards are consistent, that page can be shared with all users.
You can also develop standards that work across different operating systems. While the controls for a form might differ somewhat in shape and style for each operating system, most of the conventions can be generalized successfully. While differences in hardware platforms do force some variations in page designs, you must make sure that a user who accidentally follows the wrong platform convention does not encounter any serious problems. If you make the Enter key mean “take an action” in one environment and “move to the next field” in another, for example, you will frustrate users and create significant mistakes.
Design standards can cover a very wide range of applications, but the one place where they cannot usually stretch is between platforms and technologies. For example, a standard for a voice response system cannot be applied to Web design. The standard scripting that works for telephone interactions does not apply to the Web. Also, as of this writing, it is difficult to develop a standard for both windowing applications and Web sites because the user expectations are quite different for each platform. Therefore, you need separate standards, although the page design, operation, and other attributes should remain as consistent and compatible as possible.
The Value of Design Standards
Design standards save development time. For example, instead of developers spending hours reinventing design decisions such as whether to call a button “Enter” or “OK” and where to place that button, they can simply refer to the design standards. This also ensures that all members of a team of developers can follow the same guidelines and makes the pages of an application or site consistent.
A design standard also saves development time by supporting the creation of reusable code. For example, if you define a single way for a search and list page to work, you can create reusable code to support that design. Applying that page type then simply requires making changes to the base code. This practice also reduces the need for quality assurance because the reusable code has already been debugged.
Design standards make applications more usable: because the designs are consistent, users can generalize their knowledge of how one screen works to all the other screens of the same type. If the standard is successful, users will look at the screen and think, “Hey! I’ve seen screens like this before.” The screen then works the way they expect. This consistency has tremendous value, even if the designs are a bit suboptimal or idiosyncratic. Standard designs are likely to be far superior to ad hoc designs ergonomically, however. Ad hoc designs are generally created by an individual with limited experience and limited time, whereas a standard represents the best thinking of an entire committee—generally including highly experienced usability staff. Also, because the decisions of that committee are leveraged across hundreds of designs, the committee members tend to work harder on each design decision.
Design standards make maintenance and upgrades easier, too. For example, the development of a new DHTML slider control might make some graphic display standards obsolete. Assume that this slider is so compelling that all designs really have to be changed to take advantage of it. This change requires that the standard be upgraded, with the change then being applied to designs across the organization—a lot of work. Without a standard, you must scan through a wilderness of different graphic display designs, consider each one separately, reinvent each design, code it, and then test it. With a standard, however, you can review page types and find those places where the slider is needed. These changes can then be systematically rippled across all those page types—a vastly more simple process.
A few other intangible advantages of standards are quite significant. In a standards-based design process, the attention and creativity of developers will shift to more productive areas. For example, instead of having to worry about how to reinvent another type of menu, they can apply their creativity to understanding user taskflows and making improvements; instead of renaming the OK button, they can find a faster way to process claims.
Standards also support the creation of a unified brand—a critical element in a public Web site or private intranet site. The standard can provide a site with a sense of cohesion, organization, and reliability. Many customers become confused when they find that designs are different between modules of a single application or sections of a Web site. Consistent designs, in contrast, create a positive impression—a seamless experience that supports the brand.
While developers may initially resist the implementation of a design standard, it is essential to have one if you must do a significant amount of development. In fact, experienced developers are becoming more welcoming toward usable standards. They recognize that standards make it easier for other resources within a user experience design-centered organization to help them design pages or screens that allow users to run applications successfully.
The Process and Cost of Developing Standards
Standards development should be a high priority when creating a strategy, and it should be tackled early in the activities list. There are three ways to get a design standard: buy a generic standard, customize a generic standard, or create a standard from scratch.
If you have a small company or a lean operation with typical interface needs, it makes sense to start with a purchased, generic standard. Clearly, you’ll eventually need to add conventions for your business area, special branding, specific user needs, and so on, but the off-the-shelf product will give your company a head start. You can start small, with customizations, and gradually build up your standard elements.
If you have a large company or your environment has many special needs, you need a full design standard, including a customized set of page types with specific designs to reflect your conventions and user needs, your brand (not just in color and logo), and the personality of your company—down to the style of interaction and page layout.
Purchased standards are a good starting point for a custom standard, even for a large organization. It is quicker to modify a standard than to create one from scratch. Full customization of a generic standard generally takes six to eight weeks.
In some situations, you will need to create a standard from scratch. The most typical case is one where your environment is so idiosyncratic that you can find no generic standard that remotely fits your requirements. The introduction of a new interface technology, for example, might mean there are no generic standards. Also, sometimes the corporate culture strongly values internally designed materials. If you decide to create design standards from scratch, be aware that this can be a long, painful process with many challenges. It will take a minimum of three months and perhaps even up to a year to do it right. The process will typically require $180,000 for a consultant’s support.
If you are customizing a standard or creating one from scratch, you probably need to employ a committee-driven process with a usability consultant as a facilitator. This method starts with a review of your strategy, business areas, applications, and sites that seeks to determine the types of screens you need. The consultant then designs a good example of each page type (these prototypes may be based partly on your screens and partly on a purchased standard). This set of designs goes into a committee process. The committee, made up of the key opinion leaders in the development organizations, reviews the designs and decides whether the approach for each screen type is appropriate. This is a concrete process; the committee is essentially asked, “Is this the way you want to do a menu/form/wizard?” The final standard is based on their decisions. The process for customizing a generic standard takes usually takes from six to eight weeks and costs about $100,000 (for the modification of the standards deliverable, including the consultant’s fees). If you can make your own design decisions without this level of facilitation and high-level guidance, however, your cost can be cut nearly in half.
No matter which method you use, here is one important piece of advice: ensure that your standards effort will not run out of steam by the time the standard gets written. Sometimes committees suffer from endless cycles of iteration during the standards creation process. After a year-long process, the standard may finally be complete, but committee members may by now be so sick of the process that they have lost the motivation to push the standard into adoption. In fact, the completion of your standards is just the beginning of the real process. It is important to pace yourself accordingly. No matter which method you choose to create a standard, be sure that you have the energy, will, and resources to follow through with its implementation.
Disseminating, Supporting, and Enforcing Standards
Before investing in a standard, be sure to plan for its dissemination and support. This means training, consulting, and enforcement.
Even though the design standard may strongly support creativity and improve an application’s or Web site’s usability, the resentment of standards is real. Thus, unless you work to evangelize and uphold that standard, nothing will happen after its creation. Your investment in developing it will be lost. You should not even develop a standard, in fact, unless you have a clear plan and budget for the standard’s dissemination and support. Getting the standard written is just the beginning of the process.
At HFI, we have argued vehemently over the years about whether a paper or an online standards document is better. A paper document is easier to work with in some ways; the developer is already using the full screen for design work, so an online standard requires switching between windows. However, there is a significant cost involved in having a paper version of a standard—it must be printed and distributed. Updates will be required, and then it will be difficult to tell if you have the current version. Also, increasingly, purchased standards come with online materials such as reusable code.
If you have an online version of the standard, everyone has access to it. When the standard is updated, everyone gets the new version at the same time. Of course, making sure that everyone has the standard is very different from getting everyone to actually use the standard. You have to get the word out. Send notices of various kinds and highlight a link to the standard on the developer’s intranet pages. Nevertheless, these efforts alone will not be enough to ensure appropriate use of the standard.
It is essential to provide training on the standard. Standards training differs in important ways from training on general usability engineering methods. Standards training needs to sell developers on the value of a standard. It needs to convince them that rather than stifling their creativity, the standard will actually make them more creative, effective, and professional—that there is still plenty of room for creativity with standards, but with a higher quality and consistency that make for better designs.
The standards training also needs to show people how to use the design standards. This means understanding the structure of the design standards themselves and ways to find things within them. Developers must be familiar with the different types of pages and be able to pick those that fit a given situation. They must also know how to use the general presentation rules. All this material can usually be presented in a half-day class. Done well, these classes increase acceptance of the standards and teach people to operate effectively within them.
Preparing reusable code is a powerful way to support standards. Often, a single standard is implemented in different environments: for example, your menu may be created in Macromedia Dreamweaver and Microsoft FrontPage, as well as by old-fashioned HTML coders working in Microsoft Notepad. It makes sense, however, to select the main environment(s) and create reusable code as a specific project. This may mean creating a template for each page type in a browser environment. The development process then becomes faster, and developers have to work harder to violate the standard. Maintenance is also easier because common code underlies the various pages. Alternatively, page designs may be placed in a content management tool. Whatever the environment, the introduction of reusable code will help move the standard into general usage.
With dissemination of the standard, along with training and tools that provide support for it, developers will start to try to follow the standard. They will sometimes have misconceptions or otherwise run into trouble when working with the standard. They might think that optional standards are required, might not understand which page to use for a given user task, or might even think that the content in the examples must be copied into the designs. Poor results like these can threaten the entire standardization effort. Designate one person or team as a resource to contact for help. The best way to staff this position is with internal consultants—key staff members within the central usability organization who can answer commonly asked questions quickly.
If a developer reinvents a page, however, there is no question for the internal consultants to answer. While the developer may be happy in such a case, the standard is undermined. Without feedback to the developer or immediate feedback to management, there is only a silent unraveling of your standards investment and, eventually, poor usability of the application itself. The only answer to this type of scenario is some type of enforcement.
Enforcement of standards is a hot topic. While it can be unpleasant in practice, some form of enforcement is required. The trick is to make this process fit the corporate culture. In some organizations, heavy-handed enforcement is natural and normal. In other environments, the very idea is abhorrent. In the latter case, don’t call this practice “enforcement,” but do at least institute feedback. Have designs reviewed by a usability engineer, and point out to developers specific places where they have violated standards.
The most common, worrisome problem is the reinventing of page types. Developers may attempt to create a new type of menu, for example. The review cycle for such elements is the time to point to the standard menu and suggest that developers use an approved page type to fit their needs. In some cases, all you can do is give feedback. In other environments, you might require changes, reporting the level of compliance to the developer’s manager. The need for support of your standard is an ongoing requirement. At HFI, we have often created offshore teams that scan all screens for both ergonomic quality and adherence to standards. It has been a cost-effective way to ensure that standards are routinely applied.
Even after you have developed standards, they will continue to need attention. The standard is a living document. You will need to make improvements, add page types, and clarify areas that receive frequent consulting questions. It is also likely that areas where refinements are needed will be brought to your attention after your showcase project is launched. This refinement will lead to further improvements and greater buy-in from all users.
Implementing interface design standards should be a high priority for any serious, user-centered design strategy. The initial costs to create standards may seem high, but the return on investment in terms of branding, consistency, navigation, performance, and time savings from following template-based options more than offsets them. These gains will far outweigh any initial cost. Remember, the completion of the standards is the beginning of the real process—using them for actual UX design work. The next chapter outlines the steps for achieving a successful showcase project, which will also present an opportunity to refine your organization’s standards.