Documents as Prototypes: Designing Written Drafts for Communication across Cross-Functional Teams

Feature by Carrie Clegg

Many of us are familiar with the old adage, "Too many cooks spoil the broth." As professional communication projects become increasingly driven by cross-functional teams, the wisdom of this expression becomes more apparent: the more people you get involved representing different areas of expertise, the harder it becomes to effectively communicate across disciplines. This is essentially the problem Nick Bryan-Kinns and Fraser Hamilton address in their paper discussing the use of visual prototypes as a communication vehicle within interface design projects. [1] Their conclusions, while of particular interest to those intimately working with a product's design, can be reapplied to assist writers during the document review process.

Today's complex application development processes require input from throughout the organization, posing new challenges for cross-team communication and cooperation. Similarly, documenting these applications requires writers to forge new relationships that may not follow traditional organizational boundaries. Each new project requires that we understand all of the involved stakeholders, and how to best communicate new ideas to each of them. Bryan-Kinns and Hamilton explore the particular challenges involved in communicating visual representations (prototypes) of a product to various parties; these may include HCI designers, programmers, graphic designers, clients, end users, and so on.

Choosing the Appropriate Kind of Prototype

Numerous people, including Bryan-Kinns and Hamilton, have argued that presenting prototypes too highly detailed too early in the process can be detrimental to successful product development. In addition to the increased time and money spent, high-fidelity prototypes often lead clients to focus on smaller details when feedback is still needed on the overall conceptual design or layout [1, p95]. Furthermore, some clients may feel "locked in" to a particular design once it appears polished; they are more open to providing useful feedback when it is obvious that additional revisions will occur.

The risks of presenting a prototype too underdeveloped, on the other hand, are equally problematic when trying to communicate a design, although for possibly more obvious reasons. If a user is asked to respond to a prototype's functionality, but cannot adequately interact with or understand the system, meaningful feedback collection will be difficult.

In considering these potential risks, Bryan-Kinns and Hamilton examined how prototypes were currently being used and where communication and cooperation were routinely breaking down. Based on their observations, they conclude that there are three key "dimensions" to keep in mind when developing prototypes:

Target Audience: To whom will the particular prototype be presented? This can range from close team members within a workgroup to application developers to external clients and users.

Development Stage: What stage in the overall development cycle will the prototype reflect? For example, is the team still gathering initial requirements or is beta testing well underway?

Prototype Fidelity: How "finished" does the prototype behave and/or appear? Low fidelity prototypes could consist solely of rough pencil sketches of an interface, while high fidelity prototypes tend to reflect a more polished design and functionality. Fidelity can also be thought of as accuracy; that is, a high fidelity prototype implies that it is highly accurate in terms of modeling the finished product.

Once the appropriate Target Audience and Development Stage have been identified, we can make a more informed decision regarding the most effective level of fidelity. Other factors affecting this decision will of course include the amount of time and money budgeted to the prototype's creation (assuming higher fidelity prototypes cost more and require more time to develop). Essentially, the farther removed the audience is from your team (increasing from internal to external) and the more developed the product is (increasing from requirements to testing), the higher fidelity a prototype should be. Figure 1 plots sample scenarios, illustrating how the fidelity level might be affected by the audience and development stage:

Applying Fidelity to Documents: Drafts as Prototypes

Certainly, a clear understanding of how different types of prototypes are better suited to different types of situations will improve communication amongst stakeholders. But how can this solution help those of us whose cross-functional team projects consist mostly of written documents, such as manuals, brochures and the like? How can we best present our drafts and ideas to coworkers and clients so as to solicit the most effective feedback?

Compared to those presented to designers, writers tend to have fewer options at hand for controlling visual and functional fidelity. A low-fidelity draft of a document would essentially consist of a hand-written outline, which could potentially appear unprofessional to teammates and could be mistaken as someone's personal notes. However, once the same sentences are neatly presented in a word processing application, we run the risk of appearing too "polished", or too high in fidelity. The difficulty lies in determining the proper middle ground for effectively communicating the document's content to all those involved in making the project a success. This is where our newfound understanding of the prototype dimensions could prove beneficial.

I recently was responsible for writing documentation for an ebook company, assisting their publishing partners transition smoothly to the company's new content management system. Internally, the assignment required cooperation from throughout the organization: the engineering team needed to verify that the documentation accurately represented the system, various managers wanted to make sure their products were properly integrated, and, finally, marketing had to verify that the document aligned with the company's overall branding and messaging. Externally, we had to ensure that the document met the needs of the audience Ð both existing publishing partners who were already deeply entrenched in the existing infrastructure, as well as new publishers with no experience with the system, past or present.

I sent my first draft, neatly formatted, to several engineers and managers, along with a request that they review the content for accuracy. Feedback was limited and very mixed. Comments were often more concerned with grammar and punctuation than overall content. I had fallen prey to the problem of presenting a "prototype" that was too high in fidelity (in this case, a too-finished draft). The next time I sent a draft to my coworkers, I presented it within the body of an email message, and included only the sections on which I wanted the individual recipient to comment. For example, rather than sending a lengthy draft to a programmer, I might extract a brief, bulleted summary of the section in question. This approach did indeed produce a more engaged response. The prototype of the document was now at a more appropriate fidelity level to correspond to the stage of the overall project as well as the role of the audience, and therefore better met the reader's expectations.

Conclusion

Although the concept of a prototype (and its corresponding level of fidelity) is generally reserved for representations of products with complex interfaces, such as websites, software or physical devices, it can be easily expanded to encompass documents and their drafts as well. This allows us to apply existing knowledge of prototyping, such as the recent findings of Bryan-Kinns and Hamilton, to the document development and review process. By considering the current development stage of a document along with the intended audience of a particular revision, we can determine the proper fidelity level for presenting the draft so as to most effectively communicate with the stakeholders of a project, be they coworkers, clients, or the document's end users.

[1] N. Bryan-Kinns and F. Hamilton, "One for all and all for one? Case studies of using prototypes in commercial projects," in Proceedings of Tradition and Transcendence: NordiCHI 2002. University of Aarhus, Denmark. Association for Computing Machinery, 2002, pp. 91-100.