Most discussion about Web design seems to focus on the creative process, yet turning concept into reality requires a strong set of deliverables—the documentation (concept model, site maps, usability reports, and more) that serves as the primary communication tool between designers and customers. Here at last is a guide devoted to just that topic. Combining quick tips for improving deliverables with in-depth discussions of presentation and risk mitigation techniques, author Dan Brown shows you how to make the documentation you're required to provide into the most efficient communications tool possible. He begins with an introductory section about deliverables and their place in the overall process, and then delves into to the different types of deliverables. From usability reports to project plans, content maps, flow charts, wireframes, site maps, and more, each chapter includes a contents checklist, presentation strategy, maintenance strategy, a description of the development process and the deliverable's impact on the project, and more.
I am a freelance information architect (sometimes called user experience designer or user interface design) who subcontracts to large ad agencies for the design portion of web site creation, usually large-scale b2b and b2c sites. I am fortunate in that I am often exposed to different approaches and uses of design deliverables, but unfortunate in that everyone seems to do it a little differently. I hoped this book -- recommended by a colleague in a different state -- could help standardize my outputs.
It's an interesting mix. I almost primarily focused on the Site Map, Wireframe, and Competitive Review sections -- the bread and butter of what I do for the majority of my projects.
On one hand, I was disappointed that there weren't more real examples, probably because I'm a visual person and am always curious to see what other IA's do.
On the other hand, I was pleased to see the book acknowledge so many of the problems I encounter on a daily basis. I just had a client want to know "how many wireframes" I was creating in my estimate when I wanted the conversation to be about what processes needed to be created for the site. How does the traditional, "linear" structure of site maps translate into today's more dynamic sites, where content is not neatly tucked away in nice little silos? How do you run an effective wireframe review? For a competitive review, do you analyze by feature, or competitor? These are all issues I've encountered within the past month, and they were all addressed. I changed the formatting of my site maps immediately after reading this book!
This is the first book I've encountered that spoke so specifically to the deliverables I produce that part of me wanted even more than the book offered. I would have liked to see even more about collaborating with the development team, particularly with the layout and annotating of wireframes.
Sometimes the book talked about stuff I already knew, and sometimes I wanted more visual examples and just a little bit of color, but this was by far the most specific and comprehensive reference books I have on my shelf currently. This may be a lot for the very beginner to digest. I've been doing this for 11 years, and probably would have benefited the most from this the most about 2-3 years into my career -- when I had enough real-world examples to apply the examples against. Still, there are points here that I find relevant now. I've recommended it to several of my other colleagues so we can all be on the same page when working through design together!
Understanding user experience design principles and concepts, selecting the suitable methods for a specific project, and delivering seamless end-user experiences that align with stakeholder goals are the surface-level responsibilities of UX designers.
However, in reality, and equally important, user experience designers must possess the ability to effectively communicate their ideas to stakeholders, emphasize the significance of user experience design, and articulate the implications it holds for products. Additionally, they must be skilled in creating comprehensive project proposals, UX briefs, research protocols, and recommendations, drawing from their findings. This is what this book “Communicating Design” is all about.
As someone with a master’s degree in UX Design, I soon realized that in the real world, the quality of your UXD is irrelevant if you can’t effectively communicate its significance to stakeholders. I’ve revisited this book countless times since I bought it six years ago, and it has provided me with the confidence and skill set required to persuade stakeholders.
It's a well-written and approachable book about documenting design processes. I'm glad the topic was addressed and it's a great resource and reference when needed, but it's still a book about documentation.
I first read this book in a Digital History seminar I took a decade ago. Just finished re-reading it for a Digital History seminar I'm teaching this year. It remains a fantastic introduction to the process of creating digital web projects.
While the technologies for creating web projects has developed significantly, this book ages well because it focuses on the process and methods of creating various deliverables in a design process. Students often come wanting to make a web site, or create some digital resource without realizing all the techniques and methods that can and should go into informing the development of a project.
Communicating Design continues to be an excellent hand book for thinking through project design and for focusing on what kinds of deliverables need to be produced at what point to get stakeholders on board.
This is the first textbook that I’ve finished reading this year; it was assigned for my Interactive Information Design class. What I really like about it is the way it breaks down all the types of documents it discusses (things like content audits, wireframes, personas, all that good stuff) into three layers of information. So you get a good sense of what actually goes into making any of these documents at a basic level, but also at a deeper level if it’s required for your projects.
The other thing that makes this book great is it provides advice on how to present each type of documentation to clients; emphasizing the areas where meetings can get derailed and suggesting strategies for keeping them on track.
This book has some helpful sections, but altogether I did not find it very useful. The author presents a lengthy and detailed description of how to present Information Architecture project deliverables to clients, but it seemed there were few opportunities for flexibility in the process he describes. If you follow this model, you might end up creating deliverables that look and function like everyone else's. Maybe that kind of consistency is needed. You may decide for yourself.
This is a minor point, but I was also a little frustrated by the differences in nomenclature used in this book and Morville & Rosenfeld's Information Architecture (The Polar Bear book).
Assigned for the course SLIS 5960 - Information Architecture.
This is the least useful book ever written related to the topic of web development. I got mine at a discount price, used, and I still feel cheated. If you're looking for any conceptual tools, flexible frameworks, taxonomical systems, immediately-applicable forms or practical structures for brainstorming and project management, you won't find them here. What you will find is a stream-of-consciousness of what-if scenarios, and tons of illustrations resembling abstract art more than anything else. This book is written to justify ballooning web development budgets: It's "The Art of War" for people who make their living by drawing boxes and arrows.
If you need to present ideas on a web site to others, this is your book. Covers the processes of creating web-related documents in a comprehensive manner. It's focused on the documents, but also lets you know how to approach them, what to watch out for, how they work with each other, and how they fit into the processes of developing and designing a website. It covers each document in a similar way and from a layered approach, rather than a 'always do it this way' style. It's easy to read, but there's a lot of insightful information to go over, so it's not an 'overnight' book.
I read this book mostly for the last section of the book on Design (truthfully, I skipped the first two sections). I was specifically interested in Site Maps and Wireframes. The info was light, and didn't talk as much about the process of creating the maps/wireframes as I would have liked, and when it did, I sorta disagreed with the approach.
I think the biggest disconnect for me was that the book felt like it was focused on being used in a waterfall-based environment, and I lean more towards agile perspectives.
Went through the first 2/3 of the book in an hour. Nothing new for me, but a concise path through documentation of usability and strategy. Slowed down and read through last third on design of site including flow charts and wireframes. I like these chapters better than other books I've read on flow charts.
This one is for those with at least some experience in the web development field. It gets more technical. Lots of detail and personal experience tips from the author.
The author is a geek who loves comics and uses them in example and analogies throughout the book, which I thought I'd find endearing (I like them too), but instead, it was just kind of annoying.
You'd be forgiven for thinking that this book would go out of date very quickly - but I still find it useful. It's well written and full of neat ways of doing things. It's perhaps lacking Lean UX thinking (which seems all the rage these days) and responsive documentation, but the base principals are there for lot of concepts.
Excellent book on a too overlooked subject. Read some time ago but still have it very much dog-eared on my desk. If you didn't the 2nd edition is out, have it can't wait to dog-ear it! Kudos @brownorama (Dan Brown, the author)
good book. useful stuff about personas, segmentation and usability reports and things. for smaller websites you could slip some of these things to v2 if you are coming under time pressure. that could be useful.
Like so many introductory level books, I wish I'd read it sooner. Nevertheless if you're just starting out in UX design, this will walk you through all the deliverables you're likely to create (or encounter) in your work.
한국어로 번역된 책의 이름은 'UX Design communication'이다. 이 책을 번역한 사람이 실무에서 활동중인 분들 이기에 이 책은 실제로 웹디자인을 행하는 실무중심의 디자이너에게 체계적 지식을 제공해 주고있는것 같다. 특히 디자이너의 취약점인 기획을 하고 체계적인 방법을 적용하며 최종 결과를 커뮤니케이션하는 문서작성을 매우 구체적으로 보여주고 있다.
Thourough and solid overview of website design documentation - with excellent heads up on presenting and leading meetings to review said documentation.
The most useful ideas I got from this book were: how to effectively involve stakeholders in the design process, and how to successfully facilitate review meetings.