- Format: Kindle Edition
- File Size: 30365 KB
- Print Length: 352 pages
- Page Numbers Source ISBN: 1119971101
- Publisher: Wiley; 1 edition (24 Aug. 2011)
- Sold by: Amazon Media EU S.à r.l.
- Language: English
- ASIN: B005K046UK
- Text-to-Speech: Enabled
- Word Wise: Not Enabled
- Average Customer Review: 4 customer reviews
- Amazon Bestsellers Rank: #340,995 Paid in Kindle Store (See Top 100 Paid in Kindle Store)
Enter your mobile number below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
Getting the download link through email is temporarily not available. Please check back later.
To get the free app, enter your mobile phone number.
|Print List Price:||£30.00|
Save £10.62 (35%)
Communicating the User Experience: A Practical Guide for Creating Useful UX Documentation Kindle Edition
|New from||Used from|
Customers Who Bought This Item Also Bought
What Other Items Do Customers Buy After Viewing This Item?
Top Customer Reviews
I have used the task and persona templates and have been really happy with the results and the users loved it. Would love a part 2 of the book going into other types of deliverable as I feel there is a gap in the market for it.
Not going to change the world, but will definately give you a clear steer as to what you should be thinking about when you create deliverables.
If you already have experience in this field, I would steer clear.
Price: Reasonably priced.
Delivery: Promptly delivered.
Deliverables design is an important skill, so if you take it seriously, make sure this book finds its way into your library.
Most Helpful Customer Reviews on Amazon.com (beta)
Imagine you are a consultant or a UI person looking into a new website or application, or reviewing an old site to resolve some issues. It is this level of early documentation this book is discussing:
*Usability Test Reports
What I found surprising was the detailed instructions on how to create each of these items in various Software programs; mostly Omnigraffle or MS Powerpoint. There was some reference to Axure, MS Word and MS Excel as well, but they were in the minority.
Nearly half of this book (158 pages versus 332 overall) concerned itself with detailed instructions for how to create this documentation in a very specific format.
Since the Omnigraffle instructions were uniquely for an Apple system; 81 pages had instructions that I could not use. Having not had Axure available to me, another 15 were of no use either.
A concern, I have with all this specificity for a format, was, that it may not fit all circumstances. I get that it may been graphically pleasing to present information in this format for various situations, but it is also highly limiting. If you are consulting, their customer may have unique requests. Also if this graphical technique of representing data, was used by a prior consultant, it makes it seem unimaginative or non-customized for the clients circumstances.
Through the book, I did find sections that were repetitive, leading me to consider this a more basic text; however there were some great nuggets.
As an example in the section on Content requirements they appropriately point out the usefulness of testing with 5 users 5 times versus 25 users at the end, this is a time honored Human Factors tenant. Additionally in the Wireframe section, I liked the use of shading to portray visual heat in a section to help with the hierarchy of information. This is a simple way to be sure your locations of information and graphics are doing what they are supposed to.
In summary, this was a basic text on Human factors and User Experience documentation that will provide a framework and some sound guidance on how to design or redesign a site or application for a defined task. It also gives some very particular instructions on how to do this in a few very popular software programs.
* Sometimes well presented, sometimes not
* Not well written
Before going into details, here is the impression that I got from these authors: "We are good at our jobs. We are going to tell you exactly how we do our jobs. Do your job exactly the way we do ours, and you will be good at your job too." I don't see this approach very often in technical documents, but I always cringe when I do.
I have a couple of problems with that approach. Besides the underlying assumption ("we are good at our jobs"), there is an even worse assumption that one size fits all. The assumption that the reader can apply these basic steps as a formula and reach the same results with any client is a scary assumption. Life simply doesn't work that way. In my experience, I can't necessarily apply the same techniques from one client to the next, let alone expect different individuals to apply the techniques the same way. My other problem with this one size fits all approach is that if it were actually true, then there really isn't anything unique about the individual designer--anybody can follow these simple steps and reach the same results--even a caveman could do it.
And I hate to be so critical (and you can see from my other reviews that I'm normally not so critical), but the writing is really disappointing. A decent technical editor (or even diligent self-editing) should have caught some of the basic errors and helped polish the tone of the writing:
"By using decreasing the size of each block, you can more accurately represent the number of visitors on each page."
I make that same mistake all the time. I start a sentence and then the phone rings or someone walks into my cubicle and I get distracted. When I resume the sentence, I don't quite remember where my thought was going and I end up with stuff like "using decreasing". That's why you have to self-edit everything you write, and then if you're publishing it for sale, pay a good editor to try to punch holes in it.
This book spends a lot of time with very specific "how to" or "click here" instructions with various tools. For example, the Wireframe chapter is 106 pages. Of those 106 pages, about 80 of them contain step by step procedures for creating wireframe diagrams in OmniGraffle, Axure, and PowerPoint. That's a lot of pages devoted to very specific instructions, which--if I follow them--will lead me to create wireframes that look exactly like the authors'. But what if I don't use those tools? What if I just use Visio or some other tool? Does that mean those pages are all wasted on me?
And what if I have a different design style than the authors (or what if my client has different tastes & needs)? If I follow these specific "how to" steps, I'm going to end up with a final product that doesn't fit anyone's needs.
I think it would have been a whole lot more useful to present more general concepts and fewer "click here" steps. Tell the reader all about what goes into a good wireframe, but don't tell me how to use the software tools to create the wireframes. I should be able to figure out the tools on my own.
I found it very interesting that a book on user experience design left out such an obvious human factor: the reader's user experience. What exactly is the reader's experience in reading this book? If the purpose of this book were to turn a job over so that someone else could do the job identically and replace the author, then the book serves that purpose pretty well (writing notwithstanding). Otherwise, I don't find this approach to be the right way to teach the topics to the audience.
let me explain a little more about the images/diagrams. The authors put in sample diagrams, but they are so small that you can't read the text in them to get a feel for what's going on. It's great that they put in some "real world" type examples, but I only wish I could read them! In other places they've included photos but the shot is taken at some creative angle and out of focus in parts that it is ridiculous to even attempt to read. For a text-book style document you really want to be able to read the information in the sample shot.
The "how-to" step-by-step on creating the documentation is nice that they include several different options of software. But, really, PowerPoint?! A book like this I would have thought would be showing how to do these things using Visio as an alternative to OmniGraffle. I suppose, though, that almost everyone has PowerPoint so they reduced it to the easiest tool, but I would think that they would want to encourage people to use the best tools for the job. I enjoyed learning about Omnigraffle, as I had not heard about it prior to using this book. But I do think a lot time is spent on the step-by-step instructions with the software when instead the space and time could have been better spent on providing more details and discussion on the user experience topics such as workshop ideas as well as to show diagrams that one could actually read at a font size larger than 1pt.
Overall, I would say that if you're looking for a good introduction to creating UX documentation and a basic intro to UX itself, this is a good book for that. If you're already familiar with the basics of the UX you might want to find something that goes a bit more in-depth on the process rather than spending so much time on creating the documentation. Although, I also have to add that this book would be a good reference book to have on hand when you are tasked with creating UX documentation.
A good collection of Ux techniques and tools and documentation strategies, such as personas, wireframes, sitemapping, card sorting, etc.
Detailed instructions on creating these documents using OmniGraffle, PowerPoint, Axure, and even Excel (!).
Plenty of illustrations, photos, screenshots, etc.
The not great:
Due to the sheer breadth of the topics associated with usability and Ux design, this book can only give a useful-enough introduction to the many different facets. For example, for card sorting, the instructions are sufficient to give it a go and see what happens. However, card sorting in itself is a subject which could be its own book (and is - Card Sorting is one). Requirements elicitation is a tricky field which, again, should be studied in more detail, and uses many types of elicitation techniqies and tools. The other topics, similarly, each come with their own sets of caveats and best practices, which are not treated in detail here.
The best use of this book is to open your eyes to what is available for discovering, communicating and documenting different aspects of Ux design. The illustrations give a good idea of what is involved and the benefits of each technique. Once you've decided what to use for your situation, you can delve into each type of technique with the detail needed from other sources. But this is a good resource for discussing what processes and documents are needed with stakeholders, management, etc.