Keys to Success on Every Project

For the last decade I’ve been a project and product mercenary. I’ve ran an agency, where our job was to cut through the noise, identify the customers’ marketing and/or technology goals and plot courses for solutions. I’ve also been involved with a number of start-ups looking for answers on macro and micro levels. On the macro level in defining a set of goals, in the form of problems, to (re)solve and build a business around. On the micro level, making a multitude of daily design and intent decisions. The quality of those decisions driving execution and bridging the gap between talking about it and doing it.

Art is self-expression. Decoration is stylization. But design – by definition – is finding a solution to a problem.

When people talk about “design” in a visual context, many times it gets confused with “art”. And art does not solve a problem. In fact, a lot of people that call themselves designers are not particularly interested in solving (let alone defining) a problem, rather they are interested in imposing their visual aesthetic on the given medium. This is the precise path for form to overwhelm function.

It is true that visual appeal is important in many design disciplines (part of the solution). Graphic, user interface and architecture are some examples. However, having to solve a problem is the universal design principal that expands to all design processes. Software architecture, business process and even plumbing

All design is problem solving, but often times the problem is not clear enough to start throwing solutions at. This happens far more than people are willing to admit or bother to analyze.

In the last couple of weeks, while thinking about this article, I’ve been keeping a mental tally of the problems I’ve been asked to solve. One friend asked me to design a flyer for his new business. Another asked for feedback on an announcement email blast. I’ve also been working on a presentation to make the case for a partnership with a large company. In all cases, clarity was achieved and each project was positioned for success by first and foremost defining the problem.

With the benefit of experience, I’ve been able to whittle down the problem definition process to three basic questions:

Who is your audience?

What’s in it for them?

What do you want them to do?

Simple and to the point. The answers are your problem set. You can measure each attribute or component of the project/product/process at any one point to those answers. Anything that doesn’t answer those questions is likely unneeded noise and has no place in the ultimate solution.

Got some insights? Disagree? Comment below.