Adaptive Path Blog

Our friend Jeff Robbins of Lullabot sings the praises (literally) of one of our favorite platforms: The Drupal Song.

It’s pretty catchy, and seriously, no one’s out there writing songs about Vignette.

A few months ago, we wrote about Lane’s Next Move, not knowing what it was going to be, just knowing it was going to be interesting.

Now they’ve announced it. As Lane wrote in the inaugural post on the Get Satisfaction blog, “We’re building Satisfaction because we see the possibilities for collaboration between companies and customers expanding like never before, to the benefit of both parties, and we want to create new tools to encourage and foster this activity.”

I like to think that Lane’s prescient essay from over four years ago, Self-Service Web Applications: Less Cost, More Value, was a planted seed that is coming to flower.

As a fan of good information design, I’ve made a point lately of raving about Google Reader’s trends visualization. Despite my enthusiasm for visualizations of personal data from digital life, I admit to some serious data-envy for the exhaustive analog efforts of Nicholas Felton (of NYC design firm Megafone) and his Feltron Annual Report(s).

I’ve been eagerly anticipating the 2006 Feltron report since I first discovered last year’s, and I was not at all disappointed. From the total number of air miles traveled to a geographical listing of every restaurant eaten at in New York City in the past year, the Feltron reports stand as the most gorgeous representation of personal information I’ve ever seen. The extent to which Felton goes to record his own movements along various axes over such a long timeline is incredible, and the quality of execution — especially typographically — is close to perfect.

The quality of Felton’s work has gotten me thinking about improving personal data visualization in the tools we build.

When Adaptive Path founder (and current Googler) Jeff Veen posted recently about the work he and his team had done with Google Reader’s trends, he expressed excitement for “collecting and understanding the ambient information that flows through our digital lives.” Specifically, he referenced an excellent post by Tom Coates, who elaborates on the value of personal data summaries:

… more specifically I don’t want to know this stuff, I want to be able to capture it invisibly so that it can be knitted together and sense made of it and data made discoverable and searchable at some point in the future, when the urge or need takes me.

For me, Tom’s sentiment (and Jeff’s enthusiasm) clarify something I’ve just started to really grapple with: As we create tools that have the ability to record the wakes of users moving through their digital lives, there is a corresponding obligation to create quality visualizations of that data.

Designers should seek to enable everyone to discover meaning in the patterns of the everyday. What is required is something as complete and concise as it is visually parsable — maybe even beautiful. As artifacts go, the Feltron reports are an exemplar that tools like Google Reader Trends should evolve towards, if not in form, than in spirit.

“We are dealing with human beings, and human beings always need something more than technically proper care. They need humanity. They need heartfelt concern.” (emphasis mine)

– Pope Benedict XVI, Deus Caritas Est

Mohawk Fine Papers has published a book of 40 posters designed for the Yale School of Architecture by Michael Bierut. A small sampling of these stunning pieces are posted over at Design Observer. Points of interest: each poster features different typefaces, an adherence to the simplicity (and low printing cost) of black and white, the use of simple geometric forms to create complex layouts. One poster, for “Non Standard Structures: An Organic Order of Irregular Geometries, Hybrid Members, and Chaotic Assemblies Symposium” was featured in Michael’s talk at UX Week 2006.

Congratulations to Adaptive Path co-founder and good friend Mike Kuniavsky on the launch of the website for ThingM, his new consultancy enabling his passion for smart devices. (And congratulations to his business partner Tod, whom I’ve never met, on the release of his book Hacking Roomba, which I hope is as dangerous as it sounds!) All of us at Adaptive Path which you much success!

Last spring we received an email from a very professional and passionate-sounding high-school junior at the Marin School of Arts and Technology (MSAT). John Bjerke is his name, and he had just signed up for the redesign of his school’s website. He asked to come work with us at Adaptive Path two days a week as he moved through this big undertaking. We jumped for the opportunity, and it turned out to be a great one.

John has just written to inform me that the redesigned MSAT site is live. John deserves some big praise for his work — but to really appreciate it, you should: take a look at its prior incarnation; consider that John took on this huge project by himself; and learn about all John went through to make it happen…

Being a public magnet school that relies on recruiting applicants to build the school’s student base, the web site serves a critical role in the “business” of education. Meanwhile, the site also serves as the online point of contact between teachers and students as well as an information source for parents. Uh-oh: 4 audiences and only 1 designer/developer/project manager.

Here’s the process that John followed to make it possible:

