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.
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:
Thovtrup & Neilsen (1991) say that for a standard to be valuable it must meet two conditions:
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.
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.
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.
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:
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.
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.
Sign up to get our Newsletter delivered straight to your inbox
HFI may use ‚Äúcookies‚ÄĚ or ‚Äúweb beacons‚ÄĚ to track how Users use the Website. A cookie is a piece of software that a web server can store on Users‚Äô PCs and use to identify Users should they visit the Website again. Users may adjust their web browser software if they do not wish to accept cookies. To withdraw your consent after accepting a cookie, delete the cookie from your computer.
HFI believes that every User should know how it utilizes the information collected from Users. The Website is not directed at children under 13 years of age, and HFI does not knowingly collect personally identifiable information from children under 13 years of age online. Please note that the Website may contain links to other websites. These linked sites may not be operated or controlled by HFI. HFI is not responsible for the privacy practices of these or any other websites, and you access these websites entirely at your own risk. HFI recommends that you review the privacy practices of any other websites that you choose to visit.
HFI is based, and this website is hosted, in the United States of America. If User is from the European Union or other regions of the world with laws governing data collection and use that may differ from U.S. law and User is registering an account on the Website, visiting the Website, purchasing products or services from HFI or the Website, or otherwise using the Website, please note that any personally identifiable information that User provides to HFI will be transferred to the United States. Any such personally identifiable information provided will be processed and stored in the United States by HFI or a service provider acting on its behalf. By providing your personally identifiable information, User hereby specifically and expressly consents to such transfer and processing and the uses and disclosures set forth herein.
In the course of its business, HFI may perform expert reviews, usability testing, and other consulting work where personal privacy is a concern. HFI believes in the importance of protecting personal information, and may use measures to provide this protection, including, but not limited to, using consent forms for participants or ‚Äúdummy‚ÄĚ test data.
HFI may use personally identifiable information collected through the Website for the specific purposes for which the information was collected, to process purchases and sales of products or services offered via the Website if any, to contact Users regarding products and services offered by HFI, its parent, subsidiary and other related companies in order to otherwise to enhance Users‚Äô experience with HFI. HFI may also use information collected through the Website for research regarding the effectiveness of the Website and the business planning, marketing, advertising and sales efforts of HFI. HFI does not sell any User information under any circumstances.
HFI may disclose personally identifiable information collected from Users to its parent, subsidiary and other related companies to use the information for the purposes outlined above, as necessary to provide the services offered by HFI and to provide the Website itself, and for the specific purposes for which the information was collected. HFI may disclose personally identifiable information at the request of law enforcement or governmental agencies or in response to subpoenas, court orders or other legal process, to establish, protect or exercise HFI‚Äôs legal or other rights or to defend against a legal claim or as otherwise required or allowed by law. HFI may disclose personally identifiable information in order to protect the rights, property or safety of a User or any other person. HFI may disclose personally identifiable information to investigate or prevent a violation by User of any contractual or other relationship with HFI or the perpetration of any illegal or harmful activity. HFI may also disclose aggregate, anonymous data based on information collected from Users to investors and potential partners. Finally, HFI may disclose or transfer personally identifiable information collected from Users in connection with or in contemplation of a sale of its assets or business or a merger, consolidation or other reorganization of its business.
If a User includes such User‚Äôs personally identifiable information as part of the User posting to the Website, such information may be made available to any parties using the Website. HFI does not edit or otherwise remove such information from User information before it is posted on the Website. If a User does not wish to have such User‚Äôs personally identifiable information made available in this manner, such User must remove any such information before posting. HFI is not liable for any damages caused or incurred due to personally identifiable information made available in the foregoing manners. For example, a User posts on an HFI-administered forum would be considered Personal Information as provided by User and subject to the terms of this section.
Information about Users that is maintained on HFI‚Äôs systems or those of its service providers is protected using industry standard security measures. However, no security measures are perfect or impenetrable, and HFI cannot guarantee that the information submitted to, maintained on or transmitted from its systems will be completely secure. HFI is not responsible for the circumvention of any privacy settings or security measures relating to the Website by any Users or third parties.
Human Factors International, Inc.
PO Box 2020
1680 highway 1, STE 3600
Fairfield IA 52556
HFI reserves the right to cancel any course up to 14 (fourteen) days prior to the first day of the course. Registrants will be promptly notified and will receive a full refund or be transferred to the equivalent class of their choice within a 12-month period. HFI is not responsible for travel expenses or any costs that may be incurred as a result of cancellations.
$100 processing fee if cancelling within two weeks of course start date.
4 Pack + Exam registration: Rs. 10,000 per participant processing fee (to be paid by the participant) if cancelling or transferring the course (4 Pack-CUA/CXA) registration before three weeks from the course start date. No refund or carry forward of the course fees if cancelling or transferring the course registration within three weeks before the course start date.
Individual Modules: Rs. 3,000 per participant ‚Äėper module‚Äô processing fee (to be paid by the participant) if cancelling or transferring the course (any Individual HFI course) registration before three weeks from the course start date. No refund or carry forward of the course fees if cancelling or transferring the course registration within three weeks before the course start date.
Exam: Rs. 3,000 per participant processing fee (to be paid by the participant) if cancelling or transferring the pre agreed CUA/CXA exam date before three weeks from the examination date. No refund or carry forward of the exam fees if requesting/cancelling or transferring the CUA/CXA exam within three weeks before the examination date.
There will be no audio or video recording allowed in class. Students who have any disability that might affect their performance in this class are encouraged to speak with the instructor at the beginning of the class.
The course and training materials and all other handouts provided by HFI during the course are published, copyrighted works proprietary and owned exclusively by HFI. The course participant does not acquire title nor ownership rights in any of these materials. Further the course participant agrees not to reproduce, modify, and/or convert to electronic format (i.e., softcopy) any of the materials received from or provided by HFI. The materials provided in the class are for the sole use of the class participant. HFI does not provide the materials in electronic format to the participants in public or onsite courses.