SpoolCast: Documenting Design with Dan Brown
Brian Dan Brown interviewed by Jared Spool. Recorded November 25th, 2008.
Christiansen: [music]
Brian: Welcome. I am Brian Christiansen, producer of UIE Podcasts. In this
week's episode Jared speaks with Dan Brown, the founder and
principle at Eight Shapes, a user experience firm based in
Washington, D.C.
Dan is author of the book "Communicating Design: Developing Web site
Documentation for Design and Planning, " which discusses
documentation for usability testing, content inventories,
wireframes, and more.
On that same note, Dan will be presenting "Communicating Design:
Essential Deliverables for Highly Effective Design Teams" at our
Web App Summit, which takes place April 19th-22nd, 2009 in sunny
Newport Beach, California. You won't want to miss it.
And now here is Jared.
Jared Spool: Welcome everyone. I want to welcome you to another interview on the
SpoolCast here. Today I have with me here Dan Brown from Eight
Shapes. He wrote the book "Communicating Design: Developing Web site
Documentation for Design and Planning".
He is going to be presenting at the UIE Web App Summit in April in
Newport Beach, California. Dan, welcome.
Dan Brown: Thank you Jared. It is a pleasure to be here.
Jared: It is great to have you. So, now, you wrote this must-have book
here about the documentation that one needs to communicate great
design to the team members.
In this book it covers a whole varietyÉ you've got site maps,
content inventories, personas, and usability test plans. I have
just got to commend you.
This is like an awesome book. I can't tell you how many times I
have had clients come to me and say, "We need to be communicating
with the rest of our team and we don't know how to begin to get
this stuff down on paper or into our... Should we put it in a wiki
or should we have it online? How should we do this?"
You have really laid out these really nice comprehensive, and I
have got to tell you, good looking diagrams here.
Dan: Well thanks. The motivation came from having... I had to think
about documentation for so long. My history is filled with working
on very large clients, very large projects; lots of stakeholders.
While I think a lot has happened in the three years since I wrote
the book, that a lot of us still face these problems; multiple
stakeholders, very complex projects. As much as new technologies
can help us do those things, we still need simple and elegant ways
to communicate to all of those stakeholders. So, I hope it remains
relevant.
Jared: I think it is. One of the nice things I like about your book and
all your diagrams is that the diagrams are clear, they are concise,
and they are professional looking, right?
It doesn't take a lot to make a professional looking diagram. You
just have to have a consistent layout and a good sense of sticking
with a font and making it not be Comic-Sans.
Dan: Yes!
Jared: But, it is really nice because I think it is hard for people to
take design of this type serious, but then when they see these
professional diagrams they realize, "Hey. There is something to
this."
It is not just, "Hey. Let's get something out on the whiteboard and
then we are going to go code."
Dan: I appreciate your saying that. I think part of that comes from the
underlying philosophy of communicating design, that you can break
documentation down into its component elements.
Where I think a lot of people who are working on documents get
scared is they don't know where to begin with respect to creating
those diagrams. So, hopefully the message in the book is, "Start
with the basics."
For each of those deliverables that you mentioned I boil it down
to, "Here are the essential elements that you need to include.
Focus on those."
And then as that story develops, start to add to add additional
layers... layers is a term that I use... layers of information to
build up a more comprehensive or elaborate picture.
Jared: Yeah, it makes sense. It is sort like taking the way maps work. You
think of Google Maps where it just starts with the cities and the
roads, but then you can put on it the terrain. You can layer on top
of that the actual satellite imagery.
Each layer gives you different information. Sometimes just seeing
the road in its abstract form is all you need. Sometimes zooming
into the intersection and seeing which way, where the store
actually is on the side of the street, that is what you need.
Dan: I think it is a good metaphor, because the notion of being able to
present both a broad, holistic picture as well as some of the gory
details, so to speak, or the street level details, we should say,
is a challenge that a lot of design teams face.
They need to communicate the big picture, the overall experience,
to get buy in from... whether it be the marketing department or
whoever maintains sort of business ownership.
But, then those street level details are crucial for the
development team. Ideal documentation should be able to do both of
those things. Good documentation strives to do both and often has
to either strike a balance or identify a means for doing both of
those things; both the broad picture of the US National Highway
System and then digging down deep into what that I-95 corridor
really looks like; just to beat that metaphor to death.
Jared: That is right. We can continue to beat it to death as this
interview goes on.
Dan: Yes.
Jared: We will find other ways to map into that.
Dan: OK. Nice! [laughs]
Jared: OK. Back to reality here. So, the book has like 10 deliverables in
it, right?
Dan: Yes.
Jared: It is sort of like asking you to pick you favorite child, but is
there one or two that stand out in your mind as being particularly
powerful, something that if you have to start somewhere, this is
the place to start?
Dan: It is a really good question. I organized the book around a very
loose methodology. I really tried to stay away from methodology
because that seems much more controversial than the outputs
themselves.
So, the book starts with things like persona and usability testing
and things like that. Honestly the design work and the conceptual
work are sort of the middle chapters there.
The document that I get asked about a lot is concept models, and it
has really emerged as my favorite child, so to speak. I imagine
people who have talked to me before may get sick of me beating this
drum, but the idea behind a concept model is that it shows the
relationships between the important elements of a website.
It provides some initial planning activities or planning outputs
for us so we can start to get our head around, "What are the key
elements here? What are the key living pieces of this site?"
What is advantageous to a concept model is that it doesn't box you
into any particular approach for displaying this information. It
doesn't confine you to just showing web pages or web templates.
The idea is all I am trying to show is the relationship between
different concepts. Those concepts can be as concrete as a specific
web page. It can be as concrete as a specific product type. It can
be a specific person involved in the process.
These end up helping us paint that big picture so that we have that
foundation to start with as we delve into the details, which might
be revealed through wireframes or similar deliverables.
Jared: The concept model, it is really just a way to get that sort of
initial slice. I guess what I am wondering about is do you use this
when you are first starting the design or is this something that
you find yourself updating all the way through the design process?
Dan: It is a great question. I have used it in a number of different
ways. When I was starting at a new government agency, one in which
I had virtually no experience whatsoever, their business model was
alien to me.
The kind of stuff that they dealt with was alien to me. I used the
concept model really just for myself; as I was doing research,
looking at third party sites, just trying to get my head around,
"Who are these people? What do they do? What is important to them?"
A concept model I would pull together different audience types,
different kinds of information that they were involved with.
Because it was a government agency I could look at regulation and
legislation and start to pull those things together and paint those
relationships.
So, at the very simplest it is a learning tool. It is a mechanism
for me to learn more about the domain or whatever it is that I am
looking at.
Your point of, "Do I evolve it over time," I think it is an
opportunity for us to take a first cut at, "What are the kinds of
information on the site? How do those different kinds of
information relate to each other? What might user expectations be
around my ability to navigate this information?"
Inevitably, because it sort of has one foot in design and one foot
in more of a requirements gathering tool, it evolves over time to
the point where I can, by the end of that iteration, look at it and
say, "All right. I have a much better sense now of the kinds of
templates that I need to create and the kinds of interactions that
users might expect."
Jared: OK. So, you are building this thing out and it is showing the
different components of how the various parts of the design relate
to each other?
Dan: Yes. I have been doing a lot of work just in the last 12 months on
product marketing. Big, big high tech companies that sell very
complicated products.
At the core of that information architecture is the product page.
But, there is a constellation or ecosystem of information that
lives around a product. It might be smaller products, so to speak,
that support the product. It may be services that support the
product.
And then there is this whole mish-mash of assets and documentation,
and white papers, and press releases, and all of the case studies,
all of these things that relate to that product in some way.
So using that as, in a sense, the hub that everything else orbits
around, so to speak, the concept model helps me understand the
range of content types that are available and then how people might
expect to navigate from a product to any one of these other pieces
of information.
Jared: So, it would seem to me that one of the really nice things about
the concept model is that you can pick a piece of the model, some
area that you working in, and you can sort of take the deep dive
and build out that portion of the model, leaving the rest of the
concept model general and loose because you are not focusing there.
Then when it is time to focus on another piece you can jump over
there, take a deep dive in the model, just keep growing, and it
naturally extends. Is that a true...?
Dan: Yes. I have definitely used it in that way of, "Let's get our arms
around the bigger problem here and then let's prioritize. Let's
pick out one or two of these concepts where we really need to
generate a new set of templates, for example, " if you are looking
at more of a content focused site, "generate templates around these
things and we can save the rest of it for later."
A concept model may have elements that I don't even ever touch, but
they paint that complete picture. If I am showing the relationship
between, say, a case study and the very people who have to
contribute to that case study, that may be relevant for a content
management system implementation.
But, for me as a designer of web pages it may not be relevant. But,
at least that whole picture is painted so we are all working off
that same foundation, so to speak.
Jared: Is it a diagram that when you are working in a team different
people are building out different pieces of it, or do you build it
as a group?
Dan: It is a great question. My experience has primarily been to use it
as a planning tool for myself. I am continuing to study and explore
how to use concept models in a more collaborative setting or as a
client presentation tool.
Sometimes it works well. Sometimes it doesn't. I think there are
enormous opportunities to build concept models collaboratively.
That is to say, people standing at a whiteboard identifying lots of
concepts and trying to identify how those stitch together.
As I have indicated previously, I think the use of this as a
planning tool is still in its early stages. So, there are
opportunities to explore there.
Jared: Cool. What other tools do you feel are good starting points for
folks that have a lot of power to them and don't often get used?
Dan: We at Eight Shapes do a lot of consulting with design teams to help
them instantiate documentation standards in their practices. One of
the things that we do as part of that process is interview
stakeholders and actually conduct surveys of the design teams.
It has provided us with actually a relatively rich set of
information about design teams do documentation.
One of the interesting pieces that has come out of that is we have
been able to compare people who create these documents, people like
you and me, the designers, and then the people who need to use
these documents, whether those be business stakeholders,
developers, QA, or people like that.
So, we compare between those two groups the level of appreciation
of a document; honestly whether they like the document or not. One
of the disparities that we notice is with flow charts, actually,
where flow charts are maybe not enjoyable for us as the designers
to work on.
The consumers of the documents love them, generally speaking. That
is to say, they tend to rate much higher among business
stakeholders, IT folks, because I think, like we were talking about
before with the maps, they paint that big picture to set context.
As a designer, I think my partner, Nathan, has made this point,
which I appreciate, which is, as designers we're mired in the
details and we have that big picture on the back of our heads at
all times, presumably, but people who are not necessarily as
involved day to day with a project, may need a reminder about that
big picture.
And so something like a flowchart, which I should probably define
formally for you, can provide that big picture, a view of: here's
the overall experience, here's the overall interaction for this
particular task. And then once we dig into the wireframes, we have
that context.
Jared: When I think of flowcharts, I think of well the 1970's. [laughs]
Dan: Yes.
Jared: You know these big honking things with diamonds for decision points
and you represented output as something that looked like a tore off
piece of paper and storage was represented by things that looked
like a disk drum, which is probably something that nobody who is
listening to this, remembers what a disk drum was [laughs].
Dan: No, but you know what's amazing Jared, is that language has
survived. When I do my documentation workshops, I'll ask people to
do a flow and I won't give them any examples beforehand. It's sort
of my -- the closest I get to the Socratic method of education,
which is, I'm just going to tell you what a flowchart is. I'm going
to give you an assignment and you've got to invent a visual
language, and people gravitate towards that.
And even if they didn't use it in their own flows, when I put
examples up on the screen, they recognize the symbols and they have
an understanding of what those symbols are. So, they are wholly un-
sexy diagrams, no doubt about it, but there are ways to improve the
visual language, and I've got lots of examples in my portfolio of
how I've tried to take that convention and evolve it to make it
more attractive, or more readable, or more legible, but ultimately,
people get those symbols.
And in a sense that universal language is useful to us because it
allows us to take our ideas and express them in a way, where at
least we can start that conversation very easily with other people
who may not be, again, as mired in the details as us.
Jared: So, one of my memories of doing flowcharts is this really arduous
process -- now in the days when I first started doing them, we
didn't have online drawing tools. So, you did all the flowcharts
with literally plastic template stencils.
Dan: Yes.
Jared: And you would draw out these shapes and you'd write in these stuff.
And my sense was that it was really hard to sort of match the scale
of the detail and where you were in the detail thinking with what
you were trying to communicate.
It's the map problem again. Do I show where every mailbox and sewer
pipe is on every street, or do I give this high level look at the
flow. You could so easily get mired in putting in every decision
point and every question and every little thing, that it was very
easy to lose perspective on what it was you were trying to
communicate.
It was really hard for people who were just getting started with
flowcharting to understand what level of detail their audience
needed. How do you help your clients figure out what's the level of
detail, either in flowcharts or concept maps, or I guess any of
these tools, what's the level of detail that you need to have to
make the communication successful. Because, go to deep, it's a
problem, right?
Dan: Yeah. It's such a great question, because it's so easy. If you
start to think of these documents as people, which sometimes I do,
a little strange, you might imagine giving them too many
responsibilities, right? And so you want to use some caution in
trying to assign any one deliverable too much responsibility
because it won't be able to pull it off, right?
Every document, just like every person, has its limitations. The
advice that I give, and to your point, it's really consistent
across any document that you want to create, is to establish a
purpose for it, which sounds self-evident. But, what we find is
that a lot of people don't apply the same principles that they
would to a design problem to their own documentation.
By coming up with a purpose for the document, what am I trying to
accomplish? What is this document's role in the design process? You
can be smarter about the decisions that you make. It's like a
novelist coming up with an overall theme for his or her story.
Having that theme gives them an anchor, gives them something to
latch onto, so that everything else is in service of that theme.
Everything else is contributing to that message in some way and it
allows you to be ruthless about decision making that you make.
So you can look at it and say, "There's a lot of detail here that's
not contributing to my purpose, so I'm going to leave that out." Or
conversely, "I'm not accomplishing my objective here. I've got a
story that's painted out here, but it's still missing a level of
detail that's required to meet my purpose of, say, be very clear
about the business rules for this particular template. There's
stuff missing here, so I need to add that information back in."
Jared: So do you test your documents like one might test a design? Do you
put drafts of it in front of the audience and say, "Is this working
for you? Tell me what you're getting out of this thing." Basically,
do an iterative process on the deliverable documents themselves?
Dan: I think it's my responsibility as a designer to do that. I think
designers who don't test their documentation, however informally,
are doing their clients and their customers a disservice.
I might even go a step further and even before I've done any
documentation for a project, show documents from a prior project
and say, "This is the kind of stuff I do. Is this going to work for
you?" Because at least you're getting - it's almost like
competitive usability testing right here - sort of getting feedback
on a preexisting format that gives you that starting point.
HAFS doesn't believe that one should reinvent the wheel every time,
but a good standard provides wiggle room to adjust to the needs of
each new problem that you need to face. So, even though we work
from an established set of standards, we also acknowledge the level
of flexibility that we need to make sure that we're meeting the
needs of whomever the target might be.
Jared: OK. So, now you wrote the book a few years back, and it's at this
point you've had a chance to sort of go around and really field
test the book itself, and talk to clients and see how they're using
it. What has changed in your thinking since the book has come out?
Dan: Yeah, it is an interesting question, probably when I wrote it a few
years ago, I never would have thought that my thinking on
documentation practices would have changed. I think there are two
ways to look at this. On the micro level, I might look at each
document again and identify additional elements that are essential
for a particular diagram or particular visualization that I didn't
necessarily include before. So, my opinions on specific documents
have changed.
For example, I think my Competitive Analysis chapter is extremely
robust and there is a lot going on there, that a lot of elements
there that I say are essentially that maybe I would not come down
so hard on that anymore. I think my thoughts on wireframing have
evolved significantly where in the book I called Annotations
Optional are not essential elements, I would probably say today
that they are very essential elements.
But overall, I mean to take a more macro view, I would want to draw
a better bridge between all of these deliverables that in a sense
they all work in concert, the deliverables that one selects as
appropriate for one's project to work in concert to paint an entire
picture. And so, the book treats each document in a very silo'ed
way. Even though I do try and address some relationships between
them, really they need to tell a bigger story.
And the other aspect to it is this notion of documentation
lifecycle which we talk a lot about internally in Shapes. That a
document starts out as one thing and then evolves over the life of
a project and that is not interesting to tell in the book. So, I
think there is sort of more broader organizational issues that the
book is missing, and that I would probably want to revisit. And
then just with each deliverable, there are little, little things
like optional elements or elements that I call essential that maybe
aren't so essential anymore.
Jared: Well, I think you know all those things seem really critical,
particularly the lifecycle stuff. Definitely in the work that we
have done, these documents do - I like that you sort of think of
them as people and that you give them responsibilities, and their
responsibilities change over the life of the project. At the very
beginning, those documents are serving one purpose and then as you
move through the project, they serve a different one and then you
have someone new join the team and then also on the document
service, you had another new purpose.
Dan: Yeah, yeah. And in fact what we find is that people don't create
multiple documents or if they do, they create a very small number
and in fact that they are creating one and allowing it to evolve
with the course of the project.
Jared: Yeah and that makes perfect sense to me. Now you are going to be
doing at the Web App Summit in April, which is going to be in
Newport Beach. You are going to be giving a full day workshop on
some of the documentation tools. Can you talk a little bit about
what you will be talking about there?
Dan: Sure. Well, like I mentioned before with my workshops I try and
take a Socratic approach where I throw people into the fire, so to
speak, and we do some hands-on documentation in class with the
understanding that people are spending no more than 10, 15 minutes
on these things. It does give us a chance to talk through technique
and planning around these documents.
So usually, the way I structure these is I will pick three or four
different documents, will do an exercise around each one and then
discuss them. And I think for the Web App Summit, which seems the
most relevant besides flows and wireframes, which are the ones that
I typically do, I have also done personas in the past, but I would
be curious as to which documents people want to focus on as well.
So, I would welcome some feedback as to which documents are most
top of mind for people these days.
The Web App Summit also gives me an opportunity to inject some of
this new thinking into it. So, identifying not only some new best
practices and techniques around creating effective flows and
wireframes and other documents, but also revisit some of the core
elements and the defining elements that I talk about in the book
and take those to the next level.
Jared: Well, if people have ideas of what they'd love to hear, they could
go to our blog where this podcast is posted. You can get there
uie.com/brainsparks or just click on the blog link on the uie.com
home page and they will find the post for this podcast and in the
comments, they could just put their ideas.
Dan: Nice.
Jared: Yeah, I think that is a good place for that conversation to start.
Dan: I will subscribe to the RSS feed, so I can be immediately updated.
Jared: Well, there you go. If you look at the bottom of the post, there is
a link there where you can subscribe to the comments from the feed.
So, everybody who is following along can follow that in their
reader.
Dan: Great.
Jared: Well, I think this is going to be really a lot of fun to have you
in Newport Beach and this has been really, really interesting. And
again, for those of you who have forgotten since I started the
podcast, we are talking here with Dan Brown and we are talking
about the deliverables that come from design. Dan wrote
Communicating Design, Developing Web site Documentation for Design
and Planning. It is a New Riders book, a great book. I recommend
that you get at least one copy off Amazon, maybe a couple for the
rest of your team and in fact, it makes a great gift.
Dan: [laughs] nice.
Jared: Yeah.
Dan: It is the season [laughs].
Jared: It is, it is [laughs]. This has been a lot of fun. Thanks for doing
this Dan.
Jared: Jared, I had a great time. Thanks for having me.
Dan: OK. Take care everybody. Thanks for encouraging our behavior.
Brian: Don't forget, if you would like to hear more from Dan Brown, be
sure to join us for our Web App Summit, which takes place April
19th through 22nd, 2009, in sunny Newport Beach, California. Learn
more at webappsummit.com. That's all for this week. Thanks for
listening. Goodbye.