Flow charts was the first chapter I (re)wrote for the 2nd edition. It is perhaps the best example of the “more illustrations” objective. Using NEADS, a non-profit based near Boston, as a focal point for the flow chart work, I could present a range of examples using the same basic content. This yielded a nice range of illustrations that are (hopefully) easy to compare.
The ZIP archive (~3MB) includes the OmniGraffle file and a PDF with all the illustrations. The figures are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike.
Flow Charts, The Workshop
Can’t get enough flow charts? I’m holding a half-day workshop in Washington, DC on October 15, specifically on how to apply this diagram to the web site planning process.
Here’s what we’ll talk about:
- How to create beautiful and effective diagrams describing the underlying structure of web sites.
- How to use those diagrams in planning web projects and how pictures can make the process more efficient.
- How to “level-up” your skills in flow charting and site mapping.
- How to walk through these diagrams with clients and colleagues.
- A four-hour workshop in a comfortable training room in the heart of downtown Bethesda (October) or DC (November).
- A workbook chock full of examples.
- A chance to win a copy of the 2nd edition of Communicating Design.
The workshops are $299 each, but with early bird pricing you can save 15%!
Communicating Design, 2nd Edition arrived on my doorstep this afternoon, and I am proud of the final product. The book is larger than I thought it would be, perhaps a consequence of working electronically for the last six months. The production quality is better than expected: the new glossy cover gives it a nice polish and the heavy stock makes it a book that will stand up to lots of wear.
Overall, it feels like an entirely new book, which makes me happy because (a) I’ve learned a lot in the last five years and I’m glad the book reflects that, and (b) it was a helluva lot of work!
The back cover describes the major updates:
- An improved structure comprising two main sections: Design Diagrams and Design Deliverables. The first focuses on the nuts and bolts of design documentation and the second explains how to pull it all together.
- New deliverable: design briefs, as well as updated advice on wireframes, flow charts, and concept models.
- More illustrations, to help designers understand the subtle variations and approaches to creating design diagrams.
- Reader exercises, for those lonely nights when all you really want to do is practice creating wireframes, or for use in workshops and classes.
The back cover also includes testimonials gleaned from Twitter, which I’ve repeated here for the benefit of you and my overwhelming ego:
- @jdcoffman: Looking through “Communicating Design” – nifty book about wireframes, site maps, and neato things like that.
- @lynneux: My very own copy of ‘Communicating Design’ just arrived! Such a great book. Now can give back the loaner I’ve been hoarding
- @kevinmhoffman: Each time I start a new deliverable, I reread a little of @brownorama ‘s book and somewhere, a document gets it’s wings.
- @eatmedia: New employees get copies of Dan Brown’s “Communicating Design” a highlighter and a quiz.
- @A_Silvers: Of all the UX books I own, @brownorama’s book might be the one I turn to most often.
- @pboersma: rumour has it you have my copy of Dan Brown’s Communicating Design. Is that true? Can I have it back please?
- @nickf: After a little bit of research, a quote from @brownorama’s book saves the day yet again!
- @billder: Dan put together a great book on a tricky problem.
- @ksilver: once again Communicating Design and Dan Brown to the rescue!
- @jonesabi: @brownorama Thank you, thank you, thank you for writing your book. It has been really helpful today in dealing with clients.
Lastly, I want to call out the nine amazing people who shared their insights, experience, and knowledge, providing side bars to many of the chapters, adding voices that matter beyond mine:
- Tamara Adlin tells us what makes a great persona
- Stephen Anderson politely disagrees with me on concept models and contributed a beautiful example
- I could only include a small portion of the beautiful insights Dana Chisnell provided on usability reports
- Nathan Curtis digs into the planning and management of deliverables
- The flow charts chapter benefits from two sidebars from Chris Fahey, who tells us why “wireflows” rock
- James Melzer offers some wisdom on simplifying site maps
- Personas gets another sidebar, this one from Steve Mulder, who describes how to make personas memorable
- Donna Spencer’s contribution to the site maps chapter explains how to make the diagram “client-friendly”
- Last but not least, Russ Unger provides a side bar for the new chapter on design briefs
I spent this evening reviewing “pass 2,” which is the near-final layout of the book. Here are a couple pages to whet your appetite.
From Concept Models, a page from early in the chapter where I describe the different ways to embellish nodes.
From Flow Charts, much later in the chapter where I describe different ways to expand flow charts to incorporate other kinds of information, like personas.
Like what you see? You can pre-order the book from Amazon.
While this spiffy new cover for the second edition is exciting:
The real news here is that Liz Danzico, a professional through-and-through and a respected voice in the web design community, agreed to write the foreword! I’m grateful for her contribution, honored to share space on the cover with her, and very excited that her words set the tone for the new book.
Tools of choice
These wireframes were created from scratch in OmniGraffle Pro 5.2.3. I downloaded some animal silhouettes to use in the high fidelity version of some of the wireframes. Any photos were taken by me (or my wife).
Illustrating the use of wireframes
The chapter uses these examples to illustrate the difference between high fidelity and low fidelity wireframes and to demonstrate different kinds of annotations. Other chapters make use of these wireframes to describe how they might appear in different kinds of documents.
Download the OmniGraffle Files (8.2MB)
Excerpt: About the Examples
My family has become intimately familiar with The National Zoo in Washington, DC. Just a few stops away on the Metro and free to enter, it is an easy, inexpensive trip for us that doesn’t have to soak up a whole day. It quickly became a favorite of my son’s, and there are some months where we visit more than once.
The Zoo’s newest exhibit is Asia Trail, which includes these adorable bears called Sloth Bears. In one visit to the Zoo last year, I recall standing in front of the Sloth Bear enclosure, pulling out my iPhone with the urge to learn more about them. Reaching for my phone has become a habit, and while I could have looked up sloth bear on WikiPedia, I knew I wanted more:
- The phone should know where I am in the zoo, and bring up the relevant exhibit right away.
- The information about the exhibit should tell me about these exact bears.
- The phone should tell me where I can go next or where (as is always the need) the nearest bathroom is.
The National Zoo iPhone app was born: in my head, anyway. The examples in this chapter have screens from this imaginary iPhone application. (Wireframing challenges remain consistent regardless of the size of the screen.) To demonstrate web page wireframes, however, I’ve also mocked up some concepts for a companion application on nationalzoo.si.edu.
This is the last bit of text I wrote for the main body of the book. It’s the concluding section for the chapter on Usability Plans, a passage that needed serious updating from the first editions.
This isn’t the best bit of writing from the 2nd edition, nor is it the most important. But it is the last bit I’ll do. For a while.
Look for the second edition to be available in September.
The best-laid plans
Gauging the usability of our design work is a method and process undergoing change. Whereas lab-based testing (recruiting participants, bringing them to a lab, watching them use the product) has been entrenched for years, it is being supplemented with other forms of testing. Technologies allow designers to watch people use web sites in real-time, gathering data as it happens. We can recruit people from across the globe, ask them to participate in an unmoderated usability study, and aggregate data across multiple sessions–all from the comfort of our desk.
These capabilities have raised some worthwhile and difficult questions in the design community. How much should design decisions be informed by data? Must we respond to every usability problem surfaced? How much feedback is too much feedback? For years we sought to be closer to the target audience, to be able to watch them in real-time and solicit input. Now that such a technique is a reality, we wonder if we should be careful about what we wish for.
To me, these controversies point to more careful planning, an increasing need to establish the parameters for studying users relative to the product. A document answering some basic questions provides, in a sense, a contract. Everyone on the project should have a shared understanding of what kind of information will come out of a usability study and how that information will be used.
A good usability plan does more than just incorporate some clever script-writing and scenario-building. It establishes a role for the usability test in the design process. It moderates the voice of the user, couching it in a context that helps the project team interpret the results. It positions that input among the countless others the design team needs to accommodate.
In assembling a usability plan, it can become easy to get lost in planning logistics, writing scenarios, composing interview questions. There is a lot to think about. In light of all of it, keeping things focused on the ultimate objectives is hard. And I’m not talking about the objectives for the test (though that’s pretty hard, too). The ultimate objective is informing the design process. A good usability plan must imply, if not articulate explicitly, how the design team will incorporate the results; how they will integrate it into the landscape of the project, treating it not as a stand-alone activity, but as a constant source of feedback and inspiration.
Better illustrations, better examples. This is one of the tenets of the second edition. I’m spending at least half my effort on creating more artwork for this revision of Communicating Design. Each chapter will have a central example that illustrates different points throughout the discussion.
I’ve been wrestling with the illustrations for the chapter on concept models for a couple months. If I’m honest with myself, it’s been more than a year, even before I started working on a second edition. Creating a concept model to describe comics books is a bit of a windmill for this Dan Quixote, and I’ve been tinkering with it for a while.
I love comics and their underlying relationships are infinitely more complex than meets the eye. The complex business relationships, the varying breeds of readers, and the esoteric plot lines make for a rich (if not daunting) domain to describe visually. I’ve finally landing on something that’s good enough to be a vehicle for illustrating the chapter.
A few major revelations since starting the modeling process:
- Initially I left the reader/collector out of the model, probably because I was so focused on the structure of comics and as an avid reader, I am so close to the domain. Someone in one of my workshops pointed this out to me.
- Early versions of the model used lots of binary choices: a concept is either this or that. To strip out some of the visual noise, I created a device that simplified these dichotomies. The ovals (vs. circles) were born out of this device, to keep the concepts compact and easily nested.
- The model lacked a key focal point. I struggled to give comics a single, unifying, Glass-style backbone. In moving the concepts around, I identified this nice dichotomy between the consumption of comics and the business of comics. While perhaps not the most crucial relationships, they to establish a nice framework for the diagram using the most familiar issues. This approach yielded the fat arrows surrounding the model.
- Those arrows became a useful device for highlighting two interior relationships. Authors, artists, readers, and collectors are real, tangible concepts, and their circles got lost amidst the other ones. As the only real people in the model, they help readers to relate to the diagram. Story is also an important concept–it’s familiar and comic books are a storytelling medium. Early versions of the model did not connect the people with the stories. Creating this set of relationships in the center of the visualization gives it a stronger anchor, and a meaningful starting point.
While this is 90% an academic exercise, it’s been a useful mini-project to help refine my thoughts on concept modeling with a challenging domain. Will I continue noodling on this model? Yes. Will it get better? Time will tell. Good thing it’s not for a client project!
What follows is the sidebar from the second edition describing the genesis of the model.
Excerpt: About the example for Concept Models
I love comics, a fact widely known in my personal and professional circles. In 2009 I was introduced to a couple of guys, Ben Scofield and Nick Plante. They also love comics, and we got together to try to reinvent the online comics experience. We didn’t get too far, but I did a bit of concept modeling to help me wrap my head around the complexities of the architecture of comics.
Comic books are an interesting domain because they bring some unique dimensions. For example, the character (like Superman or Spider-Man) is the franchise. Spider-Man can appear in multiple series. This means there are multiple storylines (sometimes intersecting, sometimes in completely different universes) involving the same character. (TV actors can appear in one and only one series at a time, right? The occasional cross-over happens, but we assume that the character remains exactly the same in all appearances.)
Authors and artists play a large role in reader preference. I’ll buy a new comic by Ed Brubaker, just like I’d buy a new novel by Elmore Leonard. The prominence of the creator in movies perhaps has equal weight, but not in television. When was the last time you watched an episode of something because so-and-so wrote or directed it? On the larger comics franchises, writers and artists rotate. Brubaker wrote Daredevil for a few years but has since moved on. Readers may drop a series because their favorite writer or artist is no longer working on the book. (Admittedly, the new team on Daredevil has kept up the pace and tone set by Brubaker, so it remains in my monthly stack.)
Comics also appear in multiple formats—single issues and collections. There is also a substantial corpus of non-superhero comics (sometimes called graphic novels). All these nuances yield a set of concepts with complex relationships that make your intranet look positively flat.
Even if you’re not into comics, the examples should still be meaningful. I don’t geek out too much (that may be the last you hear of Spider-Man and Daredevil), and the concepts are directly relevant to most kinds of entertainment: movies, television shows, music. They should be, therefore, pretty accessible.
Just drafted, the final passage of the introduction. It riffs on an idea that Nathan and I have been kicking around, that it’s easy for deliverables (and the act of making them) to separate the designer from the “real work”. This seems like a good theme for philosophically setting up the practical chapters that follow the introduction.
Caveat: just a draft, hasn’t been through editing yet.
Describing vs. doing
Do documents and design artifacts reflect “real work”? How much progress are you really making on the project by tweaking line weight on a wireframe or typography on a persona? How much does the design vision depend on your formalizing a deck of screen designs or creating PowerPoint presentations about personas?
Documentation can feel detached from the design process. Diagrams are abstractions of ideas that are in and of themselves abstractions. If we need to describe something that isn’t a direct reflection of a screen design (a site map, for example, or a visualization of the underlying assumptions), the documentation can feel even further detached. At least once on every project I push my chair back from my desk and wonder aloud, “What am I doing?” (Basement offices are the best places to wonder aloud. And listen to unpopular music genres.)
These moments of doubt are useful. They keep us honest relative to our process, and force us to renew our commitment to great design time and again. Stepping back and giving documentation a critical eye, I give myself a chance to validate my efforts and make sure I’m contributing to the design in a meaningful way. I look out for at least three things:
- Is the level of effort on the deliverable on par with the utility derived from the deliverable? Spending hours upon hours on a document that won’t see the light of day beyond a single meeting may not be worth it… Unless that meeting is meant to secure funding for the rest of the project. Spending a morning on a document that will drive and inform the design process for months to come may set the stage appropriately, but likely isn’t commensurate with its value.
- Am I having more fun making the document or working through the design problem? I love making diagrams. I love making diagrams that speak for themselves. I love making diagrams so much that sometimes I forget why I’m making them. The joy should be in solving the real design problem. If I’ve lost sight of that context, perhaps my efforts will be better served elsewhere.
- What I can I be doing that better reflects the final product? If I’m working in a diagramming program because that’s what I always do, I may be neglecting another approach that does a better job of demonstrating the design concept. Paper prototypes or animated PowerPoint slide transitions, while “less sexy” than polished diagrams may describe the design idea better.
Just one more philosophical reflection before you dive into the practical stuff. If I were to boil controversies about design methodology down into a single topic, this would be it. Our urge, as designers, is to get closer to the product, to be a craftsman who can effortlessly float between imagining and building. As products, production processes, and demand change, we create a greater disparity between the people who can think of good ideas and the people who can implement them. The urge to get closer to production encourages us to revisit our design processes, techniques, methods, tools, as well as communication mechanisms.
You’re about to read about seven different artifacts and techniques for assembling them into a story. These artifacts, little projects in and of themselves, are abstracted from the final product. Yet, while the final product may not reference them in the slightest, that product depends on these artifacts for its conception, design, and implementation. They are, therefore, open to interpretation, discussion, improvement, and evolution, to best meet the needs of the product and the team responsible for building it. The recipes herein are starting points and guidelines, ready for you to shape them with your own needs, your own circumstances, and your own experiences.
I just wrote this for a new chapter in the book entitled “Pulling It All Together.” I don’t know if it will make it into the published version:
See this scar on my lower abdomen. I’ll tell you what this scar is from. Picture your intrepid information architect on a two-week sprint to prepare a deliverable, a wireframes deck rife with detailed annotations. They were 10-hour days, trying to hit a deadline so the engineering team could ramp up their development efforts. Your gallant information architect had but one gate to hurdle, an in-depth review with a key business stakeholder. The day of the meeting arrives, two hours set aside to walk through the document and solicit feedback.
For better or worse, the stakeholder hadn’t been present throughout the design process, and your handsome information architect was worried. Worried that they hadn’t accounted for every scenario with the business rules on the configuration page. Worried that he could have done a better job designing the acknowledgement screen. Worried that his hair was kind of sticking up in the back.
The stakeholder arrives five minutes late. Your humble information architect demurely fires up the projector to walk through the deliverable, offering a freshly printed version. He directs the stakeholder to flip to the table of contents. After a brief glance, the stakeholder says, “I’m double booked. I got to get to my other meeting. What do you need from me?”
“The politics of hierarchy” was a sub-heading in the site maps chapter of the first edition. Though the slight recursion implied tickles me, it’s the notion that site maps can trigger a discussion reavealing organizational politics that keeps the diagram interesting to me. It’s not just a little strange that some boxes and lines representing web content can force an organization to bare its soul.
Here’s a revamped (though as of yet unedited) version of that section. Enjoy, and let me know what you think!
The politics of hierarchy
Creating a structure for a web site brings out the worst in organizational politics, which is why so many web sites—especially in the early days—were organized around corporate structure. To validate the design of a new structure, you may need to bring all the different players to the table. With teams consisting of people from every part of the organization, everyone frowns at seeing “their” content buried deep in the site while someone else’s content is at the surface.
Your skills as a facilitator will be challenged. The introduction to this book describes with some general techniques for dealing with conflict in design, but here are a few specific to site maps:
- It’s not your content: The desire to “own” something in an organization can overshadow the true need. In this case, while different people may be responsible for creating, managing, and updating the content, it really belongs to the people using the content. If the content is not presented in a way that’s meaningful or legible to them, it doesn’t matter who “owns” it.
- Contrary to vision: A good design process will establish a purpose or vision for each page. This singular summary of what a page is “supposed to do” can be a powerful mechanism for weeding out requests that don’t contribute to that vision.
- Not everything can go on the home page: Stakeholders may wonder why everything isn’t linked from the home page. Your explanation needs to clarify that burdening the home page with a link to every piece of content (or every area) will yield an unusable home page.
- Users don’t enter through the home page: Reminding stakeholders that at least half the entry into their site comes from search, not from visiting the home, can encourage them to think broadly about the role of the home page.
- There are multiple navigation systems: A good navigation strategy includes multiple mechanisms for browsing the site. A single navigation mechanism (say, “topical navigation”) can not realistically provide access to every area of the site.
- Here’s an example…: Use examples (both good and bad) from around the web to show what happens when content and structure don’t play well together. While a web site can’t tell us everything about the design decisions behind it, we can speculate about how it came to be.
It can be easy, as a designer, to dismiss organizational politics: all you can do is point out the problems, not solve them. You’re a designer of products, not a therapist. As described in the first chapter, politics can be an obstacle to project completion or a catalyst for compromise. As designer you can position yourself outside the fray (align yourself with the product or with the target audience, I don’t care) and facilitate the process to do what’s best for the project.