The buzz in the telematics industry lately is centered around why it's not living up to expectations. Ford and Qualcomm recently ended their multi-million dollar telematics joint venture called Wingcast, which was one of the major players in the industry. Two years ago, projections for the telematics market in 2010 were in the $40 billion range; newer studies now put that amount closer to $20 billion. Telematics suppliers are cutting staff, and automotive manufacturers are scaling back telematics initiatives. So what's the problem?

Experts offer a range of explanations: Auto manufacturers and suppliers got caught up in the Internet boom—business plans for new in-car technologies didn't include any actual business, just ways to gain "eardrops" (as consumers were sometimes called). A lack of consumer awareness of telematics products and services has hindered market acceptance. Incompatible development processes—technology products operate in 6-month cycles, while automotive manufacturers tend work in 3- to 4-year cycles—make it difficult to plan production effectively. Currently available technologies do not provide the requisite functionality, and they rarely work well together due to insufficient data communication and hardware standards.

While all of these factors have undoubtedly contributed to the lackluster state of the telematics market, another important element has been curiously overlooked: Much of the confusion about how to make telematics products and services profitable is a result of thinking a single promising technology—voice recognition, WAP, Bluetooth, whatever—is the all-encompassing solution to everyone's problems. But, in fact, it is this kind of thinking that has caused so many telematics products to fail, or simply fail to even get noticed.

Technology-centered thinking is problematic for a number of reasons:

Technology is not a differentiator for consumers

When it comes to driving—or riding in—a car, most people are concerned with getting where they want to go safely, comfortably, and with a minimum of hassle. This (along with style and price, of course) is what people think about when shopping for a vehicle. Aside from perusing the feature list at the dealer, they generally only think about technology when it doesn't work. So, if your telematics offering is driven (pardon the pun) primarily by a technology, it already has a mark against it, because consumers will not be able to see how it is valuable to them. You can offer the most advanced technology in the world in your car, but if it doesn't address the customers' primary goals, they'll look elsewhere for transportation.

Focusing on a technology can be self-limiting

Investing heavily in a particular telematics technology, with the hopes that it will take off by the time the product hits the market—3 to 4 years from when you start development—locks you into supporting that technology come hell or high water. Say you begin development on an in-car broadband entertainment system that works with a single wireless connectivity model. When a newer, cheaper, and more powerful connectivity option comes around, you're stuck. Letting a single technology solution define and control the design of your product prohibits you from being flexible enough to accommodate changes in the market or technology landscape.

A technology-centered approach can take you out of your comfort zone

Telematics products and services involve numerous support infrastructures and components such as wireless connectivity service, complex integrated hardware, software systems, and consumer electronics. Many automotive manufacturers are tempted to break out of their familiar market into these other associated industries so that they can "own" every element of their telematics offerings. But this route is fraught with danger. Such an endeavor demands enormous resources. To "own" the wireless component of your product, for example, you would have to "own" a reliable, nationwide communications network, provide service and support staff and equipment, work within (or lobby to reform) strict government regulations, manage partnerships with competing services, and on and on. If the particular technology you invest in tanks, you'll be out a substantial amount of money, if not out of business altogether.

Equally problematic is the effect extending your brand into unfamiliar realms will have on how your customers perceive you. Like it or not, if you are a car company, people will think of you as a company that makes cars. If you offer a wireless phone service or streaming Internet music under your brand name, you'll naturally make buyers suspicious: "I know I can trust the phone company to connect all my calls; but can I trust a car company for that?" Even if you persuade somebody to buy your phone service plan, chances are you'll still be treading on thin ice—a few dropped calls and that customer will probably cancel her subscription muttering, "I knew it!" Breaking your corporate character just for the sake of attempting to capitalize on a vertical telematics market risks confusing your loyal customers and making potential customers wonder, "What does this company really do?"

Focusing on one technology may mean overlooking other, better options

Centering your development around a single technology may also cause you to overlook other issues and problems that can only be solved using different technologies. No one technology can provide the breadth of interaction mechanisms required to enable a driver or passenger to use a product effectively—and safely—in all situations and contexts.

