Design Is Inherently About Control. Or is it?

Great blog post on the tale of two architects. See the entire post at the Logic + Emotion blog.

"Design is inherently about control"

In a nutshell: They both build a playground. One architect goes to watch the unveiling and cringes as the children play in ways he never intended. The other goes to watch and sees same but is delighted, takes notes and plans on how to integrate what's happening into the next project.

Which are you more like?

I know that, by nature, we have a vision of what it is that we're building. We know how it's supposed to be used. When your audience does things with it you never considered, is that a bad thing? And if so, how do you stop the buggers?

I would conjecture that no, it's not bad. I think the second architect has it right. One mind can imagine only so much. Many minds can imagine so much more with the same materials. The trick is to pay attention, learn quickly from what you're seeing and incorporate it into your work.

In our world of agile software development, SCRUM's, rapid release schedules and (close to) unlimited flexibility, it's a gift to watch and learn. To do this you need to make sure you're tools are in place. Watch the numbers. Pay attention to the features that get used and expand them. Lower the priority on features that don't get used (and don't get overly attached to them, even if they're "Key To Your Grand Plan"). Examine and learn from the creations people make with your products capabilities. Talk to your users regularly and make sure your development team has customer interactions. Most of all, make sure the people that design and create aren't walled off in dark cavern full of computers and Redbull.

So is design inherently about control? At first blush, it feels that way, but in the real world, it almost never is.