Although Dan Brown’s Communicating Design: Developing Web Site Documentation for Design and Planning may not be as thrilling as the other Dan Brown’s The Da Vinci Code, it serves as a great tool for historians interested in understanding what goes into designing a successful website.
Brown’s book, much like the author, is not focused on history. Brown is writing this book as a website designer interested in documenting how and when aspects of a website come together. Although this knowledge may not be necessary for the traditional historian, using his suggestions may help get history in front of more people in a more digestible way. Brown focuses on design documents rather than the design process, as he believes these documents are important to create a consistent vision, provide visual insight, and allow for the accountability of a team/project.
Deliverables, according to Brown, are documents that allow help to push the website narrative forward by communicating the design, explaining the ideas, and orienting the content in the larger project. These deliverables allow for a unified vision to be permeated throughout the website so all participants (team, company, client, user, etc.) will have a fruitful experience. By breaking deliverables down further, Brown dissects the purpose behind each document, something he argues is crucial to the success of that deliverable.
One of those dissections leads to a discussion about personas. Personas are fictional people that “express what users need and what they expect” from the website. Although personas are an aggregation of users, Brown suggests that designers think of the personas as real individual people who will use the web site – give them real names, describe them, analyze their behaviors. Using these personas as a tool to better understand how users will interact with the site will inevitably lead to more successful documents.
These personas, though fairly controversial in the web developer sphere, are perhaps the most significant takeaway for a public historian. Public history, simply put, is history made for the benefit of the public, often with the public. Websites, unlike brick and mortar history outlets, have an almost infinite community that they have to tailor their work to. Personas allow a public historian to literally put names and descriptions to people who may stumble upon their work in order to create a website that is useful for them. When used correctly, personas can be used as a way of involving the public in the creation of a historical website, though a team or individual needs to be aware of biases they may have.
The equally important (for designers, maybe not public historians) are the more design-oriented documents. These documents are akin to the work done by historians in between the research but before writing a large paper – deadlines, outlines, timelines (the holy trinity of ‘lines). They are meant to create a layout all of the components of the website, determine a hierarchy of ideas, and structure the creation process. Considering no two users will interact with a website the same way, these documents help ensure that all pages are evoking a similar purpose.
The third, and perhaps the most boring, type of document are the reviews and reports. These documents analyze how successful the website is at doing what is indented to do through determining how usable it is and comparing it to other websites. I would venture to guess that these are the most neglected documents in the process, but they could be the most helpful. They point to the gaps in the systems, show how developers can make the website more useful, and demonstrate how others solved the same problem. Like many projects, the developer may be eager to launch the website and move on to the next thing, but these documents hold developers accountable to making sure the website is as effective as possible.
All in all, Brown’s book on Communicating Design can be a great resource for public historians interested in engaging with the online world. I think the greatest strength about his book is the “choose your adventure” feel, where practitioners from all fields can read the standalone chapters to get the direction that they need. For instance, when working on in a team, it may be more important for a public historian to read the chapters on personas and leave the usability reports to their analytical teammate. But, when the public historian is on their own, those usability reports may be the best tool to supplement their deficiencies.
Great connection to public history, Luke! I couldn’t help but think how these deliverables could help us in our Practicum class and communicating with our partner communities. Sure, the audience Brown mentions doesn’t include the stakeholders we would normally address, but the same principles apply. I agree with you that the reviews and reports are likely the most neglected documents even though they are immensely valuable. Earlier in the book (Chapter 2) Brown mentions that he rarely designs from “the ground up” and improves upon an existing site. This certainly happens in the exhibit world!
I also want to comment on Brown’s use of layers (establishing requirements, elaborating relationships, and making ‘em human, for example) in the text. Even though the text was a little difficult to understand, I grasped the concept that each of these processes and approaches have layers that may or may not apply to your position on a team.
Lastly, I feel that chunks of the book are applicable to non-website projects. Do other people agree with me?