Designing Great Design Documentation

1. Adding a summary

Let’s say, you’ve made a profound heuristic evaluation of client’s application and pointed out a hundred of usability issues. As a result, you have a one-hundred-page report with screenshots and descriptions. Such a serious work might have taken you a week or two.

And now imagine a person who is looking through your report for the first time, especially if this is a non-designer. I’m pretty sure, this person will comprehend something like in the picture below.

Two weeks of documenting the issues in the client’s product — and your report rests in peace in “Read later” folder. Apparently, not what you expect, isn’t it? And now by adding two slides to this already enormous report, we’ll help the audience to read less but get more.

See that on the picture above? The second and the third slides define key issues and to-dos. The rest of the slides are more of a proof than must-read information. Even if no one scrolls to the screenshots and comments, your goal will be reached because the essence of design is to cause changes, not to make people watch all the slides.

Even 10 pages are a sufficient cause for creating a summary. Just imagine your recipient is busy and has only five spare minutes. If he or she reads the summary only, it’ll be a win. No one is eager to cut through words and pictures to the document idea. It’s good to place summary right after the title page or title block.

This principle originates from the journalistic “inverted pyramid rule”, which suggests putting facts descendingly in the order of their significance. Both journalism and design are utilitarian, result-oriented areas, that’s why the inverted pyramid is so useful for design documentation.

So, imagine this: you work on a design system that contains a lot of different components, and a textbox is one of them. The textbox guideline has a bunch of mockups, additives, interaction rules, specifications, and features.

We, designers, tend to see the world through “design glasses” and expose pixel-perfect blah-blah or fancy canvases. Instead of bursting into pictures, animation, fonts, and colors, it’s better to say what it is and what it is used for. Dip your recipient into the subject gradually by letting them catch the idea first and then learn as many details as they need.

If your document is based on a previous teamwide activity, it’s good to remind of it in a couple of short sentences. For instance, after a workshop, you prepare a customer journey map — the description of user’s steps, actions, issues and opportunities organized in a grid. On the picture below you can see “Data rendering flow”, but it’s not clear what is this flow about, where it’s taken from and why should one know about it.

Let’s add background information. It’ll help the audience to get what you want and not to start arguing about already agreed things. This technique works the best for design briefs and discovery workshop reports, which designers often send to the participants.

And one more thing. It’s better to start documents, which are to be sent out or viewed on a screen, with a summary. Materials that are presented face-to-face can finish with a wrap-up because an audience is usually more inclined to follow the story of a presenter. Of course, if the speaker is not so dull that listeners start yawning right after the intro slide.

In a nutshellIf you are not familiar with your readers, treat them as busy people whose brains are already overwhelmed with a lot of other things.In design documents over 10 pages, start with a summary.Regardless of how important information you have, a good summary should be one-minute-reading long.

Let's block ads! (Why?)