For example, one technology that is often seen as the key to successful telematics products is voice recognition. Voice-based systems certainly can be advantageous for some tasks, such as hands-free phone dialing, or making a selection from a short list of options. But voice systems also require users to memorize specific commands and options, and by definition have no visual output, which is crucial to successful navigation and manipulating large bodies of information. So, clearly, voice interaction is not appropriate for some tasks, and trying to adapt an inadequate technology to all situations generally ends up making it work well in none of them.

Another similar approach is to consolidate access to features into as few controls as possible. The single-knob control of the iDrive system in the new BMW 745i sedan is one example. The problem with single-knob systems is that the more features the knob controls, the more the user has to concentrate on using the knob to get the result he wants. And when the driver is concentrating on the knob on his dashboard, he's not concentrating on the road. It important to note that, while the iDrive system controls over 700 features, BMW wisely chose to give the most common ones—volume and temperature adjustment—their own dedicated controls on the center console.

Breaking out of the technology-driven development box

Although it is the generally accepted standard, focusing product development on technology can confuse your brand, over-extend your development resources, and, most damaging, produce unsatisfying or unsafe products. Here are a few ways to break away from a technology-centered approach to provide better products and services to your customers.

Design for people, not technologies

The best way to avoid the traps of investing your development efforts too heavily in technology is to start with the people who will use your telematics product: What types of drivers and passengers do you want to serve? What problems do they currently deal with when they are driving? What are their goals? What is the best way you can provide them with the tools and information they need to accomplish those goals? Use the answers to these questions to develop personas, or fictional characters, who represent the needs of the various members of your target market. These personas will help you make intelligent, well-reasoned decisions when it comes to defining and developing your telematics product.

With a solid understanding of the needs and goals of your personas, you can analyze the appropriateness of any potential telematics offering you may be considering before you invest millions in the technology to make it a reality. If your research determines that a product will not fit into your personas' lives—i.e., if it will not make their driving experience safer, more comfortable, cheaper, or more hassle-free—don't built it. The implications of backing out of an expensive telematics initiative before development begins are much less severe than those you'll face later on. A product based upon the goals of real people also eases your sales and marketing efforts when the product is ready for release: you don't have to figure out how to sell a complicated technology to an unreceptive public; instead, you have the luxury of figuring out how to sell a product that people actually want, which is much easier.

Once you've decided to go ahead with your goal-directed telematics product, you can start looking at the technologies available to build it. Personas are useful at this stage too: they can help you validate your technology decisions. If you're not locked into a particular technology, you have the freedom to choose the solution that best fits the goals of the product. As you explore your options, build low-fidelity prototypes or mock-ups of the design as it would function using each technology. Then run through scenarios with your personas (making sure to include passengers as well as drivers) to see which solution fits their context and goals best.

Finally, keep in mind that, while technology changes at a rapid pace, the goals of drivers and passengers rarely do. Again, most people are concerned with getting where they want to go safely, comfortably, and with a minimum of hassle. These goals will be the same in five years as in ten. If you focus on satisfying these goals, rather than pushing your pet technology, you can more nimbly incorporate new technological options as they become available.

Focus on what you're good at

Consumers look to automotive manufacturers to provide safe, reliable, powerful, stylish cars. They look to electronics companies for the latest communication, entertainment, and information products. Be conscious of this distinction, and play to your strengths.

Though it can be tempting to reach for a piece of the huge, lucrative consumer electronics market, avoid stepping too far out of your recognized expertise. Consider starting with telematics offerings that closely tie in with the products and functions you already do well. If, for example, you are a car manufacturer whose vehicles are renowned for their reliability, your customers will be more responsive to a world-class, intelligent diagnostic notification system than to a technologically current, but only marginally useful, in-car Internet browser. This approach may not always be sexy, but if you build a foundation of telematics products that your customers find useful and enjoyable, they will be much more receptive to the more boundary-pushing products you offer down the line.

Also, remember that you don't have to do this alone. There are literally hundreds of corporations out there looking to tap into the telematics market. Find the ones that offer services, products, or technologies that complement your strengths and form partnerships with them to provide your customers with exactly what they need to accomplish their goals.

Compete on design, not technology

Technology is not a differentiator for most consumers, so don't think of it as your competitive edge. Instead, consider technology as the thing that enables you to put well-designed products in the hands of your customers, and let the design of your products set you apart from the competition.

