Customer Reviews

Communicating Design: Developing Web Site Documentation for Design and Planning

5 star:		(25)
4 star:		(11)
3 star:		(4)
2 star:		(0)
1 star:		(3)

 

 

If you work in a large team in a big corporation, and use conventional rather than agile approaches to web development, you may find this book very useful. It has advice not just on what tools to employ, when, and why, but also how to interact with clients and specialists in various roles during every stage of website genesis/ontogeny, from strategy to execution (via usability tests, concept mapping, wireframes and much more).

As a one-person band with a very small budget, I found big chunks of it rather idealistic, somehow old-fashioned, and not very relevant to my own circumstances. The usability / market research specialist? The information architect? Those would be me. The programmer? The graphic designer? Oh, those would be me too. And the person making sure that the words and images are suitable for the web as a medium? Me again.

I wanted some advice on best practice for (a) documenting decisions made (and reasons for making them) and (b) highlighting consequences of those decisions (and reasons) for future work. I was quite surprised not to see much discussion about how to document (b), which in my experience is often a huge hole in documentation.

Also, the processes I use are much more agile than those described in the book, which doesn't cover how to document development using agile methods. This is a shame, because I think more and more developers are moving in this direction.

Part of the value of this book is the promise that the author will provide templates and examples. This promise is worth zero. If you go to the companion website, there is a note from the author that says, essentially, "Ooops, so sorry. Got too busy." Just a tad unprofessional? I guess different people have different perspectives on such things.

Call me crazy, but one would think that the author would have had a whole stack of examples and templates BEFORE he wrote the book. How else would he know what documents are needed? Just a rhetorical question.....

The book itself is useful, don't get me wrong. I am just very disappointed in the lack of companion material. Other reviews very adequately cover the content.

In terms of practical help, AND downloadable templates, I vastly prefer Web ReDesign 2.0: Workflow that Works (2nd Edition) by Kelly Goto.

Kelly Goto's advice saved my tail when I was a newbie in the field (waaaaay back in the dark ages of the 20th century), and still has relevance for me today.

Web ReDesign 2.0: Workflow that Works (2nd Edition) (VOICES)

[...]

UPDATE: August 2008: nothing has changed on the companion website, [...] Quite frankly, it looks like it has been abandoned.


UPDATE: February 4, 2010: The author finally has updated the site. However, as of this date, there are still no templates or other downloads as far as I can tell. Looks like the author has turned it into a blog. You might want to check it out and see if any progress has been made. Since Amazon won't allow a web address to appear in a review, you can figure it out from the title of the book.

Dan Brown did it. I never imagined someone would pull it off, but he came up with a meta-web development communication book, a book about the process of putting together user needs, strategy and web design documents. In these three categories, he covers the ten web site communication deliverables he considers to be of most value, taking the reader through a structure that will help in the process of conception, construction, presentation to others and context.

I found the concept of Personas he introduced very interesting (and innovative in the web development space) and later picked up a book that specialized on the topic ("The User Is Always Right" by Steve Mulder and Ziv Yaar) to learn more about it. In terms of the rest of the concepts he introduced, if you are a seasoned web producer/development specialist, you may not find most of them to be new, but seeing the whole package in front of you will be useful and refresh items you know to be of importance. If you are becoming acquainted with this area, the book will become a permanent reference you will want to take with you at all times along with "Web Project Management: Delivering Successful Commercial Web Sites" by Ashley Friedlein.

As soon as I picked up this book, I breathed a huge sigh of relief. I've been working with wireframes for many years, and creating them for a couple of years, but it's my experience that everyone does them differently, and so I gratefully welcome an overview of the basics.

I almost don't dare to write this next thing, so unbelieving am I at my good luck, but here are all the documents he covers, filling in holes in my knowledge base:

1. Personas
2. Usability test plans
3. Usability reports
4. Competitive analysis
5. Concept models
6. Content inventories
7. Site maps
8. Flow charts
9. Wireframes
10. Screen designs

As he says in his preface, it's a how-to book. It's a cookbook. It's for people who make the docs, people who use the docs, and people who review the docs.

I'm really excited. Methodology is great, but what a joy it is to just get some basic templates!

If you're a nerd like me, then you feel giddy when someone publishes a cool nerdbook. I have stayed up late reading this book and and filled the margins with notes and stars. Brown gives simple, applicable advice about creating and presenting Web deliverables.

I am impressed with his comprehensive coverage of the entire life of each deliverable and with how he shapes content into the book's practical structure. Brown writes clearly and concisely, and he crafts his content with solid writing patterns that make the book easy to understand and easy to use. He's as thoughtful about the use of the book as he is about the use of his Web documentation.

Brown groups the deliverables into user needs documents, strategy documents, and design documents. Each deliverable is its own independent chapter. Each chapter covers creating the deliverable, presenting it, how to use it in a project, and how it fits with other documents. He prioritizes the deliverable's content so you know which information is most essential. For each deliverable, Brown writes about the challenges one will face when creating the document and presenting it. For example, he writes about how to structure meetings to prepare for and solve common meeting challenges.

This book has helped me because I'm relatively new to Web documentation, but I'm sure veterans will find it useful, too. I highly recommended it.

I found this to be a good handbook for the type of documentation I often create on projects. I think I wanted more focus on the information design aspect of diagrams / tables, etc. - sort of Dan's take on Tufte. This is more of a comprehensive review of what content a particular document could or should include, how to inflect the doc to different audiences/purposes, and when (or if) to use it in a project. That is important stuff, and Dan does a good job of it. Dan also provides some nice commentary on the future of documentation.

Dan Brown's first offering is a practical guide for Information Architects (IA) and other usability and user experience professionals in the web/software design and human factors engineering industries. Because IA is an emerging field, Dan draws from his vast experience to describe 10 typical deliverables that help facilitate the design of useful products.

You may already be familiar with these types of documents, but Dan inspires creativity by showing examples of each type of deliverable. In addition, he provides a focus for each section by explaining the purpose of the deliverable, its intended audience, level of effort to produce the deliverable, context (when should it be produced in the development process?), and format (what might it look like?).

I won't outline each type of deliverable here because you can simply view the table of contents, but I will say this...After owning the book for less than a week, it sits right beside me at work. A few days after receiving the book, I was asked to create a content inventory of a particular web site. The practicality of the book helps me focus on what information I should be communicating to my intended audience and the examples spark ideas to make my work product better.

This isn't a book to tell you how to do your job, but it is a book to help you effectively communicate with a diverse group of stakeholders so that the resulting product fulfills its requirements and results in a high ROI.

I love this book! Brown definitely knows his stuff, which makes sense since he talks about deliverables and documentation, you'd think he would know how to write a book about communicating his ideas to an audience. Awesome job Mr. Brown. Thank you for coming up with this gem! It has templates galore to keep your project organized. I'm a librarian so I have read many, many books that talk about information organization, but this book stands out because the information and samples make you think of your particular project. The reader is prompted to consider details that most books overlook or assume the reader already knows. Can't wait for the next book by this author!

I found Dan's book just as I was beginning a new job as an information architect. Although I've done this work for a number of years, I found that he had some great tips on just about everything--from constructing a wireframe (how much detail, what to include, etc.) to the most strategic ways to do a wireframe walkthrough with a team. I appreciate Dan's common-sense, real-world approach.

When upper management starts using the phrase "best practices" near your office, keep this book handy. Mr. Brown has written the authoritative work on how to document your IA work and - perhaps more importantly - how to present your work.

The sections on presentation and getting buy-in alone are worth the price of admission.