When I first started this week’s reading, Communicating Design: Developing Web Site Documentation for Design and Planning by Daniel M. Brown, I asked myself, “With how quickly the internet and technology have changed over the past twenty years, what kind of relevant information can I gain from a book on website design that is over fifteen years old?” As it turns out, my skepticism was unwarranted. This book, a cross between a self-help and how-to manual, provides a wealth of professional and technical knowledge packaged into organized blocks and accompanied by numerous diagrams, examples, and illustrations.
In what ways is this manual still applicable to website design today? In what ways could it not be applicable?
In his preface, Brown states that this book is all about documentation. According to Brown, documentation is a critical part of the design process. Effective documentation provides a history of the site, gets new team members up to speed on the production of the site, shows every major decision made during the site’s development, and gives readers the big idea of the site. It is essential that team members create proper documentation to ensure the smoothness and success of the development process, so Brown wrote this book to help you, the readers, “improve your documentation, providing advice on how to plan your deliverables and use them effectively in meetings and on project.” I personally feel like a lot of the information he provided could be applied to the development of products other than websites.
How has this book influenced the way that you think about your own projects for this class? Are the assumptions Brown makes detrimental to his argument or helpful?
Brown specifies that while his book provides a guide for website design, every situation is different, so he outlines the assumptions he made for the sake of structure. Providing these assumptions is helpful for readers like myself, who have no website design experience, and it bolsters his credibility as an authority on this topic. However, after reading these assumptions, I was left wondering on what he based these assumptions. Of course, it is impossible to provide an answer for every situation, but did he base his assumptions on the most common situations in website development or on his own firsthand experiences? According to Amazon—the only place I was able to find information on his background, Brown has been a consultant on information architecture and user experience design since 1994. Because this book has no sources to define where Brown got his information, I assume that his suggestions are based on his own personal experience and expertise.
How reliable is this type of resource when it is based on only one person’s experience?
This book is extremely effective as a guide because of the rigid structure Brown employs throughout. Brown divided his book into three major sections or categories of documentation: user needs documentation, strategy documentation, and design documentation. Those categories contain three or four of the most prevalent types of documents (one for each chapter): personas, usability test plans, usability test reports, competitive analyses, concept models, content inventories, site maps, flowcharts, wireframes, and screen designs. Each chapter is further broken down into a main idea and definition, an overview of the chapter, instructions for how to create that chapter’s document, how to present the document, and how to place it in context. The sections on creating the document contain three layers: layer one, or the most vital information; layer two, the supporting details “to enhance the document”; and layer three, information putting the document into a larger context. In my reading, I also noted the significance he placed on communication and presentation in each chapter. His tips for presenting were helpful, if a bit reiterative, because he indicates that effective teamwork relies on efficient communication. Another reason for the repetition is that this book could be read as a reference, so readers could pick out the sections that apply most to them and only read those sections.
How useful is this book as a reference or tool for website designers? Which section did you find most useful and why?
One thing I found confusing was the terminology of a document vs. a deliverable. At times, I got the sense that they were the same, but at certain points it seemed like Brown used the two terms interchangeably. He often provided definitions for each of his major terms at the beginning of each chapter. However, while he did define deliverables clearly, the exact definition of “documents” was harder to find.
Overall, I gained some useful insight into thinking about how to structure my own project for this class. I think the section I gained the most useful information from the chapters on user needs. I liked thinking about the different audiences for the proposal I have been drafting, and it gave me some new ways to think about the researching the diversity of my audience.