When you describe your telematics product or service to your customers and partners, don't make a list of the technology features it includes, describe how it solves the problems drivers and passengers face in their vehicles. Your customers will see that you've thought about their needs and care enough to provide them with a solution that works. Your partners will see this approach as a signal of your expertise on the matter, and will be less likely to second-guess your decisions or make their own technology-or marketing-centric demands on the product. While it's difficult to tell a compelling, believable story with only features and technologies, it's easy to do it with good design.

What do you think? Join the conversation in Comments

Developing a new product or service is tricky. When everything goes well, the product can redefine a market or even create an entirely new one, to the benefit of its manufacturer and its consumers. When the product doesn't click with its audience, though, the costs—development, employee, manufacturing—can be staggering. How do you ensure that your new product doesn't flop? One effective method is to conduct a requirements definition phase before developing a new product.

Requirements definition simply means "figuring out what to make before you make it." This process is not unique to software products. Architects, for instance, go through a requirements definition phase before they start construction on a home. They talk to the future home owner and determine how many floors and rooms will be in the house, where the bedroom should be, if there's a deck, and so on. Similarly, in the product development world, requirements definition enables you to make appropriate decisions about the functionality and design of a product before you invest time and money developing it. By bridging the gap between the needs of the market and those of your organization, requirements definition significantly reduces guesswork in technology product planning, and helps ensure that business and engineering are working on the same product.

As an example of the value of requirements definition, a former client of ours asked us to design a suite of software for people working in long-term healthcare facilities. During our research phase, in which we interviewed staff in hospitals and rest homes, we discovered a user role that our client had not previously identified. People in this role were critical to the management of these facilities, and we ultimately designed an interface specifically for them. Without the initial requirements gathering phase, our client would have been unable to satisfy this key user group, and thus would have been unable to provide its customers with the solution they needed.

Why it doesn't work to "see what sticks"

Although it seems like an obvious step, requirements definition does not often happen in development processes. Some organizations perceive such up-front research as too expensive or slow, or believe they already have enough of an understanding of their customers' needs. So, they throw technology or functionality at the market to see what sticks. Then they iterate the product until sales targets are met or, just as likely, the product is discontinued. It's possible to get results using this tactic, but the hit rate is very low, and the costs are very high.

One obvious expense is in engineering and production costs: If you throw a bunch of technologies together, you may luck out and produce something people will buy. More likely, though, you'll have to go back to the drawing board continually to rework your product or start over from scratch. Either way, this costs more than if you had shipped a desirable product the first time. Since many companies operate under the mistaken assumption that this approach is ultimately cheaper, they are often unprepared for the recurring, cyclical costs that arise. When they do realize the costs involved, the company is often reluctant to spend more, so the product languishes in its original, sub-par state, which helps neither consumers nor the company's bottom line.

Another, more hidden consequence of the "see what sticks" approach is that it will sooner or later affect your customers' perception of your brand. If you repeatedly release products that are difficult or painful to use or that don't satisfy any real needs, it won't take long for your customers to lose faith in your brand and look elsewhere for their solution. This, in the long run, can be more damaging than an inflated development budget—winning customers back after losing them due to bad design is extremely difficult.

When to define requirements

Clearly, it pays to determine what people need before you start developing a product for them. This is what requirements definition is all about. So how do you do it? Most important is timing: the requirements definition phase must be completed before any substantial development begins.

On a typical development timeline, requirements definition should occur after the business side has decided to introduce a new product (or a new version of an existing one), but prior to any technical or design planning. This natural transition point gives you the opportunity to determine what business and marketing wants the product to be, then match that to the technical requirements and capabilities of the system.

As you define your requirements, it may be tempting to start coding the parts of the product that have already been defined. Don't. Requirements definition and development cannot be done in parallel. Good product requirements describe a cohesive, unified product; if investigation into one requirement uncovers the need to modify another, previously defined requirement, your development team must be flexible enough to accommodate the necessary changes. Major modifications to a product in mid-stream are generally the most painful, and they will cost you time, effort, and money.

The requirements definition phase is complete when you can confidently describe who will use the product and why, what the product must do to meet its users' needs, what business goals must be satisfied, and what the major technical requirements are.

Who should define requirements

