Designing for Documentation vs. Designing for Development

Work
Creative Commons License photo credit: riddle_

Let’s talk for a moment about design “artifacts” (or  “deliverables” or “documentation” or whaever you call them.)

They take up a lot of time. I’ve worked on some projects where, by the time we’ve done dozens of wireframes in high-detail, we could have coded a working prototype of our idea.

But if you just produce artifacts or documentation, you don’t actually have anything built. IA diagrams, flow charts, OmniGraffles, and all kinds of illustrations of what the final product will be. So why do design agencies and web companies even deal with so much documentation?

It’s a symptom of a bottleneck.

A bottleneck in the value chain. Think about it. Design ideas are perishable. They have to be acted on right after they appear, or they fade away. So what happens when your development process can’t absorb design ideas at the rate you produce them?

It looks like a dilemma. You either:

  1. Produce design ideas at the pace of development (which is far slower, by definition of the bottleneck) or
  2. Freeze ideas in the form of documents, diagrams and requirements until they are ready to be thawed and consumed later.

I suspect #2 is what happens in a lot of firms. The throughput from design to implementation in those places is so low that pacing design with development doesn’t seem feasible.

37signals is firmly in the #1 camp. Designs go from concept to HTML (often in-app) without any deliverables in-between, and then from HTML mock to fully implemented feature in Ruby or JavaScript again without intermediate artifacts.

Healthy pressures on design, programming and scope. Pacing design with development puts a few pressures on the company that we think are healthy.

First it means all the designers should be proficient enough with code to implement their ideas, at least statically. Second, the programmers should have enough skill and leverage from their tools (an important factor) to produce meaningful work in short periods.

The third point concerns how we manage and define scope. In order for design, implementation, and review to all happen while the plate is still hot, each piece has to be small. If we bite off too much work at once, then design will go on too long before development can join in. When there’s too much to build at once, review becomes unfocused because the set of variables to evaluate is too large. So whether the project is small or large, we factor the scope into smaller component scopes, build them one at a time based on their dependencies to each other, and evaluate the results step by step using the app ourselves.

The ideal loop

The ideal loop is short enough that you can still feel the spark of your idea and you’re still curious to find out if the decision was right or not as you click through the implementation. You can’t fully judge a design until you’ve tried it in action. The clothes simply look different when they’re on. If there are too many changes to evaluate at once, we can’t tell which of the changes contribute to the improvement or regression and how those changes suggest future steps. Moving in one direction in one feedback cycle is easy. Moving in ten directions in the same cycle is too hard.

[Source: The Documentation Dilemma from 37 Signals]