As historians, when doing research, don’t we just yearn for some sort of source material that will explain why someone made a particular choice or help us understand why an event unfolded as it did? Documentation in the form of various deliverables is the historical source material that helps us understand the design choices that were made when creating a website. In the first edition of Communicating Design, Dan M. Brown offers a handbook for producing useful documentation to guide a project team through the design or redesign of a website. While the book does seem to be aimed at people designing websites for corporate clientele, there is much of value here for historians looking to create a digital history web project.
Brown discusses ten forms of deliverables, which he breaks out into three broad categories of documentation—user needs, strategy, and design. User needs documents (personas, usability test plans, and usability test results) describe what we think we know or hope to learn about our audience members. The strategy documents (concept models, content inventories, and competitive analyses) flesh out the concepts and ideas behind what will ultimately become the web design. Finally, the design documentation (site map, flow charts, wireframes, and screen design) illustrates how the site will look to and behave for the users. As varied as websites are, it should not be surprising that these documents generally have no set length or form. The information within them can be communicated in different ways (text, images, graphical representations, spreadsheets, etc.) and presented in differing levels of detail. But together, the deliverables help to ensure that the members of the project team are all on the same page in terms of decisions that have been made about the design direction and the assumptions behind those decisions.
While websites are a relatively new means of communicating information and engaging with audiences for historians, particularly those from the academic realm, the intellectual work of creating a website actually has a lot in common with producing a more traditional textual work, such as a monograph or journal article. Brown sometimes refers to this process as “situational analysis,” where you determine the purpose of your endeavor, situate the project in a larger context, and understand your audience in order to ascertain what information to include in your finished product.
Over and over again, Brown stressed that effective communication begins with knowing your purpose. With a paper, you’d start out with your research question. What issue will you investigate in your research? Similarly with a website, what do you hope to accomplish? What experience do you want your site users to have? What problem are you trying to solve? What do you need the website to be able to do?
The audience for your project will in part dictate the requirements of your presentation. This point is perhaps taken for granted in the academic world that we are used to, as we are trained to write for one particular audience, which is presented as the historical method rather than as a single way of writing about history. In academia, you’re writing for the scholarly community, which has a set of conventions shaping what your final product will look like, such as explaining your methodology and evidence, engaging with a body of historiography, and extensive use of citations in a prescribed format. Your professor may impose other requirements—double spaced, Times New Roman 12, one inch margins, page numbers at the bottom center, word length expectations, etc. All of these requirements affect not only the content of your work, but also how your finished product ultimately looks. No professor or journal editor is going to read your single-spaced essay printed in 8-point Comic Sans on hot pink paper no matter how amazing the content is.
With a web project, however, your audience’s expectations won’t be set out so clearly in a style guide or syllabus. You will really need to think about who it is you are trying to reach and what their needs are. This will involve some research on your part, the results of which are captured in what Brown calls “personas.” Personas are a set of representations of the various users of your site, including who they are, their motivations for using your site, and what they hope to gain from their interaction with the site and with your organization. By examining the personas for commonalities, you can identify content priorities and make decisions regarding what to include in your website and what might best be left out.
The contextual strategy activities described by Brown also have analogous elements to producing an academic research paper. Brown suggests, for example, conducting and documenting a competitive analysis to see how other websites in your general area do things similarly and differently and to identify any gaps in what is covered or in actions that can be performed on the sites. The competitive analysis would be akin to the historical literature review to see how other historians have approached the same or similar problem before so that you can contribute something new to the discussion. For a digital history project, it would be worthwhile to check out some existing digital history sites as we have been doing in this class to explore various ways that people have brought history to the Internet, evaluate new tools for analyzing or presenting your content, see what has been successful, and perhaps find some inspiration or think about ways to break new ground.
Continuing with the implementation of strategy, Brown’s discussion of content inventories seems to apply more to existing websites, but basically a content inventory or audit is researching and identifying your source material. Keeping in mind that all of it won’t be used in the final implementation, what is the content that you have that could be used in your website? As you progress with your research/strategizing, you can employ concept models, in which you write out your ideas for your paper or website and explore the relationships among them, often by writing your ideas or key points in boxes or bubbles and drawing lines to connect them together as appropriate. Concept models will help you to develop the underlying direction and structure of your project as it begins to take shape as a tangible work product.
The information gleaned from learning about your intended audience, your resources, and the competitive landscape provides the context for the choices that you make and implement in the creation of your final product. This is where the academic paper vs. web project comparison most significantly differs. For a research paper, you would probably write out an outline, including however much detail you would need to be able to translate that document into an actual manuscript. Brown cites four documents that constitute the “outline” of the website: the site map depicts the overall structure of the website; flowcharts illustrate points where users interact with the website and have various choices to make; wireframes show the basic structure of the individual pages of the site; and screen designs represent how the site will look and feel when it is completed. All of these documents are graphic and non-linear by nature, which may be a bit foreign to historians, but basically the rules of effective communication apply—illustrate your main points clearly and eliminate any extraneous details.
The design deliverables are used by the site engineers to create the actual website, but the design work isn’t complete yet. Ultimately everything points back to the users’ experience, and therefore some usability testing is in order once a website prototype is available. Design adjustments may be in order once you receive feedback from your intended audience. Ultimately, the basis of good design is meeting user need in Brown’s view.
While the book format necessitates that Brown present his ten deliverables in an orderly, linear manner, the process of website design does not happen quite so neatly, as Brown often admits. The first step is always to know your purpose, and the actual design phase doesn’t normally begin until at least some of the contextual work has taken place, but otherwise many of the activities Brown describes happen concurrently and are often presented in the same deliverable. As with writing a paper, revision is the rule. Hence the importance of having good documentation, to record the history of the thought process that went into design choices at various stages of your website project. Wouldn’t it be nice if good documentation existed for everything that we want to understand more about?