78 of 83 people found the following review helpful
For people who work in large web teams,
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.
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
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
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
@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
@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
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 ›