The best attitude to have when trying to solve problems is that 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 us are soft and vague: they haven't been rigorously tested, pushed or probed to find the real boundaries. This isn't to say designers should do whatever they want. Some of the best designs in history came about because they were challenged by their clients. But good designers are masters at being creative about the creativity.
Perhaps, instead of the car being ten feet tall, what they really want is a car they can fit comfortably in, given that the client is the NBA Cleveland Cavaliers' Shaquille Oneal.
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 trick in creative work, especially with clients, is how to explore their constraints in such a way that you do not annoy them, but that you understand the problem sufficiently well that you get at core of the problems they need to solve. And then get them to happily acknowledge these are the true problems, rather than assuming their description of their problems is sufficiently well formed to be the true target. 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, that are poorly formed as well as those that are 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 G. 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.
ABOUT THE AUTHOR:
Scott Berkun left his job working for Microsoft in 2003 to become a full-time writer and public speaker. He has written three bestselling books. His work can also be found in The New York Times, The Washington Post, Forbes, The Wall Street Journal, The Economist, The Guardian, Wired magazine, National Public Radio and other media. This entry was originally posted here.