Communicating design is tricky business. Designers have invented all kinds of deliverables to handle this job, but we continue to run into the same issues over and over again.
First, we forget things. We leave out some small element that, as it turns out, is absolutely essential to making an interaction work, so we need to revise our designs and send out a new set. Second, we run out of time in our busy schedules and never actually get around to presenting the design work to our clients (whether internal or on the other side of the planet). Third, we forget to include a few extra hours in our project proposals for the inevitable questions developers will have as they dig in and start trying to build the deviously brilliant designs we’ve concocted for them.
Fortunately, there’s a solution to this mess. But for several months now, I apparently couldn’t be bothered to tell you about it.
So today, I’m turning over a new leaf. I’m giving away my secret weapon. (But not until the end of the article.)
Introducing the Design Description Document (DDD)
A Design Description Document (DDD) is, essentially, a slide deck that shows detailed use cases alongside wireframes or comps in an effort to detail all the interactions in a design. And it has quite a few major benefits.
Typically, when an interaction designer completes a set of task flow diagrams and wireframes, she ZIPs it up and sends it off to whoever is pounding on the wall for them and hopes everything goes well. This method invariably backfires.
The ZIP gets sent to the boss, and the boss comes back with questions. The ZIP gets sent to the development team, and the developers come back with questions. The ZIP gets sent to the Documentation team, and the writers wait until something is in QA, because they know the final product won’t be anywhere near what you designed, and then they write their Help documents as quickly as humanly possible.
The Design Description Document cures all of this. First, it communicates to the boss how each interaction will occur, so he has no questions. Second, it tells the developers exactly how things need to work so they know what to build and can immediately start cranking it out. Third, it gives the Documentation team something they can start writing about sooner than later. After all, if the developers know exactly how everything needs to work, odds are much better that the final product will be in line with the original design.
Do you see a trend here? DDDs are good for everyone. Oh wait, what about the designer?
Well, DDDs are designer-friendly, too. They take very little time to create, they’re wickedly easy to update, and, well, they can be branded, and what designer doesn’t love that?
And in addition to answering questions, it helps prevent you from making mistakes and sending them to everyone you know. Because a DDD includes detailed use cases (more on this in a few), you have to actually write down the steps to complete each interaction. As you do this, you can continually check the wireframe to make sure each step can be performed as you’ve written it. If not, you probably forgot to add something to the wireframe. Now you can fix the wireframe, update the DDD, and send out mistake-free design deliverables.
The elements of a DDD
The Cover slide (the first slide in the deck) of every Design Description Document includes a few key elements. Here’s the list:
- Client name
- Project name
- Version number of the application
- Designer’s name
- “Last modified” date
Each subsequent slide of the DDD includes a few more essential elements:
- Wireframe for a single screen, or a storyboard for a complete interaction (you will likely need to scale this down to fit it on the slide, hence the inclusion of a full-size version of each wireframe in your design deliverables)
- Detailed, written use cases for each interaction shown in the wireframe or storyboard
- The file name of the accompanying full-size wireframe image (e.g. 01-Homepage.jpg)
- Notes (if needed)
And if you find that you need some extra room for longer explanations, you can always add Notes slides to the equation, either mixed in with the wireframes or at the end of the slide deck.
The low-down on the how-to
To put one of these babies together, you need the right software. Fortunately, it’s probably already on your machine. As I said, DDDs are slide decks, which means you can put them together in Microsoft Powerpoint or Apple Keynote. You could, in theory, also use Adobe Illustrator or even use keyframes in Adobe Flash.
I created templates in Powerpoint and Keynote to get you started. I use the Keynote version often, and I find that it’s the easiest, but not everyone is lucky enough to own a Mac.
Both versions make use of “master slides”, and this is where the graphics are located. So that I don’t have to reformat text every time I create a new DDD, I keep a version that has three slides by default: the Cover slide, a Design Description slide, and a Notes slide.
To create a Design Description Document, simply pop open one of these files and do a quick Save As to make a copy without affecting the template. Then:
- Access the Cover master slide and replace the ClientName, ProjectName, Version#, DesignerName, and DD/MM/YYYY text with the name of your client and the project, version number, designer name, and date.
- Open the Design Description master slide and replace the AppName and V# text with the appropriate info.
- Go to the second slide in the deck and copy and paste it to make new empty slides - as many as you need to show each wireframe you created. If you have 20 wireframes, create 20 Design Description slides.
- Next, either insert a wireframe image or paste one in, and then start writing out use cases in the sidebar for each interaction on that screen.
- When you’re done, either send it off as is, or turn it into a PDF. (This is good for preventing people from editing the document.)
In Keynote, you can simply export the entire document as a PDF, directly from within Keynote, by choosing File > Export and selecting the PDF tab in the resulting dialog box.
In Powerpoint on Windows - well, you’ll have to figure that out yourself. I’m allergic to Windows. Can’t go near the darn thing.
Use cases 101
These templates are designed to help you write effective use cases, but here is a quick crash course.
First, replace the term “Use case” throughout your Design Description slides with tasks. For example, “Sign in” is a very typical heading for a use case. “Retrieve password” is another.
Next, write out the steps to complete each interaction in the wireframe.
Finally, go back over each step in the use case and look for exceptions. Exceptions are things that can occur if a user doesn’t execute your use case exactly as you intended it. A user who enters an incorrect password on a sign-in screen, for example, needs to be shown an error message. The use case exceptions are where you detail these facts.
To do this, explain which use case step is being excepted, then write out the steps for the alternate use case. In the example shown here, a user can enter an incorrect user name (Step 1 in the use case). To remedy this, we show an inline error message, the user enters the user name again, and clicks the Sign In button.
Click here to download
Ha! Made you click.
So, you’re sold? You want the templates so you can create your own Design Description Documents and stop sending out mistakes and answering questions long after a project is over?
Well, then download the template already.
For just a few cents a day, you can help a designer break the habit
Once you get the hang of creating your own DDDs, spread the word. The more designers use these templates, the easier life will be for all of us in the future. I can’t tell you how many times I’ve been sent a set of wireframes designed by someone else and had to go hunt them down and ask questions.
With the DDD, life is richer and more rewarding. It’s like one of those commercials where everyone is happy.
For a full collection of templates, visit www.rhjr.net/ddd.
And if you happen to create a new template in something other than Keynote or Powerpoint, send them to me at “robert at rhjr dot net” and I’ll add them to the collection. (Be sure to give yourself credit in the template. You deserve it.)
Great article. I’ve used PowerPoint as my agile programming design tool before too - easy and quick. Can’t wait to see your slides.
[…] Deliverables That Work: Design Description Documents “A Design Description Document (DDD) is, essentially, a slide deck that shows detailed use cases alongside wireframes or comps in an effort to detail all the interactions in a design. And it has quite a few major benefits.” (tags: webdesign management design web clients workflow) […]
[…] I’m happy to announce that I have a new article up on Vitamin, called Deliverables That Work: Design Description Documents, in which I give away what I hope will become your new favorite design deliverable. It’s a little something that I’ve been using for months now and has proven extremely effective for communicating design work. Learn more about Design Description Documents here. […]
[…] Hoy leí algo muy interesante para documentar mockups o diseños de interfase usando algo llamado Documentos de Descripción del Diseño (o algo así). […]
[…] Link […]
[…] Deliverables That Work: Design Description Documents […]
[…] Vitamin Features » Deliverables That Work: Design Description Documents Slide templates for alternative to way to present wireframes. (tags: design wireframes tools) […]
[…] Over on Vitamin Robert Hoekman has posted a great template and ‘how to’ for a powepoint slide deck that shows detailed use cases alongside wireframes or comps in an effort to detail all the interactions in a design. Excerpt: The Design Description Document cures all of this. First, it communicates to the boss how each interaction will occur, so he has no questions. Second, it tells the developers exactly how things need to work so they know what to build and can immediately start cranking it out. Third, it gives the Documentation team something they can start writing about sooner than later. After all, if the developers know exactly how everything needs to work, odds are much better that the final product will be in line with the original design. […]
For those not that familiar with Power Point, it would have been helpful if you talked about how to edit the Master Slides.
View > Master > Slide Master
I wasted a fair amount of time trying to figure out how to change the ClientName, ProjectName, Version#, DesignerName, and DD/MM/YYYY.
Otherwise, though, this is great! :-)
Good point - sorry about that!
I’m not sure if this is the same process on Windows, but on Mac:
1) Go to the slide you want to edit
2) Choose View > Master > Slide Master
3) Edit the fields you want to edit in the master slide
4) Click the “Close” button in the Masters toolbar
That’s it!
I really like your format with the sidebar. I have been creating pdfs for clients but I think adding the sidebar with all the information is a great way to communicate site details and how it will function.
Thanks, Robert. Simple, easy solution. I will promote Design Description Documents for effectively communicating design work both with my design communication students and my clients.
I really like the template! Definitely an interesting, and clearcut approach. I also discovered a template a few months ago called the Task Analysis Grid.
http://toddwarfel.com/?p=16
This template is more focused on the requirements side, but gives a clear way to communicate tasks, scenarios/use cases, pain points, and functionality.
Wow, what a great article and technique! Big thanks!
I can agree that, yes, it’s a good thing to have the use cases proximate to the wireframes. That’s like motherhood and apple pie. However, I’m less sure whether that little gutter — even with the “notes” pane in ppt — is sufficient to really indicate anything but a superficial use case.
Your DDD is useful for communicating with a client or a technical writer, but I doubt this would reduce the number of questions from a developer or qa engineer. At least, not unless those folks are actively participating in requirement discussions with the client.
Thanks so much for the kind words, everyone. I’m really glad you’re finding value in the DDD.
@Todd Moy:
Thanks for your comments.
Surprisingly, there’s rarely been a time when I needed more room for use cases on a single slide, even when they’ve been long. I believe this is because I usually create wireframes for every state of a screen, so the use cases end up being spread out over a few slides. And in the rare case that I do need more room room, I just duplicate the slide and and continue the use cases and notes on the second one (I add
“(continued)” to the slide title when doing this).
In response to your other point, I’ve been using the DDD for several months now and it’s actually been very well-received by QA teams, dev teams, etc. It’s pretty rare, actually, that clients end up having questions about the interactions. I make it a point to include details on what the system does in addition to the user’s actions, so the use cases can actually be quite thorough without involving a lot of writing.
On an unrelated note, I see you run a Meetup group in Phoenix. We should chat more about that. I’m in Phoenix as well. Feel free to shoot me an email anytime.
Thanks again for your comments.
Just curious… What’s the difference between this and a wireframe? Is it the inclusion of the use cases/scenarios?
If that’s the difference, why isn’t everyone adding use cases/scenarios to their wireframes (when necessary, of course).
Lastly, what does this *not* communicate well. That would help people know when to use this format, and when to choose another.
[…] Deliverables That Work: Design Description Documents (tags: Productivity communication Design development documentation wireframe tools Process) […]
@ Austin:
“Just curious… What’s the difference between this and a wireframe? Is it the inclusion of the use cases/scenarios?”
A wireframe is just a low-res version of a page design - it doesn’t typically include annotations. The wireframe is part of the DDD, but not the whole thing. Adding the use cases to it gives each wireframe context and more depth. It communicates the details so that other people know how the screen behaves.
“If that’s the difference, why isn’t everyone adding use cases/scenarios to their wireframes (when necessary, of course).”
Actually, I have no idea! For some reason, many designers leave out these details wen they deliver design work. In some cases, I’m sure it’s because they worked closely with the dev team in the first place and as such, don’t need to include notes about the behavior. In other cases, I really can’t explain it.
I think it’s always beneficial to detail the behavior through use cases. First, it helps you, as a designer, think out each interaction to make sure it does what it needs to do. It also gives you an extra opportunity to refine the screens - you can look for ways to make each process simpler. Finally, it’s great for QA and Documentation teams regardless of whether or not the dev team already understands how the interactions work. QA can see how an interaction is supposed to work in the first place so they know what to test, and Documentation can start writing immediately.
“Lastly, what does this *not* communicate well. That would help people know when to use this format, and when to choose another. ”
Great question!
- It doesn’t communicate any information you might have about who your audience is (if you’re designing for a niche audience). For example, if you’re creating an app for doctors, the DDD isn’t going to include any information about doctors or how they work.
- It doesn’t include cold, hard technical facts about how they System might accomplish each interaction. If Ajax needs to be used to call up some new search results, for example, this is not noted in the DDD. The DDD will tell the developers that the results need to show up without reloading the page, but how they do that is up to them. It leaves the programming creativity in the hands of the programmers. The DDD only describes behavior, it doesn’t tell people how to achieve it. It’s tool-agnostic.
Hope that helps! Thanks for your questions.
Nice article and thanks for the templates link.
May I recommend you a good book about design documentation? “Communicating Design” by Dan Brown.
I can’t access the master slide and replace the stuffs in PowerPoint 2007….
Like all great ideas its so obvious once someone has pointed it out. Thanks. Terrific.
The new version of Pages will let you create and print side notes. I took your Keynote template and made a Pages one. Print to PDF and it’s a keeper.
So, how is this different from a functional spec?
[…] Deliverables That Work: Design Description Documents (DDD) You know those things you’re supposed to deliver to a client during a big project — use cases, wireframes, etc.? Robert Hoekman Jr. does and he shares the tool he uses to package them all — the DDD. Wireframes, the schematic presentation of interaction, can be used to display the model behind the sketch in a more effective way. As a sidebar or infobox, they can give your clients a precise idea of the site functionality and its structure. This article presents some of such Wireframes for free download (for Apple iWork). A PowerPoint-template is also included. […]
[…] Deliverables That Work: Design Description Documents (DDD) Um eine optimale Kommunikation zwischen Kunden und Designern zu erreichen, ist es oft hilfreich, sog. Wireframes, also die schematische Darstellung der Interaktion, zu verwenden. Diese sollen dazu benutzt werden, um Seitenbetreibern eine kompakte und präzise Vorstellung über die Seitenfunktionalität sowie Seitenstruktur zu vermitteln - etwa durch eine begleitende Infobox, die über einzelne Seitenbereiche informiert. Robert Hoekman Jr stellt einige solcher Wireframes kostenlos zum Download bereit (für Apple iWork). Eine PowerPoint-Vorlage wird ebenfalls mitgeliefert. […]
[…] Deliverables That Work: Design Description Documents (DDD) You know those things you’re supposed to deliver to a client during a big project — use cases, wireframes, etc.? Robert Hoekman Jr. does and he shares the tool he uses to package them all — the DDD. Wireframes, the schematic presentation of interaction, can be used to display the model behind the sketch in a more effective way. As a sidebar or infobox, they can give your clients a precise idea of the site functionality and its structure. This article presents some of such Wireframes for free download (for Apple iWork). A PowerPoint-template is also included. […]
[…] Deliverables That Work: Design Description Documents (DDD) You know those things you’re supposed to deliver to a client during a big project — use cases, wireframes, etc.? Robert Hoekman Jr. does and he shares the tool he uses to package them all — the DDD. Wireframes, the schematic presentation of interaction, can be used to display the model behind the sketch in a more effective way. As a sidebar or infobox, they can give your clients a precise idea of the site functionality and its structure. This article presents some of such Wireframes for free download (for Apple iWork). A PowerPoint-template is also included. […]
[…] Si estas involucrado en nwIA los DDT, y los Sheter de de técnicas pueden resultarte útiles. […]
[…] Deliverables That Work: Design Description Documents (DDD) You know those things you’re supposed to deliver to a client during a big project — use cases, wireframes, etc.? Robert Hoekman Jr. does and he shares the tool he uses to package them all — the DDD. Wireframes, the schematic presentation of interaction, can be used to display the model behind the sketch in a more effective way. As a sidebar or infobox, they can give your clients a precise idea of the site functionality and its structure. This article presents some of such Wireframes for free download (for Apple iWork). A PowerPoint-template is also included. […]
[…] WireframeA wireframe is a basic structure — skeleton — of a site that describes the ideas, concepts and site structure of a web-site. Wireframes can be designed as presentations which explain to the stake holders how the site is designed, which functionality it offers and how users can accomplish their tasks. Wireframes usually don’t have any visual elements or a complete page layouts; they are often first drafts and sketches designers create on paper. Example? Here you go. [Glossary, Wikipedia: Wireframes] […]
[…] WireframeA wireframe is a basic structure — skeleton — of a site that describes the ideas, concepts and site structure of a web-site. Wireframes can be designed as presentations which explain to the stake holders how the site is designed, which functionality it offers and how users can accomplish their tasks. Wireframes usually don’t have any visual elements or a complete page layouts; they are often first drafts and sketches designers create on paper. Example? Here you go. [Glossary, Wikipedia: Wireframes] […]
[…] Wireframe A wireframe is a basic structure — skeleton — of a site that describes the ideas, concepts and site structure of a web-site. Wireframes can be designed as presentations which explain to the stake holders how the site is designed, which functionality it offers and how users can accomplish their tasks. Wireframes usually don’t have any visual elements or a complete page layouts; they are often first drafts and sketches designers create on paper. Example? Here you go. [Glossary, Wikipedia: Wireframes] […]
[…] From Vitamin Features, a free template for a Design Description Document — this looks really good and like it could really help us at this stage in the game. There is a version for Mac … […]
[…] Vitamin Features » Deliverables That Work: Design Description Documents […]
[…] Deliverables That Work: Design Description Documents […]
Look this site
http://www.ooyes.net
[…] Скелет сайта, который отражает идеи концепции и структуру будущего сайта. Может быть представлен в виде презентации демонстрирующей заказчикам, особенности компоновки и функциональности сайта, а также возможные сценарии выполнения пользователями их задач. Обычно скелет не содержит визуальных элементов или готовой разметки сайта, но возможно в него будут включены черновики или скетчи. Пример. [Glossary, Wikipedia: Wireframes ] […]
I’ve only just found this article (my feed reader wasn’t checking the Vitamin feed for some reason), as it happens we have recently started taking a very similar approach - i.e wireframes with annotation.
We find MS Publisher really good for this - it allows your to create quite sophisticated wireframes/page mock-ups including web form elements such as check boxes, radio buttons, list boxes and submit forms. Plus, it has a “web view” function, ’save as’ html and ’save as’ .mht .
Where Powerpoint differs is the ’slide’ concept which keeps the whole package very neat. But for individual wireframes Publisher is hard to beat.
We’re also trialling ConceptDraw WebWave for site concept and site map design, www.conceptdraw.com/en/ although we haven’t yet decided whether it’s worth the asking price.
Incidentally we find these things help us with concept design so that we can give external developers and designers something meaningful from the outset :)
[…] link: Deliverables That Work: Design Description Document November 6, 2007 – 6:35 pm Deliverables That Work: Design Description Documents […]
[…] Deliverables That Work: Design Description Documents […]
[…] Deliverables That Work: Design Description Documents (DDD) You know those things you’re supposed to deliver to a client during a big project — use cases, wireframes, etc.? Robert Hoekman Jr. does and he shares the tool he uses to package them all — the DDD. Wireframes, the schematic presentation of interaction, can be used to display the model behind the sketch in a more effective way. As a sidebar or infobox, they can give your clients a precise idea of the site functionality and its structure. This article presents some of such Wireframes for free download (for Apple iWork). A PowerPoint-template is also included. […]
[…] Deliverables that work: design description documents L’auteur, accessoirement interaction designer, explique le processus ainsi que les documents qu’il a adoptés pour présenter ses ébauches et communiquer avec les différentes équipes clientes. Il s’agit en quelque sorte d’un mixe de wireframes, de cas d’utilisation et de diapositives PowerPoint. […]
[…] While browsing the archives at thinkvitamin.com I came across an article by Robert Hoekman Jr called Deliverables That Work: Design Description Documents. In it he suggests combining use cases and wireframes or screenshot to make single design document. I generally provided detailed notes about the behaviour of the interface as part of my wireframes, however I like his suggest of using usecases. […]
[…] Скелет сайта, который отражает идеи концепции и структуру будущего сайта. Может быть представлен в виде презентации, демонстрирующей заказчикам, особенности компоновки и функциональности сайта, а также возможные сценарии выполнения пользователями их задач. Обычно скелет не содержит визуальных элементов или готовой разметки сайта, но, возможно, в него будут включены черновики или скетчи. Пример17. [Glossary16, Wikipedia: Wireframes18 ] […]
[…] Make your brief as visual as possible to establish your direction from the outset. In the context of website design projects, this can be done using a combination of mood boards, design description documents, sketch-boards, or even a comic strip. Your brief can be a combination of technical and lo-fi. For example, a digital mood board combined with paper sketch-boards is an efficient and effective means of setting a direction and communicating your understanding of the brief. […]
[…] Make your brief as visual as possible to establish your direction from the outset. In the context of website design projects, this can be done using a combination of mood boards, design description documents, sketch-boards, or even a comic strip. Your brief can be a combination of technical and lo-fi. For example, a digital mood board combined with paper sketch-boards is an efficient and effective means of setting a direction and communicating your understanding of the brief. […]
[…] Make your brief as visual as possible to establish your direction from the outset. In the context of website design projects, this can be done using a combination of mood boards, design description documents, sketch-boards, or even a comic strip. Your brief can be a combination of technical and lo-fi. For example, a digital mood board combined with paper sketch-boards is an efficient and effective means of setting a direction and communicating your understanding of the brief. […]