Is it Straightforward?

“The hardest part of design isn’t doing the design. It’s working with everyone else without wanting to run screaming for the hills.” –Dan Brown

Luckily, while he suggests that collaboration is the most difficult task when doing design, or for our purposes working on any digital project, Brown has answers. Rather than providing suggestions for how to engage in interpersonal relationships, Brown describes how to create documentation—a historian’s dream— to keep a record of the project and to help team members communicate more effectively.

Dan Brown’s Communicating Design: Developing Web Site Documentation for Design and Planning is a how-to book. His intention is to teach his readers how to create and present deliverables efficiently and effectively. He defines a deliverable as a document created during the course of a web design project to facilitate communications, capture decisions, and stimulate innovation. These documents are able to capture ideas, innovation, theory, and concepts at a moment in time, and there are three primary reasons for their production:

• Consistency of vision
• Accountability
• Traceability

The entire team being on the same page—the creators, users, and approvers from the design team to the clients and stakeholders— contribute to the success of the project.

There is evidently theory in the preface and sprinkled throughout the text, but because this book primarily relies on practical advice, the depth of the theory behind this analysis is hidden by the simplicity of the layout and organization. Brown also argues that it can be used with any methodology and utilizing the reader’s choice of tools, making it appear universally applicable. He analyzes ten deliverables in an order based on a standard project timeline. He sorts the deliverables into three categories, corresponding to the divisions of the book into parts. He further organizes his content by dedicating each chapter to a particular deliverable:

• User Need Documents
  • Personas
  • Usability test plan
  • Usability report
• Strategy Documents
  • Competitive analysis
  • Concept model
  • Content inventory
• Design Documents
  • Site maps
  • Flow charts
  • Wireframes
  • Screen designs

That Brown can manage to make these deliverables sound simple to me—a person with no real design experience, particularly any web-based design experience— is a testament to his successful explanation of these principles. The structure of each chapter is identical which is an intentional effort to give the same advice for each deliverable, making the book easy to follow. Each chapter starts with an introduction including a definition. He follows this section with an overview, challenges, the process of creation, presenting the deliverable, and putting it in context. The organization is formulaic and effective.

A particular strength of the book, is Brown’s close attention to personas, referring to the system’s intended users. Brown encourages projects to treat these personas as actual people, featuring profiles and detailed scenarios. This chapter emphasizes, from a design-standpoint, the importance of recognizing audience and who will be interacting with our products. While this might seem obvious to those of us with a public focus to our work, it’s evident that most traditional scholarly work isn’t created with a close eye on “users.” Those which do have a wide-public appeal are lauded as rare beasts. As Public Historians, we do much more of this kind of work, and Brown contributes a useful model for a practice many of us have seen when learning about working with the public on the museum floor or as an interpreter. Taking this experience to the web and making it digital complicates our understanding of the user, and that’s why User-Centered Design is so important—which we hear more about this week from Sara’s blog post.  

As a Public Historian, or any historian interested in doing collaborative work—which digital history often is— Communicating Design reminded me of every major scholarly project I’ve contributed to, particularly of the process of keeping records and sorting documents. In the preface, he emphasizes how the field of web design is particularly guilty of lacking good documentation, and honestly, most projects are. His point is well-taken because it proves difficult to track group decisions and to recognize how those decisions impact the eventual product or outcome without a dedicated effort to this end. These documentation efforts are like the footnotes of a traditional scholarly work. We need to leave a trace of how we came to create a project or future projects will be unable to build on our experiences. By tracking these efforts and creating clear deliverables along the way, a project is better able to defend choices, methodology, and the theory informing their product, and future projects and scholarship will benefit from this endeavor.

This book is straightforward, as a how-to guide should be. The creativity, as we know, is the product of actively doing the work and wading into an actual tool like Omeka, which we see several of our classmates attempting here and here or from Emily’s blog post, checking out digital projects seeking grants. It’s only when we start creating that things start getting messy, but with the structure and methods laid out by Dan Brown’s Communicating Design, maybe our own projects will look a little more straightforward.