1. Talk to the stakeholders. John started by defining expectations with the faculty and staff at MSAT, as well as the prior caretaker of the site.
2. Know what you’ve got. Next was an exhaustive inventory of the prior MSAT website’s content and inventory. John found a few things he never knew was there. Sound familiar?
3. Learn from the end users. John had users of the site categorize the site’s content and functionality as well as propose names for these categories.
4. Design for the goals of each user. Starting with whiteboard sketches and page mock-ups, John went through multiple iterations of the site navigation and layout to provide pathways for each user to their goals on the site.
5. Criteria-driven visual design. Visual design was something John was uneasy about tackling, so we took a very objective approach. We defined criteria for the visual design, then looked to other sites, magazines, and other sources to inspire the visual direction.
6. Iterative development. Back in John’s comfort zone, he knocked out working code in a number of days, integrating the content with TextPattern as he worked.
7. Strong handoff. After migrating web hosts (ouch), testing, and releasing the site, John’s handed off the content maintenance to two dedicated parent volunteers logged into the Textpattern system as content editors.

We hope and think that John got as much out of the experience as we did. It was a pleasure to watch someone pick the UX methods that made sense to them, plow through the process, and elegantly pull together a series of web-based tools to make it happen.

Wow. What were you doing when you were in high school?
John, thanks for working with us and impressing us.

Brian Oberkirch unearths a podcast interview of Peter Merholz from a looong time ago (March) when you could use the term Web 2.0 without being beaten with wire coat hangers.

Two of the speakers at this year’s UX Week have new books out: Dan Brown’s Communicating Design: Developing Web Site Documentation for Design and Planning and Dan Saffer’s Designing for Interaction: Creating Smart Applications and Clever Devices (both from New Riders). The two Dans recently had a conversation about their books. This is part two. Read part one.

Dan B: Dan, some web designers believe that documentation is a waste of time because it distracts from the purpose at hand — namely, to build a good product. You indicated that Designing for Interaction discusses models as tools for designers. Do you think that models are essential to the design process? Are there other tools that you consider essential to the design process?

Dan S: For me, Dan, models are the design process! Just about everything I do, outside of things like project management, is all about making models. First: modeling the design research in conceptual models and personas. Then modeling user actions in task flows and potential user actions in storyboards and scenarios. Then modeling the design itself in the form of sketches, wireframes, and prototypes. In a sense, to me, all design is about model making.

Part of that is, of course, documenting. It’s in vogue now to shun documentation and go straight to the prototype or even right to building the product. Which is a fine way to work, although it’s not mine. I’m definitely of the “measure twice, cut once” school, because, man, once you get code going or physical models being made, it gets increasingly difficult and expensive to change.

In design school, one of my professors Jodi Forlizzi used to pound into us that the quality of the documentation you make is an indication of your quality as a designer. And although I was annoyed at the time at having to make things like designed CD covers instead of just scrawling a label with a sharpee, I’m come to agree with her. I hate seeing sloppy, ugly deliverables. Whether it’s true or not, it makes me feel that the design itself isn’t very good. I don’t trust the documentation: it doesn’t communicate to me the quality of thinking that went into it. I imagine you talk a lot about this in your book, Dan.

As far as essential tools go, for me the two inescapable tools have been and remain wireframes and prototypes. Wireframes gather up all the thinking–the business rules, the technical constraints, the features and content needed by users, the controls for those features, the states, etc.–that I’ve discovered and brainstormed over how many weeks. They become “the bible” for the product. I’ve found that they get referred to over and over and over again, way more than any other document by far.

Wireframes don’t convey timing, animation, or feeling very well, though. And for those, you need prototypes. Ideas that seem brilliant in wireframes are terrible in practice. And visa versa–stuff I’ve thrown out in the wireframe for seeming too clunky work well in the prototype. Over the last year or so, I’ve been experimenting with low-fi animations made with animated gifs (now that’s old skool!) in order to convey how something should feel and how the timing of, say, a drag-and-drop should be. And some tools you simply can’t experience well until they are working. How can you tell if a drawing tool is going to help you draw until you build it and play with it (and have users test it)?

I’m curious to hear what you have to say about wireframes, Dan. How do you build them using your concept of layered documents?

Dan B: I like your thoughts on modeling because it’s clear that for larger products, it can be difficult to prototype the entire experience all at once. Modeling allows us designers to focus on certain aspects of the product or web site, hashing out obscure business rules or dealing with specific user needs. As you imply, wireframes are a crucial tool for this process.

The chapter in Communicating Design on wireframes is the longest, clocking in at 40 pages. It’s the document that a dozen designers have thirteen different opinions about. In many ways, it’s the ideal layered document because there are so many different kinds of information that you can include in a wireframe.

