Problem Statements – The much shinier version

The last blog post I wrote was about starting design with a problem rather than a solution, and it came from a conversation with Stephen Anderson about a presentation he was putting together for the IA Summit.

Here’s his presentation, and (of course) it’s great stuff:

You can’t solve problems you don’t know about

So, several conversations recently are coming together:

– Judy Unrein’s post on Mike Monteiro’s How Designers Destroyed the World talk, and her discussion about how designers can’t be just be order takers (go watch the talk – it’s amazing)

– A conversation with Stephen Anderson about his upcoming IA Summit talk called Stop Doing What You Are Told! about reframing the design problem (soooo looking forward to those slides)

– Dan Lockton’s article in the guardian about sustainable design, which talks about how, if people aren’t doing things the way we would like, we should figure out how to solve their problems, rather than treating them as the problem.

Getting to the problem

So, this is hard.  I think designers are often given solutions to implement, rather than problems to solve.   I sometime think that’s half my job with clients — getting a clear statement on the problem they are trying to solve, or the opportunity they are trying to realize. It’s something where the outside perspective can really help — when you live with problems all the time, they frequently become tacit.

When I was teaching undergraduates, this was a hard idea to communicate, but it’s a key skill that everyone needs to have. I used to have a really simple card sorting game that I’d have my students play to see if they were being given a problem to solve, or a solution to implement.  If it was a solution, then they had to work on a way to get the actual problem clearly stated.

cardsortingactivity

I think, in light of Dan’s article, I’d tweak it a bit more, and talk about strategies for unpacking even the problem statements (e.g. the card “Sales people aren’t able to answer customer technical questions” would probably be better as “Customers have technical questions that they need answered during the sales process”).

I have several different questions that help me dig for the problem:

  • “Uh huh, and what do they need to do with that?” or “What do they need to do differently?”
  • “What bad thing will happen if they don’t know that?”
  • “Can you give me an example?”
  • “If you woke up tomorrow and we’d implemented this perfectly, what would be different?”
  • “What does is it look like when they get it wrong? What are common mistakes?”

Curious to know what other people do — what do you use to understand what the real problem/opportunity/challenge is?

 

Love these: Mental Notes

So, still need a gift for the design geek on your holiday shopping list?*

I’ve mentioned Stephen Anderson before (I’m a big ol’ fan), but I particularly love his Mental Notes cards, which cover dozens of psychology principles that impact how we design. Need to jump start your design process?  Pull a few cards out the deck, and talk about how you can incorporate those ideas.

You can order them here: http://getmentalnotes.com/

I particularly mention it now because (aside from the fact that these are awesome) Stephen is donating half the proceeds right now.

* Yes, I know it’s a little late to order holiday presents (story of my life), but you can print some sample cards to use a placeholder gift until the real ones arrive.