Customer Review

78 of 83 people found the following review helpful
3.0 out of 5 stars For people who work in large web teams, November 6, 2007
This review is from: Communicating Design: Developing Web Site Documentation for Design and Planning (Paperback)
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.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No

[Add comment]
Post a comment
To insert a product link use the format: [[ASIN:ASIN product-title]] (What's this?)
Amazon will display this name with all your submissions, including reviews and discussion posts. (Learn more)
Name:
Badge:
This badge will be assigned to you and will appear along with your name.
There was an error. Please try again.
Please see the full guidelines here.

Official Comment

As a representative of this product you can post one Official Comment on this review. It will appear immediately below the review wherever it is displayed.   Learn more
The following name and badge will be shown with this comment:
 (edit name)
After clicking the Post button you will be asked to create your public name, which will be shown with all your contributions.

Is this your product?

If you are the author, artist, manufacturer or an official representative of this product, you can post an Official Comment on this review. It will appear immediately below the review wherever it is displayed.  Learn more
Otherwise, you can still post a regular comment on this review.

Is this your product?

If you are the author, artist, manufacturer or an official representative of this product, you can post an Official Comment on this review. It will appear immediately below the review wherever it is displayed.   Learn more
 
System timed out

We were unable to verify whether you represent the product. Please try again later, or retry now. Otherwise you can post a regular comment.

Since you previously posted an Official Comment, this comment will appear in the comment section below. You also have the option to edit your Official Comment.   Learn more
The maximum number of Official Comments have been posted. This comment will appear in the comment section below.   Learn more
Prompts for sign-in
 

Comments

Tracked by 4 customers

Sort: Oldest first | Newest first
Showing 1-7 of 7 posts in this discussion
Initial post: Nov 7, 2007 9:59:38 AM PST
The book is about design documentation not project management. I pick this book up every time I need to sort a user flow or annotate wireframes - the information it contains is immediately actionable. I would suggest looking at Scott Berkun's "The Art of Project Management" for tips on how to make (and document) both good and bad decisions.

Posted on Aug 27, 2009 10:13:43 PM PDT
jellyjams says:
Did you end up finding a book like that for a one-man (or woman, in my case) operation?

In reply to an earlier post on Nov 13, 2009 7:19:27 AM PST
antenna says:
Not yet! Feel free to post recommendations in this thread.

In reply to an earlier post on Apr 11, 2011 9:41:32 PM PDT
S. Christie says:
I know what you mean. I am a one (woman) show too, and work in government - it seems like all books assume you have 1) a web team to work with and that 2) ecommerce and getting people to purchase is the most important factor. Neither are true for me. Just wanted to let you knw I feel your pain.

In reply to an earlier post on Jun 10, 2011 10:52:43 PM PDT
carleecomm says:
@antenna, @S. Christie - Me three! Would love to hear of any good book suggestions for project managing a one-person web development/user-centered design operation. I guess, for now, the answer is we just have to read a tonne of books that cover all angles.

Posted on Feb 20, 2012 6:02:52 PM PST
Last edited by the author on Feb 20, 2012 6:27:16 PM PST
solostyle says:
@jellyjams, @antenna, @S. Christie, @carleecomm: Have any of you read "A project guide to ux design" by unger and chandler? I just bought it and started reading it today. It seems to talk more about how a one person UX team could work. There are a lot of agile experience design books coming out this year!! Here is the list:
agile experience design, ratcliffe
user story mapping, patton
agile user experience design, patton
designing with agile, ramsay
lean ux: applying... , gothelf

Keep an eye out for these books!

Posted on Feb 20, 2012 6:14:35 PM PST
Last edited by the author on Feb 20, 2012 6:16:51 PM PST
solostyle says:
hey antenna, you said

"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."

I totally understand--documentation is often so annoying to do that by the time you get to the (b), where you actually describe your reasoning for the design decision and the consequences maybe even of other options that were not chosen, you're about ready to stop writing it and/or stop reading it. But--is there any described documentation that could capture what you're talking about, what you say you need advice on for (b)? Sounds like it would end up being some kind of decision tree or something?

I agree with you about the agile. Designing (etc) more agilely would be nice. I just think that's a different topic. I think you can apply iterative processes to documentation, too. Make each document super short and sweet, capturing main points. It's been a few years. Have you done anything in the past 5 years to develop your own way of accomplishing this? I'd love to hear about your experience.
‹ Previous 1 Next ›

Review Details

Item

4.4 out of 5 stars (39 customer reviews)
5 star:
 (23)
4 star:
 (11)
3 star:
 (3)
2 star:    (0)
1 star:
 (2)
 
 
 
Used & New from: $0.01
Add to wishlist
Reviewer


Location: ex-UK now US

Top Reviewer Ranking: 968,461