At its heart a wireframe, as I’ve defined it, displays content and priority–what’s on the screen and its relative importance. These two elements (plus some identifying information) constitute the first layer. That is, the information that makes the document what it is.

Many designers include layout in their wireframes, so the book defines this as a second-layer element. Annotations also appear on the second layer. You can get away doing wireframes without this information, but the wireframes may not be as meaningful for your project team without them. I’ve done some brilliant (if I do say so myself) layout-free wireframes that emphasize priority and functionality, giving the visual designer free-reign over the look of the pages, but the design team needed more direction for layout.

Honestly, I’ve never done wireframes the same way twice. Every project calls for a different focus and emphasis. Some wireframes include detailed documentation of business rules and interactions while others describe the sources of content and production schedules.

A central idea of the book is that designers should not be a slave to our documentation: use it to further the creative process but don’t do it for the sake of itself. If you need to change a documentation standard to accommodate a project’s nuances, so be it.

This is one of the reasons why I wrote the book in the first place. Most design books out there deal with process and methodology, not specifically with documentation. In most of these books, documents are an afterthought and tend to be very prescriptive. These books also neglect how to use the document in the context of a project, so mine also includes a section for each deliverable on presenting the deliverable to colleagues and clients.

Dan S: One quick comment about wireframes before we move on, Dan. It’s interesting that you break up wireframes like that into your layers. I’ve always envisioned wireframes as having three components, which corresponds almost perfectly to your layered approach, although I never thought of it that way. I see wireframes as having three parts: the wireframe itself, the annotations, and the metadata about the wireframe. The metadata (when the wireframe was made, who made it, what changed since last time, issues) would be down on your third layer, I suppose.

Dan B: Perhaps my layers are not what you would expect, Dan. Identifying information is crucial in any document, and should be considered essential–in the parlance of Communicating Design, a first-layer element. Why? If you’ve ever had a stack of wireframes handed to you, you’ll know it’s important to include these bookkeeping elements so you can keep everything straight.

I don’t want to go into great detail here, so I’ll post something on CommunicatingDesign.com that digs into the three layers of wireframes.

Dan S: I totally agree about changing the document to suit the project, Dan. A foolish consistency being the hobgoblin of small minds and all. I’ve thrown all sorts of things into the wireframe: task flows, technical specifications, business requirements, mini-storyboards, screen captures from the existing website, even hand drawings.

But I have to admit, Dan, that I did pretty much what you just said with documentation in my book. “Here’s what this document is for. Here’s what this one is for, etc.” Although I offer up ways to do most of them, I certainly didn’t go into depth on each one or talk about how to present them. But then again, mine wasn’t a book about documentation, more on methods, process, and overviews.

Dan B: A follow-up question to your previous comments, Dan: you indicate that there’s a trend now to shun documentation. I also see that trend, but mostly in the design community itself. Have you had to change how you manage client expectations with respect to documentation?

Dan S: Nope. I have yet to hear a client tell me to provide less documentation. Then again, I try to only give the essentials. At Adaptive Path, we tend to avoid (or at least try to avoid) massive amounts of documentation that no one is ever going to read. If we can get away with a diagram or presentation or set of wireframes, then by god, that’s what we do. We had one strategy engagement in which the deliverable turned out to be a poster. I guarantee that that poster, which reportedly hangs on walls in various client offices, was better understood and used than any standard strategy document would have been.

Dan B: Dan, what inspired you to write your book?

Dan S: It’s pretty simple really, Dan. I taught two semesters of interaction design fundamentals at Carnegie Mellon and never found a book that I felt was appropriate, that approached the topic from in a way that resonated with me and how I worked and was taught. I was putting together chapters from Alan Cooper’s book, and another from Jesse James Garrett’s book, and other articles and blog posts from all around the web: Dan Hill, Don Norman and a host of others. I thought, “This is ridiculous.” So I wrote my own book, and included a lot of those people that I was already drawing on, either simply as inspiration or by including them in interviews.

Dan, I’m assuming you include a bunch of different documentation samples in your book. Are they all yours, or did you gather them from a number of people? If it’s the latter, were there any that really surprised you?

Dan B: Most of the samples I created especially for the book, Dan, though I did solicit some samples from friends and colleagues. The reason you won’t see more samples from other people is purely logistical. I knew it would be difficult for people to secure permission to use their work in a publication, and since I had limited time and resources, I decided to avoid the issue altogether by creating examples from
scratch.

More importantly, as part of the book, I anticipated creating a wiki just for user experience documentation, and I felt this would be a better place for people to share work samples because it’s something that doesn’t have a hard and fast deadline. Additionally, readers should have access to a broad range of examples, and no doubt the web is a better place for that kind of resource.

