Solutions Start as Problem Statements.

September 26, 2019 In Graduate Studies Prototyping and Testing User Centered Design

Mod 5- The Art of Crafting Problem Statements with Prof. Bjorn Akselsen

Problems are Opportunities

From an entrepreneurial standpoint, problems present a chance to create a profitable product or service that makes users happy. The Oxford dictionary defines a problem as “a matter or situation regarded as unwelcome or harmful and needing to be dealt with and overcome.” People gladly pay to have their problems go away. However, some problems are elusive, just symptoms of deeper ones, or ongoing conditions that are not perceived as problems until someone comes along and pulls the thorn from the lion’s paw. Ahhh, all better now!

 

“The best problems are like old furniture. They’ve been sitting in the same place for years without being bothered.”

Defined and Undefined

In design thinking, these problems are categorized as undefined. Defined problems are clear, we understand the cause and can formulate a solution. Undefined problems are trickier, we need to investigate and reveal them before addressing causes and proposing solutions. Aaron Benjamin of Prototypr.io writes “The best problems are like old furniture. They’ve been sitting in the same place for years without being bothered.” The worst problems, defined or undefined are “wicked” problems. Most wicked problems are societal in nature, they do not have a straightforward solution or there are no clear answers to them. These problems can be found in education, security, poverty, and environmental activities. There’s a cure for problems: solutions. 

Solutions are actions based on ideas. But before we start working on ideas, a great definition of your problem statement will guide you and your team’s work and kick start the ideation process in the right direction. It will bring about clarity and focus to the design space. 

 

3 Essential Parts

In any project plan it is critical to define 3 things:

1.

The problem
This requires you to frame your problem using a human-centered definition. The problem statement refers to specific users, their needs and the insights that your team has gained through empathy. The problem statement should be about the people the team is trying to help, rather than focussing on technology, monetary returns or product specifications. The problem statement is short but broad enough for creative freedom. The problem statement should NOT propose a solution. The problem statement should also not list technical requirements, as this could restrict the team and prevent them from exploring areas that may yield innovative and bring new insights to the project.

The statement should be specific enough to make it manageable. A  problem statement like “Improve the human condition,” is too broad and will likely cause team members to easily feel daunted. Problem statements should have sufficient constraints to make the project manageable.

Below is a formula for a short user-centered problem statement:

 

 

2.

The goal (business objectives)
Understanding business objectives helps you craft your problem definition because it allows you to drill for more specific information. Follow-up questions can unlock a wealth of insights that influence the design approach:

  • How do you know this is an issue?
  • Who is affected by the issue?
  • When and how often does this occur?
  • What benchmarks do you have and what changes do you expect?

It also helps you form solutions based on the intent. How many times have we heard stories of inventions that were commercial successes meant for something other than their original application? If the company just wants to sell more “widgets”, maybe it is not about changing the advertising or packaging, but discovering a whole new market. Let’s face it, selling widgets is what pays the bills, dismiss business objectives at your own peril, or form proposals that acknowledge and integrate them into better solutions.

 

 

3.

The solution
And last but not least, the proposed solution. Once you have your problem defined, you have ideas, you need to create a plan and make the idea actionable. This is where the “WHY?” and “WHAT?” meet the “HOW”. “How Might We…” (HMW) questions are questions that have the potential to spark ideation sessions. They should be broad enough for a wide range of solutions, but narrow enough that specific solutions can be created for them. The “Why-How Ladder” is a design thinking practice/exercise where the ultimate aim is to find out how you can solve one or more problems. Your How Might We questions will help you move from the definition stage and into the next stage in Design Thinking, the Ideation stage, where you start looking for specific innovative solutions. An iterative process, the “Why-How” cycle needs to be executed well to be productive. Asking “why?” endlessly can be counterproductive and lead to irrelevant information. On the other hand, it can be beneficial as it can expose hidden causes or new problems to address that can save time and money. It may even produce a deeper understanding of the initial challenge.  

 

POV and Context

When defining problems there are two things that you must consider: POV, the user’s point of view and context, the environment that sustains or produced the problem in which our solution must succeed. 

POV
A POV involves reframing a design challenge into an actionable problem statement from the user’s perspective. You articulate a POV by combining your knowledge about the user, his or her needs and the insights which you’ve come to know from empathy, quantitative and qualitative research. Your POV should be an actionable problem statement that will drive the rest of the design and development work. Understand not only what users need to do, but also what motivates them and what attitudes they have toward their tasks.

