Iterative Design and Big Boxes--
A couple of decades ago, at the early part of my technical communication career, I developed and delivered installation and maintenance training for industrial equipment (specifically, hot melt glue machinery that went on packaging lines) . Part of my job included setting up equipment for lab exercises, which required plumbing hydraulic and pneumatic lines and solenoids and such. My technical background is in electronics, so this hydraulic and pneumatic plumbing aspect was a challenge for me. Basically I had a small box of fittings and connections, and if I needed to get part A plumbed to part B, I found a fitting that went on part A and kept going into my box finding and connecting fittings until I had a jerry-rigged arrangement that ended with a fitting that matched part B. It worked.

I then had an opportunity to visit a Procter and Gamble plant in Lima, Ohio, where they were completely refitting a production line. I was thrilled; I was going to get to see how a by-gawd union pipe-fitter for a major packaging plant did it. I showed up; the union pipe fitter showed up; she had a BIG box of fittings that she kept digging into until she had an arrangement that fit on part A on one end and part B on the other. My reaction was, "Well I'll be damned!"

I moved on, away from hydraulics and pneumatics and into the more rational word of software applications. I was committed to the belief that thorough planning and design could create efficiently producible documentation that was user-friendly. Twenty years later I am a user assistance architect with a PhD working for IBM. What does that mean? I now have a BIG box of tools and patterns that I fish around in, but basically I still get from A to B by looking for what fits and doing a lot of trial and error.

But at last I think I get it: That's the way design happens!

I now give myself shorter planning windows and plan on doing frequent iterations to get it right. I fiddle less with planning tools and more with wireframing and rapid prototyping tools. My mantra is learn fast, fail early. Get something that you can play with, interact with, and show others as soon as possible.

This is not a natural behavior for technical communicators; we have this notion that things we develop should be accurate and complete (and even look good). Well, eventually, they should be, but not at first. To do collaborative, iterative design, we must create cultures where we show first drafts and half-baked ideas to others and not worry that we will be judged by their flaws and inadequacies. We must be willing to let others share their early drafts with us and not judge them for their lack of quality that can come only with polishing. There is little time for polishing at the early stage of design, and besides, you'd be polishing a lot of stuff that eventually gets thrown away.

Don't stop analyzing and planning, just recognize that the real creative breakthroughs come from building and kicking what you've built. The earlier you can do that and the more iterations you can take it through, the better the final design will be.