That said, I did get a few examples, including a site map from James Melzer, a set of wireframes from Stephen Anderson, a content inventory from Sarah Rice, and a workflow from MAYA Design. Todd Warfel sent a photo of personas posted in a meeting room. Jesse James Garrett and the good people at OmniGroup let me use a screenshot of Jesse’s visual vocabulary. Finally, Netflix let me recreate their movie page in a series of wireframes for that chapter. Nothing too surprising: the purpose of the book was to capture the basics of documentation, and it avoided getting into anything too proprietary or specialized.

When I saw your posted interviews, Dan, I had really mixed feelings. On the one hand, I was excited to see such good stuff from some of the industry’s biggest thinkers. On the other hand, I was crushed that I didn’t do anything that cool for my book! Did you find that your interviews corroborated your ideas in the book? Were there any major disagreements between what people said and the design philosophy described in Designing for Interaction? Finally, what surprised you most about the interviews?

Dan S: Dan, I have to thank Peter Merholz for suggesting that I do interviews. I got a lot of great suggestions while writing, but that was probably the best of the lot. There weren’t a lot of disagreements with the philosophy of the book from the interviewees, but then I probably stacked the deck with people I agreed with. Almost all the interviews made me change my mind about something, though. Hugh Dubberly made me realize that systems design isn’t necessarily opposed to user-centered design. Marc Rettig talking about how the seminal moment in interaction design hasn’t happened yet. Larry Tesler on what it means to be an experienced designer. Carl DiSalvo on how robots are both a product and a service. And on and on. I’m honestly flattered these people appeared in my book.

One last question, Dan: When’s the book out?

Dan B: I’m sure the interviews will be a great balance to the concepts you lay out in the book. Another point of jealousy: your supporting website is great! How do you plan, Dan, to extend the experience of the book online? Can we expect ongoing interviews?

To answer your question, Communicating Design should be out any day now. I believe it’s delayed a few days to correct a printing problem found in my advance copy. If you’ve pre-ordered it, it should be arriving in the next week or so. What about you? When can I expect my pre-ordered copy to materialize in my mailbox?

In the meantime, Dan, it’s clear from your personal blog that you need some suggestions for comics. Perhaps when you’re in Washington for UX Week, we can visit my local comic book store. Of course, if you need something to tide you over, I *highly* recommend Warren Ellis’ Nextwave from Marvel. It’s a parody of superhero comics with sharp writing, wicked art, and killer koala bears. What’s not to like?

Dan S: After the interviews came in, I was like, damn, I should do a whole book of interviews! But then I noticed that Bill Moggridge is coming out with a book later this fall that is exactly like that! So oh well.

I haven’t given much thought to how the book will expand online, but I am traveling around with a workshop based on the book. The first locations are in San Francisco and Sydney in September and probably New York in October.

The book itself, like yours, should be out any day now. It’s in warehouses, supposedly.

Great talking to you, Dan, and I look forward to reading your book and seeing you at UX Week! And I’ll have to check out that comic!

Two of the speakers at this year’s UX Week have new books out: Dan Brown’s Communicating Design: Developing Web Site Documentation for Design and Planning and Dan Saffer’s Designing for Interaction: Creating Smart Applications and Clever Devices (both from New Riders). The two Dans recently had a conversation about their books.

Dan S: So Dan, I hear you’ve written a book. What’s it about?

Dan B: It’s funny you mention it, Dan. I have written a book. It’s about documentation for designers, covering ten different types of deliverables. Each deliverable (from personas to wireframes) has a dedicated chapter, and focuses on how to create the deliverable and how to use it in the context of a project. The book avoids specific methodologies or tools and emphasizes the contents of each type of deliverable, and how it serves as a communication tool between members of the team.

I understand your book is hitting the shelves this summer, too. What’s yours about?

Dan S: Well, Dan, mine’s an overview of interaction design, covering everything from its history to its future. I go into stuff like the different approaches to interaction design, user research, the characteristics of good interaction design, interface design, as well as some advanced topics like what’s being called “service design” and designing for adaptation and hackability. And, of course, design tools like wireframes and personas.

Perhaps since both our books cover those, we should talk about those a little. I’ve always felt most people do personas wrong and that’s why a lot of people dislike them. Dan, what’s your take on them?

Dan B: I agree with you, Dan. Many of my clients have a “so what?” attitude toward personas because as documents, personas can require a lot of preparation but have very short shelf-lives. Unless the design team has expertise in leveraging persona information throughout the design process, it’s easy for the document to gather dust soon after its creation.

