Deliverables That Work: Design Description Documents

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)

Design Description Document

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

Cover slide for a Design Description Document

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:

  1. 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.
  2. Open the Design Description master slide and replace the AppName and V# text with the appropriate info.
  3. 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.
  4. 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.
  5. 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.

Written use case for a Design Description Document

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

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.)


8 comments on “Deliverables That Work: Design Description Documents

  1. Thanks much for the refresher about how placing use case content adjacent to a wireframe can be an effective communication method. I’ll put something together in Graffle and if it manages to finally get through the skulls of our happy-go-artsy design staff how functionality based on marketing objectives should drive the web design rather than whim, then perhaps I’ll be able to contribute to your zip file.

  2. Pingback: The Blog » Design Description Documents in OmniGraffle