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?

 

11 thoughts on “You can’t solve problems you don’t know about

  1. Hi Julie, I think this issue is why I’ve found the ideas and techniques in design thinking so powerful for what we do.

    To answer your question, stop listening to the SME or project lead and go talk to the people you are actually designing for – the end users. Understand their world and you can understand the roots of the problem.

    All of the questions above assume that the person you are talking to really understands the problem. Often they don’t.

    • Hey Sam — thanks for the comment — totally agree.

      I do think getting the stakeholders to clearly frame the change they are looking for is a necessary first step, but then I definitely believe you need to spend time with the actual end-users to better understand causes and solutions. 100%.

      Thanks for the comment!

  2. This is a great post. I love the observation, “designers are often given solutions to implement, rather than problems to solve.” — This is true.

    One point to make: stakeholders’ aren’t always looking to correct errors; sometimes they need to simply improve outcomes. This, too, is a “problem” that can be identified and articulated. I point it out because most of your prompt questions point to detrimental problems. Yes, I hate to think organizations only pursue learning / training / professional development when something goes wrong.

    • Absolutely agree — I referred a little to opportunities also, but I think you’re right — I tend to focus on the ‘problem’ aspect, and should have equivalent strategies around opportunities as well.

      Thanks!

  3. Pingback: You can't solve problems you don't know about | Voices in the Feminine | Scoop.it

  4. Pingback: You can't solve problems you don't know about | A New Society, a new education! | Scoop.it

  5. Pingback: You can't solve problems you don't know about | General Instructional Design | Scoop.it

  6. Pingback: You can't solve problems you don't know about | Organizational Learning and Development | Scoop.it

  7. Great post, this is a topic which I think is often overlooked or misunderstood.

    In addition to asking what the problem actually is (not what the solution they are looking for is), I like to ask what they believe is currently working and why.

    Asking these questions gives me an idea of their ability to identify what success or failure looks like. I am also able to determine if the problem is a result of some inconsistency or contradiction in policy or procedures.

  8. Hey, I just saw this (always behind) — thanks for the shout-out!

    I love this simple guide to how you can tell whether you’re being given a problem to solve or an order to fill. It’s a great first step in solving the problem. And double-agree with Sam’s focus on end user research a la design thinking!

  9. Hi. I am glad I came across your blog. I have just started a certificate program in IDT and most of the information seems to be focused on the educational side. Discussions seem to focus on teacher/learner relationships in an educational setting. When I came across your post, I immediately could relate to strategic mapping, similar to providing key success factors to align performance with the overall strategy of an organization. I think in both environments success can only come if common values and goals are a central issue and deeply rooted in the culture. Planning maps provide a visual representation of how strategic measures are linked to various business processes, not that different from mapping the problem, opportunities and the challenges. At least now I have something familiar to make connection with the new material.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>