Since my book focuses on the presentation of information, I don’t spend any time on how to do user research. Instead, Communicating Design provides strategies for preparing documents with whatever information you have on hand using a layered approach. The contents of every deliverable are described in a series of three layers—the first layer having the most essential elements, the second layer having useful details, and the third layer having contextual information. It’s important to understand that for the purpose of this book, layers are meant only as conceptual groupings, not as a visualization technique. In the case of personas, the first layer of information contains elements like the name of the persona and a basic account of the persona’s goals and needs. For the second layer, I recommend direct user quotes and behaviors—information that can make the persona seem more real. If so inclined, designers can also include optional contextual information like a personal background or technical expertise. I consider these to be third-layer elements.

My personal biases definitely show through here. For essential information, I believe personas need to be grounded in user needs and motivations. Demographics and personal background information can be entertaining, but ultimately of little use—even distracting—to the design process. From a documentation perspective, “doing personas wrong” means capturing information that ultimately has little bearing on the design process. The upshot is that a handful of bulleted lists may be all you need for a set of personas.

By conceiving deliverables as a series of layers, designers can focus on the important information first, communicating the essentials and adding further detail as necessary.

Staying on the topic of personas, Dan, how do you recommend designers incorporate users into interaction design projects?

Dan S: Before I answer that, Dan, I want to poke at your layered approach to documentation. Is each layer meant for a different audience, or is each layer about getting deeper meaning out of each document? Are the layers created at the same time, or added on to?

As far as personas go, aside from helping the designer empathize with users, I think they are most useful in three ways: prioritizing features, creating task “pathways,” and for evaluating design solutions. The features of your product need to address the needs of your most important persona, so personas should help determine where design and development effort should go. Next, the behaviors that should demarcate each persona should give an indication of how each persona could or would use the product, so you can design towards those behaviors. Creating storyboards and written scenarios using the personas often help with this. And then, once you have a design, you can ask, “Would Elaine use this? Could Roy?” instead of just the generic “the users.”

Dan B: In short, Dan, the layers categorize the different elements of a document by how important they are to the document. Elements on the first layer are essential—without nodes and connectors, for example, you can’t have a site map. You could include groupings of screens and tie-ins to personas on your site map, but these aren’t essential elements to site maps, and depend more on circumstance and specific project need. So though there isn’t a direct connection between the layers and the audiences, you may decide to leave information out of a document because it doesn’t suit your audience. Communicating Design helps designers distinguish between essential and non-essential elements.

As for creating the document, the designer should start with the basic information (first layer elements) and add further elements as needed by the situation and what information they have on-hand. To get back to personas, I describe a photograph as a third-layer element—nice-to-have, but not essential. This means that designers shouldn’t worry about searching Google Images unless they strongly believe that a generic photo of an abstract user will help the document in some way. Frankly, they need to be nailing down goals and behaviors first.

I like the emphasis on behaviors and prioritization, Dan. Your book describes four different approaches to design—user-centered, activity-centered, systems, and genius. In what way do user research and personas play a role in each of these approaches?

Dan S: Dan, user research is usually involved to varying degrees in all of these approaches, except for what I call “genius design.” Genius design is when the designer presumes to know enough about the users and the subject area to simply proceed with designing with little or no validation from research. This happens either because the designer simply doesn’t have the time or resources to conduct research, or simply is uninterested in it.

In the other approaches, we see designers using user research to undercover insights about the users, such as behaviors, environments, tasks and goals. They then take the research data and make models out of it: “things to think with” as the models have been called. One type of model is, of course, personas, because they should be based on research, not on what the designer (or marketing department) thinks the users are or should be. These types of models help designers (and, very importantly, others!) understand what they’ve just witnessed in the research. They are what I (and others of course) call “conceptual models.”

Is this what you call “Concept Models” in your book, Dan, or is that something different?

Dan B: In Communicating Design, Dan, a Concept Model is a variation of the concept mapping technique developed by Joseph Novak for use in education. In concept maps, nouns are connected by verbs, like Owner –> walks –> Dog.

Web designers use more elaborate concept models to illustrate the relationships between the important aspects of a project, like users, stakeholders, processes, documents, systems, or anything else. When I start a new project, I’ll typically use a concept model as an internal document to help me understand all the nuances and different players. As you say, these models may be the result of research, but concept models don’t necessarily focus on users exclusively.

Bryce Glass developed a concept model to describe Flickr. Bryce was kind enough to let me use the illustration in my book. (I’ll never get tired of pointing people to that thing.)

Concept Models illustrate a good general principle throughout the book: documents are flexible, and may be used in a variety of situations. I hope I’ve laid out the book to help people take advantage of this flexibility, and see ways they can use documents that they haven’t used before.

Part Two