“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 thing 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 problems are almost certainly destined for trouble.
I couldn’t agree more, we used to call this “Fitting a problem into a Solution,” which tends to be a problem for nearly every company, small and large.
Great write up Jeff, and very poignant to a meeting I had today. A follow-up question: What are some good ways to get a client to pullback from the solution to get at the problem?
This was a really great post. I like how you described how a designer is a problem solver. A lot of the time when you hear designer I just think of an Artistic person making “pretty” things.
I’m afraid to utter the word solutioneering in the office for fear an exec will hear it and like it.
Great post, I really like the last line — I plan to use that. (:
I loved your inclusion of ‘Make the logo bigger’. That phrase sounds familiar for some reason ;)
What a great term! I have struggled with the situation over and over again (It seems like this happens more frequently when IT people are involved?) but never had a name for it.
I also try to stress to all of my clients that I need to know what the problem is before we discuss what solutions should be applied. This is what keeps designers from becoming “Yes Men”
You know, I know <a href=”http://twitter.com/kneath/statuses/509316532” >exactly what you mean</a>. I cringe every time I’m in a client meeting and they present solutions rather than the core problems — unfortunately I’ve found trying to get clients that work at large, well-established companies to present problems is damn near impossible. You can push back, or explain your viewpoint — and many times they even agree. But damned if next meeting they don’t say something like “We’d like to make the buttons green instead of white.”
Ah well, one can dream :)
AMEN! I find myself constantly trying to explain that problems should find solutions, not the other way around. I’ve tried explaining it in terms of Good ideas versus Cool ideas and as the interplay between ‘Doing things right’ and ‘Doing the right things’ using Venn diagrams. This boils it down to a single word that might just stick. I can’t wait to try it out.
## What are some good ways to get a client to pullback from the solution to get at the problem?
Say no to your client. It works for me. Do it nicely of course, explain the ‘why’, but never be afraid of the word ‘no’.
My clients pay me to guide them, to improve their web strategy. I wouldn’t be doing my job if I didn’t say no when they offer an idea that isn’t the right solution.
I can see this article being good for clients to read. It draws a good line between people that are trying to solve the real problems and someone just throwing something at the issue. Shows our value.
@Greg Good call. Not enough companies understand that. The client is NOT always right.
Great article. You’ve articulated a lot of what I see in my own business. My best clients come to me with problems and want my expertise solving them. My worst think they have the solution and just don’t have the skill to execute it.
Eventually I saw this pattern and the problems it creates and now I try to steer potential clients toward telling me about their problems, not their solutions - and if they don’t, I know we won’t be a good fit for them.
Good points to make. How often I’ve been in web design offices and the phone rings… 30 seconds into the conversation is “what you need is a CMS”!!! And without looking at the business problem (or web problem) beforehand. Its the tail wagging the horse.
When you look at web problems first things are also so much clearer… great article.
Great write up. I’ve been practicsing this and you’ve made it clear to everyone. Thank you.
The only problem with this is that the time required to think in terms of a persona and actually analyse the actual problems are usually well outside of the client’s budget. Maybe that’s why I haven’t been able to find the ‘ipod’ solution to CMS .