Making your design real: The form & behavior specification
This article is one in an occassional series on design documentation. The first article in this series, Bridging the gap with requirements definition, by Ryan Olshavsky, discussed how to document the needs of the user and the domain issues relevant to the design of products. The second article, Turning requirements into product definition, by Jonathan Korman, discussed how you get from an understanding of your users to a vision for an innovative product that appeals to them. The present article discusses how a detailed specification of the form and behavior takes the guesswork out of product development.
Let's say your development organization has embraced design as a key to creating successful products. You've devoted time and energy to creating the perfect, goal-directed design for your product. Your programmers are ready and eager to start putting that design into code. So…now what? How do you communicate your design to your development team, accurately and in sufficient detail? One approach is to produce a Form & Behavior Specification.
The Form & Behavior Specification picks up where the Product Requirements Document leaves off. The PRD captures who will use a product and why it's worth building, and communicates the high-level design that will satisfy users (see Jonathan Korman's article, "Turning requirements into product definition"). After the PRD is complete, the hardware and software interface of the product goes through progressive levels of refinement, until the final design is reached. This Form & Behavior Specification documents that final design in text and graphics. It serves as the definitive guide to what the product will actually look like and how it will behave.
Why create an F&B spec document?
It is customary for builders to work from a blueprint that expresses the final form of what they are building. Most software developers, however, can only dream of such a thing. It is all too typical to be in the position of having to code toward a final destination that nobody has yet laid eyes upon. Detours are inevitable, not to mention the inability to know whether you have "arrived."
The chief purpose of the Form & Behavior Specification is to communicate the design of a product to the developers who will produce it, so that the product is built as intended. Without an F&B spec to guide them, developers must make things up as they go or constantly ask the designer about the interface's behaviors; either way, the process lags, mistakes are often made, and users eventually end up unhappy. In order to be most effective, developers need a blueprint for the product, much like the blueprints an architect produces for a building. The F&B spec is that design blueprint, and it is beneficial at several stages in the development process. It provides a multi-dimensional view of the product in its final state, giving developers a clear target.
Before any coding begins, technical planners can use the F&B spec as the foundation for the Technical Requirements Document, which is analogous to the technical drawings an electrical or structural engineer produces based on an architect's design blueprint. The TRD describes how the product will function technologically, behind the scenes. Using the F&B spec, which addresses all the important components of the product, technical planners can create a plan for precisely how the design must be built.
Similarly, because the F&B spec lays out the whole product up front, development managers can more accurately assess how long it will take to build, and how many people are needed to build it. The F&B spec also locks in the design, which eliminates surprise additions or changes to the product after coding has begun. This saves time and money, and ensures a more cohesive, stable development effort.
During coding, the F&B spec serves as an invaluable reference tool for programmers. All of the key interface elements and behaviors of the product are explained in the F&B spec, so developers can focus on producing clean, functional code, rather than spending time figuring out how the product should look and behave, and how people are going to use it.
The Form & Behavior Specification can also be valuable to non-developers. Technical support personnel, for example, can use it to familiarize themselves with the product before it's released. When the product hits the market, the help desk is ready. Similarly, manual writers can refer to the F&B spec to get a headstart on organizing and explaining how to use the product. Usability professionals have the foundation they need for testing, while marketing and sales folks have an image of the product before it is even built.
What's in a Form & Behavior Specification
The exact content of a Form & Behavior Specification document varies according to the depth and breadth of the design it captures. All F&B specs should include explanations and illustrations of the interface at a level of detail sufficient for the development organization that will build the product. Smaller, close-knit development groups can rely on inter-personal communication to supplement the information in the document, and thus can get by with fairly high-level descriptions of interface elements and behaviors. Large development groups, on the other hand, usually need more explicit, detailed information because individual programmers tend to rely exclusively on documentation to answer their questions. Whatever the case, all F&B spec documents typically have the following characteristics:
A logical structure
In order to be useful, the Form & Behavior Specification must be organized clearly and consistently. The best approach is to imagine "zooming in" on the interface. Start with an overview of each interface screen or major area of the design, then provide progressively more detailed descriptions of the components within each of those areas. If you were describing the interface of Microsoft Outlook, for example, you'd start by explaining that it has six major modes: Calendar, Contacts, Inbox/Email, Journal, Notes, and Tasks. Then you would go into more depth on each mode in its own section of the document.
At every level of the design, you should provide an overview of the concept or interface element, a description of its major components, and explanations of its key behaviors, as in the following:
- Interface Area I overview
- Component A overview
- Component B overview
- Component C overview
- Interface Area II overview
- Interface Area III overview
Detailed illustrations and descriptions of interface elements
The detailed explanations of the interface and its constituent elements—the vocabulary of the design—form the real meat of the F&B spec. When documenting this information, it is important to be both consistent and clear.
Whatever level of detail is necessary for the needs of your development organization, make sure that it is consistent throughout the document. For example, if you describe pixel-level behaviors of one part of the interface, you should describe everything else to that level as well. This may sound like a daunting task, but keep in mind that you usually do not need to describe or illustrate standard interface behaviors like click-and-drag or menu interactions (though you should show and tell what can be clicked-and-dragged and what appears in those menus). A good rule is to describe and illustrate any interface element or behavior that is unique to your design in enough detail that your developers will be able to implement it accurately.
Descriptions of interface elements should be concise and clearly written; typically they are presented as short bodies of text or as bullets. There are many ways to illustrate an interface element, but screenshots (cropped, if necessary) accompanied by text call-outs are usually most effective.
Call-outs can be used to provide short descriptions of key interface elements.
Walk-throughs of key behaviors
Other key ingredients of the F&B spec are descriptions and illustrations of the behaviors of the interface. The best way to communicate these behaviors is to use sequential walk-throughs, which are step-by-step procedures that explain how the persona interacts with an area or component of the interface. Walk-throughs are persona-oriented: they demonstrate each behavior from the perspective of the persona. That is, each step in the procedure is either something the persona does with the interface or something the persona can see the system do in response. (The behind-the-scenes technical behaviors of the system are documented in the Technical Requirements Document.)
Walk-throughs are presented much like storyboards for a movie. Each major action the persona sees is represented by a numbered graphic and a corresponding written description of what happens at that step. Again, it's not crucial to illustrate every step in a process—just make sure all the unique and important actions are shown.
Walk-throughs explain, step-by-step, the key behaviors of the design.
Focus on primary interactions
Although the F&B spec must ultimately account for all the behaviors of the product's interface, it can be time-consuming and frustrating to document (and read) each behavior at the same level of detail. You can optimize the F&B spec by focusing on the interactions the primary persona will most likely encounter. Make sure the document first accurately captures what users will probably do, then account for the possible, but less-likely cases. Secondary interactions can often be noted at the end of a section, in tables, or as conditional steps in the main behavior walk-through.
Appropriate technical discussions
While the F&B spec is not meant to describe the technical implementation of the product, it is worthwhile to include explanations or notes of important technical considerations and implications of the design. If, for instance, your design requires a new technology or new system functionality, explain why and how it is used. Or, if the design utilizes a unique implementation of a standard interface widget, describe how the new widget's behavior differs technically from the standard type. This will help your developers better understand what must be done to properly implement the design.
Additional supporting information
Depending on the scope of your design and the depth of your documentation, the F&B spec may include other useful information for your developers. If there is a visual style guide for your design, for example, include it in the F&B spec. Another valuable section is a list of any open design decisions or implementation issues that are subject to developer input or that were not addressed when the F&B spec was published.
When to produce the F&B spec
You can start the Form & Behavior Specification at any time during the design process, but perhaps the best time is when you have determined the overall structure of the design. You can use the design framework as an outline for the document itself. Then it's simply a matter of progressively filling in the blanks in that outline to a sufficient level of detail. As you write, remember to leave time for reviews of your document, either by your teammates or a trusted colleague. And keep in mind that you will probably need at least a week (more time for larger projects, less for smaller ones) after the design is finished, to make sure the document is consistent, complete, and properly formatted.
The F&B spec is finished when it contains sufficient detail for your developers to begin technical implementation. How do you know? Collaborate with a trusted developer, to make sure you're providing enough information in the way that can be best metabolized by the organization. It may be tempting to hand off chunks of the F&B spec to development as you finish them. Don't. As with the PRD, the F&B spec must be able to accommodate late-stage changes to the design without derailing development. It can be difficult and painful (if not impossible) to make substantial changes to the design once your developers have started to implement it. Furthermore, pulling the development trigger before the design is ready and fully documented weakens the design and detracts from your authority in the development organization—a documented design that keeps changing after coding has begun is not much better than having no design at all.
Who should produce the F&B spec?
The person or group responsible for the design of the product should also be responsible for writing the Form & Behavior Specification. At Cooper, this role is filled by the Design Communicator. Typically, that person will be the designer or product planner in your development group. Ideally, that person has an inclination toward documentation, and is assigned the F&B spec at the beginning of the design process. In any case, the writer of the F&B spec must be a full-fledged member of the design team, and have both authority and responsibility for the success of the design. Because the F&B spec is the design, its author must be willing to take responsibility for the decisions therein. (And if all that sounds exciting to you, chances are you're a good candidate for writing the document.)
The Form & Behavior Specification is a crucial component of successful product development initiatives. Whether you are revising an existing product or developing an entirely new one, generating an F&B spec document will help you make sure your design is fully fleshed-out, help keep your developers on time and on budget, and ensure that your users get the product they deserve.