“Guidelines themselves aren’t the problem; it’s their misapplication that is.”Guidelines. We seem to have a love-hate relationship with them. At the same time we construct them, we worry they’ll come back to haunt us. How did guidelines get such a bad reputation?

On the whole they’re usually a sincere attempt to capture valuable knowledge or provide instruction to the less experienced. Implicit within efforts (such as Boxes and Arrows) is the development of guidelines, and that’s a good thing. Guidelines themselves aren’t the problem; it’s their misapplication that is.

Before discussing the utility of guidelines and how best to apply them, let’s define some terms. IBM’s “Ease of Use” defines guidelines as something more specific than principles but less explicit than conventions, standards, or rules. For the purposes of this discussion, that definition works well. Although you might consult guidelines to help determine your house style or the set of conventions used for a particular site, the guidelines are not the conventions themselves.

Guidelines are a good thing

When knowledge is captured in the form of a guideline, it’s known as a prescriptive theory. Prescriptive theories suggest actions to take that will lead to desired results. Guidelines aren’t rules to be enforced. They don’t eliminate creativity and innovation from the design process. Instead guidelines are a vital part of our decision strategy during the design process.

In addition, as Microsoft explains in the introduction to its “Inductive User Interface Guidelines,” “following UI guidelines might help ensure that the product you give your users allows them to apply skills they’ve already learned to common tasks and learn new tasks more easily.” But how can guidelines be integrated as a useful part of the design process? To answer this question, it’s helpful to try to describe that activity itself.

The design process

Design is a process of interpretation, not a routine based in explicit rules and exacting propositions. It is an argumentative process, or what Donald Schön in his book The Reflective Practitioner calls “reflection in action.” This action involves examining the tradeoffs of design choices and debating them with oneself and others. Design becomes an iterative conversation between the designer and the design situation, with both the designer’s understanding and the state of the design space undergoing continuous change. [1] It’s this debate that’s part of a process of iterative understanding. The conversation itself is needed in order to construct an appreciation of the environment that dictates the design needs of our end product. The guideline, then, isn’t the end of this conversation, but instead it’s an important part of it.

Engineers, for example, when engaged in this conversation don’t actually map out every possible design choice to make the optimum choice. Instead, faced with a complex task with uncertain outcomes, they choose the first satisfactory option — they satisfice. As we work within these increasingly complex situations, weighing business and user needs, taking into account technological and time constrains, guidelines exist to support the decision-making that’s part of the design process.

For a guideline to be a useful participant in the conversation, it needs to reveal its etiology. Pithy top ten lists and similar pronouncements don’t serve us well. A poorly constructed guideline does not add to the design conversation, but is instead a parent proclaiming, “because I said so.” Instead, evidence-based guidelines are the most useful so that when we consider the applicability of a particular guideline to a situation, we can look at the research that went into its formulation.

Usability.gov’s “Evidence-Based Guidelines” provides a great example of communicating the background research. They’ve devised a rating system to indicate the “strength of evidence” for each guideline and cited their sources making these guidelines very useful to practitioners. (See case study) Looking at this scale and examining some of the sources can help us as we assess a guideline’s applicability to a particular situation.

Context, context, context

“Usability guidelines always need to be applied with a certain amount of understanding as to when they apply and when they don’t apply,” warns Jakob Nielsen in an interview in Boxes and Arrows. To start, know that application of guidelines is dependent on context. John L. Campbell, in “The Development of Human Factors Design Guidelines,” [2] when discussing the formulation of local project specific directions, reminds us that the final design “will always represent an integration of user requirements, design constraints, available information and expert judgment.” There are no guidelines that are applicable in all contexts. Clay Shirky’s recent description of very localized sites developed by his students is an excellent illustration of taking context into consideration. Several of his students developed applications that relied on particular social situations for a very well defined small set of users. Considering the context meant that some guidelines applied to their situation, while others weren’t relevant.

A little knowledge is a dangerous thing, or so the saying goes. Design neophytes, therefore, may be ill-equipped to consider a guideline in context of the greater design problem. It’s only with some experience that we learn to balance top-down design knowledge with situation-specific analysis. They frequently fall victim to faulty deductive reasoning as well, confusing a rule with the guideline it attempts to follow. For example, if a guideline suggests that we should make it easy for a user to find the main navigation, and putting the navigation down the left hand side of a web page achieves this objective, a novice might then have a tendency to reason that all easy to find navigation goes down the left hand side. We’ve all done it at one point or another. Evidence-based guidelines give novices a narrative to reference with different contexts to consider and might help them avoid making false assumptions based on limited experience.

Consider the following when assessing the applicability of a guideline:

1. Design can never be static over time.
   Your local style guide might change quickly, but a single guideline may change more slowly and the movement of principles is almost imperceptible. However guidelines do evolve. For example, in 1994 Jacob Nielsen found that most users, when looking for links on a web page, don’t scroll. However, in 1997 he noted that behavior had changed. So a guideline based on findings from 1994 would be inappropriate in most contexts today.
2. The phrase “interactive media” includes a plural noun.
   The web alone covers a broad list of activity. At its most simple, it can be discussed in terms of Jesse James Garrett’s original “Elements of User Experience” diagram. The illustration outlines the duality of the web, acting as hypertext and then as software interface. [3] These two very different uses are something to watch out for when considering the applicability of a guideline. What applies in one context may not in the other, although they both involve the web.

As you bring guidelines into the design process keep in mind that they are not conclusions, but instead just part of the conversation between designer and the design situation. A problem with guidelines arises when they are used to short circuit that conversation and when they are documented in such a way that one can’t answer the question “why” during the design process. When we are mindful of context and the strength of evidence as we work within the bounded rationality of the design process, guidelines become invaluable.

Tanya Rabourn is an information architect and interaction designer. She’s built sites for small retailers, major research institutions, and a whole lot in between. She earned an MLIS from The University of Texas at Austin in 1996 and is currently an information architect in New York City. Her personal website is pixelcharmer.com.

Notes

1. Coyne, R. and Snodgrass, A. (1991). “Is designing mysterious? challenging the dual knowledge thesis.” Design Studies 12:3, 124-131
2. Campbell, John L. (1996). “The development of human factors design guidelines.” International Journal of Industrial Ergonomics 18:5-6, 363-371
3. The Elements of User Experience
   http://www.jjg.net/ia/elements.pdf

For More Information

• IBM’s Ease of Use
  http://www-3.ibm.com/ibm/easy/eou_ext.nsf/Publish/759
• Microsoft’s Inductive User Interface Guidelines
  http://msdn.microsoft.com/library/en-us/dnwui/html/iuiguidelines.asp?frame=true#iuiguidelines_topic1
• Usability.gov’s “Evidence-Based Guidelines”
  http://usability.gov/guidelines/
• Got Usability? Talk with Jakob Nielsen
  http://www.boxesandarrows.com/archives/got_usability_talking_with_jakob_nielsen.php
• Clay Shirky’s “Situated Software”
  http://www.shirky.com/writings/situated_software.html
• Changes in Web Usability since 1994
  http://www.useit.com/alertbox/9712a.html