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?
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:
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.
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.