Product requirements serve as a bridge between business and engineering, so the people who generate them should sit between business and engineering as well. Technically, requirements definers can be executives, product managers, marketing people, designers, or whoever. Their place within the organization doesn't matter; what does is that they be trusted to fairly represent the needs of the constituent sides of the organization, that they be given an appropriate level of responsibility (to temper their authority—so they have some "skin in the game"), and that they be effective communicators and listeners.

The most likely candidates for filling this role are product planners (incidentally, that's a good title for the job; see Jonathan Korman's article "Putting people together to create new products") or designers, as they tend to have the requisite communication and organization skills and often are already in a position of balancing the needs of the business, engineering, and users.

How to create product requirements

The most important step in defining product requirements is talking to people. This is why it is crucial that the product planner be a good communicator. There are three perspectives from which it is important to get input: business, technical, and user. This step is sometimes called requirements gathering.

To learn the why of the product, you need to talk to business and marketing representatives, who will tell you about the target market and what business needs the product must satisfy. It is also worthwhile to interview any business partners, value-added resellers, or other parties who may have insight into the goals of the product. Talking to these groups should be fairly simple, since most of them are already in your organization. One-on-one interviews or small group working sessions are good forums for soliciting their ideas and concerns.

Next, and perhaps most significantly, the product planner should learn about the potential users of the product. If the product does not yet exist, this group should include people who use similar products (made by you or other companies) or who are in the target market for your product. Talking to users reveals who will use your product and what they need it to do. If, for some reason, you are unable to talk to real users, subject-matter experts can often serve as a useful proxy for customer needs.

User interviews should be qualitative. The intent is not to gather statistics but to uncover the problems and goals of the people who will be using your product and what functionality will satisfy those goals. There are many methods you can use toward this end: ethnographic interviews, contextual inquiry, focus groups or surveys, and so on. These techniques vary in effectiveness, depending on the time available to conduct the research, the type of users with whom you're dealing, and the type of information you're seeking.

Finally, when you know what your users need, interview your engineers and developers to get the technical perspective-the how of the product. Find out what technology resources are available in your organization and if there are pre-existing solutions you may be able to leverage. By talking to developers, you can also gain an understanding of the technical constraints the design will need to accommodate.

Presenting product requirements

Once you've researched the requirements of the various groups within your organization and those of your users, you need to represent your findings in a way that everyone in your development organization can embrace. One approach is to develop personas, which are archetypal characters created to represent the needs and goals of the people for whom the product will be designed. A believable, well-developed cast of personas—including one or more target, or primary, personas—can serve as a rallying point for the product. Defining functionality to satisfy the goals of a real person, rather than an abstract notion of "the user," enables your organization to avoid development roadblocks caused by personal preferences or biases. (For more on developing personas, see Kim Goodwin's article "Perfecting your personas.")

Finally, when you've answered your key questions and you know the why, what, who, and how of the product, you must capture that information in a Product Requirements Document. The PRD represents the first in a trio of documents critical to successful technology product planning (see diagram).

Once a product idea is generated, it is important to document the relevant requirements and specifications at each stage of development. This helps ensure everyone in your organization is on the same page—literally and figuratively—throughout the process.

The PRD is where you actually define the requirements of the product. The document itself can take many forms, but it should always include compelling descriptions of why the product is being developed (business and marketing goals), who will use it (personas and their goals), what functionality is required of the product (persona needs), and how it will be built (engineering goals).

The PRD need not be perfect. It is impossible to accurately specify every detail of the product before development begins. Many times, technical implementation can illuminate new, better ways of doing things—but only if everyone is working within the defined overall direction provided by the PRD. When generating product requirements, the high-level model of the product must be correct; if it's sturdy, everyone can use it as a guide, and lower-level details can change without rocking (or capsizing) the boat.

Incorporating requirements into the development process

When the product requirements document is complete, and the appropriate people have signed off on it, the design of the product can begin. With a PRD that provides a clear roadmap, business and marketing can be confident that their sales and company growth goals will be addressed, while engineering can be assured that development will proceed without any surprises down the line. Completing a successful requirements definition phase may require more time at the beginning of the development cycle, but the investment pays off in development savings and in the marketplace. Ultimately, requirements definition will produce better products for both you and your customers.

What do you think? Join the conversation in Comments

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
         -   Elements
         -   Behaviors
    -   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.

What do you think? Join the conversation in Comments