People do not talk about problems, in fact in many aspects of their lives, they are encouraged not to talk about problems. In addition, problems are correlated with fault, stakeholders may believe that when discussing a problem, someone will get blamed. Trust is a factor in any discussion of problems and POV, be prepared to transcend distrust, fear and negative attitudes that may become obstacles in your explorations. For example, In my time working in IT, I discovered that at times users would not share critical information with support because they feared being seen as unintelligent or inept when that was often not the view of the technician. It may sound cliche, but patience, kindness, and transparency can go a long way.  

Context
Context is important. At a macro level, context informs what technology should convey the design. At a micro level, context places restraints on interactions and the visual treatment of the interface. If the client does not provide all the details of the context, the design team may miss critical information to produce an effective solution. Understand the intended context of use by interviewing and observing users in their environment. Do not assume that your client has done the necessary research to uncover the needs of users. 

Conduct research directly with the intended audience. Also, context may have a historical dimension, make sure to research the background of an issue and see what may have contributed to it. Was this always a problem? When did it start? Did something change that contributed to it? Was anything tried before?  

 

 

Problem statements in practice

When business and user objectives are mapped out, designers can then create user flows that support desirable user behavior while satisfying user needs and aligning with their attitudes. This week we will return to the subject to our empathy map project, Vivint employees and their undercover boss, to develop 5 problem statement examples based on what we already know. 

 

 

In these examples, I attempted to define the problem without offering a solution. I also focused on actionable problems without including some of the source information emotional details. Being “out of touch” could mean better reporting mechanisms or observation practices. “Proper and appropriate gear” could mean a harness or better shoes. “Clearer phone connection” could mean a new phone, changed configuration on the computer or a change to the wall consoles. “Verifying work” could mean additional personnel, process or device. I have learned that defining problems and crafting problem statements is not easy. It requires a lot of thought, consideration of context, and balance between POVs. In many ways, you must don an investigator’s hat, get your magnifying glass out and deduce some conclusions, but they can’t be conclusive enough to pronounce a solution, that is yet to come. But with practice, you will make it seem “elementary…..my dear Watson!.” In short, Shawn needs to write well-crafted problem statements because he wants all his projects to be successful. 

Featured graphic by Shawn Torres. Sidebar Photo by rawpixel.com from Pexels

Resources & References

Benjamin, A. (2018). Design: How to define the problem. Medium. Retrieved from https://blog.prototypr.io/design-how-to-define-the-problem-5361cccb2fcb

Stage 2 in the Design Thinking Process: Define the Problem and Interpret the Results. (2019, September 24). Retrieved from https://www.interaction-design.org/literature/article/stage-2-in-the-design-thinking-process-define-the-problem-and-interpret-the-results

UX for Beginners: Defining the Design Problem. (2016, April 11). Retrieved from https://www.uxpin.com/studio/blog/ux-for-beginners-defining-the-design-problem

How/Why Laddering. (2019, September 24). Retrieved from https://dschool-old.stanford.edu/groups/k12/wiki/afdc3/HowWhy_Laddering.html

Orazulume, B. (2018). Wicked Problems => Design Thinking— Day 4. Medium. Retrieved from https://medium.com/ux-design-from-a-novice/design-thinking-day-4-8257db95cf57

Wicked Problems: Problems Worth Solving – Wicked Problem. (2019, September 26). Retrieved from https://www.wickedproblems.com/1_wicked_problems.php

Wicked Problems – Austin Center for Design. (2019, September 26). Retrieved from http://www.ac4d.com/our-work-philosophy-and-approach-to-education/understanding-wicked-problems

Wicked Problems: 5 Steps to Help You Tackle Wicked Problems by Combining Systems Thinking with Agile Methodology. (2019, September 26). Retrieved from https://www.interaction-design.org/literature/article/wicked-problems-5-steps-to-help-you-tackle-wicked-problems-by-combining-systems-thinking-with-agile-methodology

11 Successful Products Originally Invented for Something Else. (2015, October 08). Retrieved from http://mentalfloss.com/article/57861/11-successful-products-originally-invented-something-else

 

Recent Posts from the Graduate Series:


Shawn Torres is a freelance interactive designer and developer based out of Washington D.C. with a background in communications and information technology management. He has worked for a wide variety of industries and clients including Wunderman Thompson advertising, Human Rights Campaign, American Chemical Society, Fruit of the Loom and more. UX/UI is his passion. Designer, Developer, Daddy….Dreamer.