Wireframes

Wireframes (Figure 5.13) are a set of documents that show structure, information hierarchy, functionality, and content. They have their roots in architectural drawings and network schematics (in fact, they are sometimes called schematics). Other than prototypes, wireframes are the most important document that interaction designers produce when working on products. (Services don't typically have wireframes. Instead they have service blueprints; see Chapter 8.) Wireframes are a means of documenting the features of a product, as well as the technical and business logic that went into those features, with only a veneer of visual design (mostly just the controls of the product). They are the blueprints of a product. Developers, industrial designers, copywriters, and business people use wireframes to understand and build the product in a thoughtful way without being distracted by the visual or physical form.

Figure 5.13. Wireframes show the structural and functional elements of a product, devoid of visual and industrial design.

Wireframes are tricky documents to create because of the multiple audiences that read and use them. Clients want to see how the design meets their business goals. Developers want to see how the product works (and doesn't workfor instance, what happens when an error occurs) so they can know what they need to code. Visual or industrial designers want to see what visual or physical elements will need to be designed, such as the number and type of buttons. Copywriters want to see what they need to write: help text, manuals, headlines, and so on. And designers want to be able to refer to them in the future to remember details such as why there are two buttons instead of one for a certain feature. Accommodating the needs of these various audiences in one document is the designer's task. The wireframe, like all models and diagrams, is really a communication device.

Wireframes typically have three main areas: the wireframe itself, the accompanying annotations, and information about the wireframe (wireframe metadata).

The Wireframe

The wireframe itself is a detailed view of a particular part of a product. Wireframes can show anything from an overview of a productthe face of a PDA, for instanceto detailed documentation of a particular functionality, such as the volume control on a music editing application.

Wireframes should rough out the form of a product. Form is shaped by three factors: the content, the functionality ("form follows function"), and the means of accessing or navigating to those two things. Thus, the wireframe needs to include placeholders for the content and functions as well as the elements for navigating them (buttons, switches, menus, keystrokes, and so on).

Content is a deliberately vague term that includes text, movies, images, icons, animations, and more. Text, unless it is specifically known or being suggested by the designer (for instance, a button label), is typically represented on wireframes by greeked or dummy text. This dummy text is often the one used by typesetters since the 1500s: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. It's become somewhat of a tradition to use it in wireframes. Other content items are usually represented by boxes with Xs through them and some indicator of what they are, either on the wireframe (preferable) or in the annotations.

Functionality consists of the controlsthe buttons, knobs, sliders, dials, input boxes, and so onof a feature, as well as the product's feedback to those controls. A simple Web site form, for example, usually consists of labels ("Enter your name"), text boxes (where you enter your name, for instance), radio buttons ("Male? Female?"), check boxes ("Check here to join our mailing list!"), a Submit button, a Cancel button, and error messages ("You forgot to enter your name!"). All of these need to be documented on the wireframe.

There also needs to be a way to find and use the content and functionality: navigation. Navigation can consist of any number of methods, such as hyperlinks, simple drop-down menus, toolbars with widgets, and complex manipulations in physical space. On some mobile phones, for instance, pushing the cursor key down while pressing the star key locks the phone. On a digital camera, to view the content (the pictures that were taken), the user may have to change the mode of the camera and then use buttons to flip through the photos.

All these components should appear on the wireframe in a way that shows their general placement and importance. Note that the same wireframe can be used to design many different forms; wireframes can be interpreted in different ways by the visual or industrial designer. What is important is that all the items (content placeholders, functionality, and navigation) needed to create the final product be on the wireframes.

Anything on a wireframe that is not obvious or labeled should have a corresponding annotation.

Annotations

Annotations are brief notes that describe nonobvious items on the wireframe. They explain the wireframe when the designer isn't there to do so. When developers or clients want to know the reason for a button, they should be able to read the annotation and understand not just what the button does, but also why the button is there. Documenting "why" is a challenge, since annotations should be brief. But there is a vast difference between an annotation that says, "This button stops the process," and one that says, "This button stops the process so users don't have to wait for long periods." In the second version, the reader immediately knows the reason for the button. If a change occurs in the process ("The process now takes only a second"), it's easier to see how to adjust the design appropriately.

Here is a partial list of wireframe objects that should be annotated:

• Controls. (See Chapter 6 for a list of controls.) What happens when a button is pushed or a dial is turned or a hyperlink is clicked.

• Conditional items. Objects that change based on context. For example, in many application menus, certain items are dimmed depending on what the user is doing at the time.

• Constraints. Anything with a business, legal, logical, or technical constraint (for example, the longest possible length of a password or the legal reason that minors cannot view certain content).

• Anything that, due to space, could not be shown in the wireframe itself (for example, every item on a long drop-down menu).

Wireframe Metadata

Each wireframe should have information about that wireframethat is, wireframe metadata. Every wireframe should include the following:

• The designer's name.

• The date the wireframe was made or changed.

• The version number.

• What has changed since the last version. Clients like this; it shows that the designer is actively addressing issues that have arisen during the project.

• Related documentation. Any related documentation (ideally with a specific page number) that is relevant to this wireframe: business requirements, technical specifications, use cases, and so on. If there are questions about the wireframe ("Did we really say that the robot wouldn't swim?"), appropriate documents can be referenced.

• Unresolved issues. Are there problems with the wireframe that still need to be addressed?

• A place for general notes. This is the place for the designer to express any final reservations about the productespecially the constraints that affected it. I have occasionally noted where business or technical constraints have had a negative impact on a product and should be addressed. In this way, designers can either argue for changes upon presenting the wireframes, or, if the clients or developers are reluctant to change the constraints, bring them up in the future when complaints arise or another version is planned.