Over on my post Do constraints help problem solving, Aaron asked:
I’m currently completing a dissertation titled Development in Product Design is driven by a response to changing constraints rather than innovation for my 3rd year BA Product Design course. You have stated that constraints can be eliminated on purpose, I can understand how they can be created but not eliminated? have you got any example of this in practice?
The best attitude when trying to solve problems is everything is negotiable. Just because someone says the car they want you to design must be red and ten feet tall, or done by Friday doesn’t mean it actually needs to be those things. Most constraints people give are made up: they haven’t been rigorously examined to find the real boundaries.
Maybe instead of being ten feet tall, what they really want is a car they can fit comfortably in, given that the client is Shaquille O’neal.
And perhaps it’s not a red car they want, but just a car that looks cooler than their neighbors car.
Or instead of it all being done Friday, only one important part needs to be done, but the rest can be done by Monday.
People confuse being specific with being accurate. Having details and numbers doesn’t mean you understand why those things are the right choices.
The challenge in creative work, especially with clients, is how to explore their constraints without annoying them. And then get them to happily acknowledge these are the true problems, rather than assuming their description of their problems is sufficient. The reason why so many projects fail is the lack of this skill on all sides: clients, executives, designers, engineers and customers all stink at this process, and dismiss it as irrelevant.
The fancy word for this is requirements elicitation. But it really just means thinking hard and carefully about requirements, understanding they are a kind of design unto themselves. Someone has to diligently sort through those that contradict, and identify those that are poorly formed or unnecessary. Prototyping and sketching helps sort this out, but that’s just part of the process.
The best book I’ve ever seen on this is Exploring Requirements, By Weinberg. It should be required reading for anyone who solves problems for anyone else.
But the big problem is, of the few phrases more boring in this world than project management, requirements gathering is definitely one of them. It needs a slicker name. I hate jargon but I’d be all for something snazzy that gets them to care more about this kind of thinking. (Require-magic? Constraint-O-Rama? Hmmm).
Sometimes you can find a way to make two different constraints reduce down to one, making the problem simpler to solve. A constraint (e.g. requirement) might not be eliminated, but can be bent, shifted, twisted, rephrased, or entirely manipulated (See Kobyiash Maru) to serve your purposes.
A favorite example: for decades the problem with bringing the internet into developing countries was the expense of digging tunnels to put in power, phone and cable lines. The advent of cell phones, where towers are built above ground and no wires are needed, eliminated the constraints around digging and cabling. For many people in the world today their first phones, and first web browsers, are cell phones. A constraint was entirely eliminated by design.
Good ideas can sometimes eliminate seemingly immovable constraints.