Jeff Croft

I’m a product designer in Seattle, WA. I recently worked at Simply Measured, and previously co-founded Lendle.

Some of my past clients include Facebook, Microsoft, Yahoo, and the University of Washington.

I’ve authored two books on web and interactive design and spoken at dozens of conferences around the world.

I’m currently accepting contract work and considering full-time opportunities.

Blog entry // 01.10.2008 // 10:06 AM // 0 Comments

Solutioneering, or putting solutions before problems

Solutioneering” is a term our Creative Director, D. Keith Robinson, came up with back in the early days of Blue Flavor. Essentially, it means putting solutions before problems. In technical fields like web design and development, solutioneering is especially prevalent. However, this approach rarely yields good results.

Design, by very definition, is the act of solving problems. In order for anything to be designed well, we must first identify the problems we are trying to solve and the goals we are trying to reach. Design firms like Blue Flavor employ experts at solving problems on the web, and clients will find their projects most successful when they approach an agency with problems, rather than solutions.

To illustrate the difference between problems and solutions, here are a few examples of problems and goals clients may come to Blue Flavor with:

  • Our company’s e-commerce site is selling a lot of product x, but we want to sell more of product y, because it has higher margins.
  • We have little trouble attracting users to our site, but we find that most of them don’t come back for multiple visits.
  • Our website is slow and unreliable.
  • We don’t feel like our website accurately conveys our brand image.
  • We want our site to be easier to use.

And, here are a few examples of solutions to these problems:

  • Product y should be above product x on the e-commerce site.
  • Add community features, such as comments, to the web site.
  • Move the site to more powerful hardware.
  • Make the logo bigger.
  • Use an AJAX, “Web 2.0”-style interface.

Each of these solutions may be adequate for the problem at hand. On the other hand, none of them are the only solution to the given problem, and they may very well not be the best solution, either. Yet, we web designers do see clients coming to us with these types of solutions (rather than the problems) on their website wishlist. And worse, we web designers can have a tendency to jump straight to the solutions ourselves, if we’re not careful.

Examples of great design always show a solid understanding of the problem domain. Consider several of Apple’s latest achievements: Time Machine, Visual Voicemail, the iPod, etc. In each case, you can clearly see how Apple designers took the time to dissect the problem at hand and craft an elegant solution. If they had “solutioneered,” Time Machine likely would have been a prettier version of Retrospect, Visual Voicemail probably would have been a slightly more intuitive touch-tone prompt system, and the iPod probably never would have been born at all.

But it’s easy to get excited about a problem and start jumping ahead of yourself. So how can we avoid it? I find keep yourself on the problem-solving tip is all about putting yourself in other people’s shoes.

One classic Interaction Design deliverable is personas. In essence, a persona is a brief story about a (usually fictional) user of your site. It provides a bit of demographic information on the user, and walks the reader through what it is they might want to do on the site, and how they’d do it. Quite frankly, I’m not convinced taking the time to do personas as a formal deliverable is always worth it — but I regularly do a compressed, simplified version of this step in my head as I’m designing individual features and pages. Just forcing yourself to be in the user’s mental state for a few minutes will go along way. What does the user want to do? That’s your problem — now solve it. :)

Problems don’t always come from users, though. They can often come from the business or technical goals of the site, as well. For example, a client may be looking to “flip” their company, and your job may be to help them create a solid acquisition target. In this case, you need to put yourself in the shoes of an investor or suitor for the product. Or, the problem may be that the client is spending too much money on bandwidth charges and needs to figure out how to reduce these charges without lowering the functionality of the site.

The important to understand here is that designers, by trade, are problem-solvers. It’s what we do. If you find yourself jumping to solutions without properly investigating the problem domain, chances are you’re acting more as a decorator than a designer. If you’re looking for a design firm to work with you on a project, you’ll find the good ones do their best work when they have problems to solve rather than just solutions to implement.

Be careful about “solutioneering.” Projects which put solutions ahead of problem are always certainly destined for trouble.

Recently, I’ve been posting articles over the at the Blue Flavor blog. I’ve decided to cross-post some of those articles here. This is one such article. Because this article was originally posted to the Blue Flavor blog, I ask that you direct your comments and discussion over there. Head on over and we’ll talk…


Comments are disabled for this entry.

Tags for this entry
Links in this entry