One of the harder things I do in my corporate design gig is to try and maintain some wiggle room within UI and interaction projects. More often than not these put front end pieces to market that grow from months of diligently scheduled meetings involving business analysts, marketers, bankers, front and back end programmers, and strict dates. The UI process expectation is one of exhaustive requirements definition, then prototyping and signoff, then code. And I don’t think the model is an exception for big organizations with in-house teams.
Time and again, however, I’ve found that some answers (let alone questions) don’t present themselves until long after the project plan has been signed, sealed, and delivered. The problem then becomes that the plan assumes everything’s been answered and optimized up front while sticking to the plan will in fact prove to be the sub-optimal route to take. I’ve sometimes had to walk a narrow line in reconciling the tensions this can present in my job. I’ve recently also seen the ‘magic’ that can happen if the parties on a design project can accept a certain level of ongoing uncertainty.
There have been big online success stories of late, mint.com for one within the personal finance sector, that have emerged from nimble organizations willing to embrace a sort of irresolution with purpose. 37signals, of Basecamp and Backpack fame, is another group that has embraced anti-process and seen success. The following Andrew Hunt excerpt was lifted from their recent book Getting Real. I don’t expect Corporate’s staid organizational cultures to go agile overnight but I do believe there are lessons we can take from flocking birds and dexterous development. Let’s try to let at least some of it it happen…
Emergence is one of the founding principles of agility, and is the closest one to pure magic. Emergent properties aren’t designed or built in, they simply happen as a dynamic result of the rest of the system. “Emergence” comes from middle 17th century Latin in the sense of an “unforeseen occurrence.” You can’t plan for it or schedule it, but you can cultivate an environment where you can let it happen and benefit from it.
A classic example of emergence lies in the flocking behavior of birds. A computer simulation can use as few as three simple rules (along the lines of “don’t run into each other”) and suddenly you get very complex behavior as the flock wends and wafts its way gracefully through the sky, reforming around obstacles, and so on. None of this advanced behavior (such as reforming the same shape around an obstacle) is specified by the rules; it emerges from the dynamics of the system.
Simple rules, as with the birds simulation, lead to complex behavior. Complex rules, as with the tax law in most countries, lead to stupid behavior.
Many common software development practices have the unfortunate side effect of eliminating any chance for emergent behavior. Most attempts at optimization – tying something down very explicitly – reduces the breadth and scope of interactions and relationships, which is the very source of emergence. In the flocking birds example, as with a well-designed system, it’s the interactions and relationships that create the interesting behavior.
The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it’s locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence.
Keep it small. Keep it simple. Let it happen. – Andrew Hunt, The Pragmatic Programmers
Refreshing Alex.
It’s good to have a plan, especially when the designer and the person actually doing the lifting is a different person. But I see no need to have things set in stone. Things change over the course of a project and a team is better when they are more flexible to a shift in the project.
Thanks for the perspective, In my case we (designer and developer, or ‘lifter’) are one and the same.