How to design concepts

Ok, one more thing on this [making patterns worth using](http://ryskamp.org/brain/design/make-a-pattern-worth-using) topic.

It is of utmost importance that when you design a concept, you design something you actually want. Obvious? You would think so…

I think designers underestimate the power of a truly impressive concept. A design that takes risks to express an exciting vision can galvanize a team to do great work. A mediocre concept, on the other hand, won’t convince anyone to work hard on it.

[One of my favorite quotes](http://www.ontko.com/~rayo/burnham.html) is by [Daniel Burnham](http://en.wikipedia.org/wiki/Daniel_Burnham), an American architect from the early 20th century:

> *Make no little plans. They have no magic to stir men’s blood and probably themselves will not be realized.* Make big plans; aim high in hope and work, remembering that a noble, logical diagram once recorded will never die, but long after we are gone will be a living thing, asserting itself with ever-growing insistency. Remember that our sons and grandsons are going to do things that would stagger us. Let your watchword be order and your beacon beauty. Think big.

Great designs can inspire great work. Yet designers too often compromise our designs, watering down our desired outcomes for real or imagined reasons. Why do we so easily give up our unique opportunity to design the future? I know at least one reason that I do it.

I am, by most measures, a pretty bad engineer. I never really took to the technical side of design, always being more excited about concept work. However, the more exposure I get the the technical side of any field I work in, the more likely I am to apply that experience to my concept designs. That can be good, to the extent that it liberates me from imagined technical constraints and gives me new ideas for solutions.

But often, I have allowed my interpretations of the technical constraints to interfere with my concept designs, to the point that my work loses its importance. My core competency, and the the reason I’m part of most project teams, is visualizing ideal solutions. If I scale those back because of imagined or real constraints, then I’m diluting my impact on the project.

There will always be plenty of people willing to take the role of devil’s advocate (no matter how much Tom Kelley [tries to eliminate that](http://ryskamp.org/brain/books/notes-from-the-ten-faces-of-innovation)) or scale back the scope based on limitations or release plans. What’s missing in most engineering-driven projects is the audacious goal, a clear and exciting picture of what the solution could be. There is plenty of time to compromise later, but very few chances to work from a blank canvas.

I remember a story about the beginnings of the 7-11 cycling team. Jim Ochowicz was a veteran racer but putting together a team for the first time. Before he went into the meeting with the Southland Corporation (parent company of 7-11), his friend asked him how much money he was asking for. Ochowicz replied something low like $10,000, since he thought that was realistic. His friend replied that this was 7-11–they could afford almost any price if the idea was good. “Ask for what you really want,” he said, “you might get it.” Ochowicz asked for 10 times more than he had planned–and got it.

Design what you really want. Design what excites you more than anything else. Imagine the future; then draw it out. Who knows–you might get it.