On some projects I’ve witnessed, people fall into the unfortunate habit of producing lots of documentation - that which simply overwhelms anyone new who is trying to wrap their head around what’s actually going on. Yes, it’s sometimes necessary to get busy with breadth and detail, especially on a big project. But we must never lose sight of how much context might be necessary to understand our work from the outside.
It’s for this reason that some years ago I started doing simpler walkthroughs, and ones aimed not as design documentation for developers or decision-makers, just as simple explanations of the product and its raison-d’etre.
Think of it as a walkthrough plus context. A bit of persona (the who and the why are they doing it), and the what (what happens, and what benefit they derive from it).
The Clearleft 'crate'
At Clearleft we’ve had a concept for many years of handing over a ‘crate’ — a mini website (password-protected) with the key context for the project, and links to web resources that form the deliverables. By doing so, the client knows there’s one place to look. And there's the added and very practical bonus that if anyone new joins the team client-side, or simply wants to know what's going on, they can come in and get up to speed quickly.
(Aside: our methods for making component libraries have been put into a tool we built called Fractal, which is now used by 18F and Eurostar - a deliverable with an even longer lifespan.)
The devil can be the detail
The opposite of all this is when there’s nothing but endlessly detailed documents — spreadsheets, reports, and nothing that comes close to a concise explanation, let alone a value proposition for whatever is being proposed. And they're only useful when you know where to look to find them, which is a problem in itself when you consider things like staff turnover. All too often we ask people to get lost in a forest without a map.
This often happens when you know too much. You've been working on a thing for weeks on months, you know all of the basics, you're too close to it. Along come the assumptions, ones that you can't count on others to understand.
Merging the forest with the trees
Much as I'm advocating ways to prevent people getting lost in the forest, sometimes the trees is what they need. The details are the design, after all. So how can we usefully combine the two? This is a big topic all of it's own, but I find the following universal design principles have been consistently useful.
Advance organiser and the inverted pyramid
David Ausubel's learning concept is that the big picture comes before the details, that detailed information should be chunked up later, and that in many cases starting with what people already know (comparative knowledge) is a great starting point.
The inverted pyramid is a concept from journalism that echoes this idea - put the why/when/where/what at the beginning, and order everything else in terms of importance.
(Both of these concepts are detailed in 'Universal Principles of Design'.)
It’s our job as designers to find the right levels of detail in the right context. To tell stories, to inspire, to clarify if people are understanding what’s being communicated, and most of all, make it usable. People shouldn’t be left guessing as to where understanding lies — be the invisible force that gets people on the same page, using your powers of design.
This is an edited version of a post originally published on Ben Sauer's Slapdashery blog, here.
