What’s your problem?

No, seriously. It’s a good question to ask. So good that I made it a part of my design review process.

We all know that a problem statement is fundamental to well-designed solutions (because: well, what is a solution without a problem?). But I’ve been thinking about what else this little gem of a statement can do. I’ve seen a well-crafted problem statement drive a team of people who will rally, flex, and advocate as one unit to create better experiences. As ingrained as designing for problems is in the design community and education, I still see the step lacking the attention it deserves in practice.

How might we amplify the full value of the problem statement and empower designers? Do your designers have a safe venue to get constructive and supportive input/feedback on well-crafted problem statements? Do you assess and reinforce how well the solution solves the problem through every stage of your design and build process? Do you measure whether or not the problem has been solved and how well?

Support designers in problem articulation

Design review, “crit,” solution review, design pitch, stakeholder review… Every team has their process and nomenclature for reviewing the quality of designed solutions. I have found that these same processes can be used for review of problem articulation as well. It doesn’t have to be formal, but should be thoughtful; offering structure removes the guesswork for designers.

I ask designers for 3 simple bits of info. Here’s what I ask for, what I assess, and what I aim to offer as the design leader:

1. Request

Hearing how the request was made and who it came from is a signal of information if a designer is thrown into the middle of something that is unclear or ambiguous. How well does the requester describe the customer problem? Do they understand the software? Their role in the organization may be a signal about what the motivating factor is. Discussing requests that come in “blind” are a good stepping stone when trying to transform organizations to build from customer information. (Real talk: every team isn’t there. Rather than lecture on how designers should only be building from customer intel, let’s also talk about the steps we can take while in transition.)

Design leaders can potentially add value here by offering coaching to junior designers on how to engage those who made the request to get more intel, or can offer subject-matter or organizational insights that they may have due to the organic nature of being in different business meetings or customer engagements. I am always looking for how designers have considered trying to get the most context possible.

2. Situational landscape

Designers are curious by nature — this is the time to engage that curiosity. What is the existing product workflow or user experience where this issue is encountered? How is the usability? What else do we know about related issues on these surfaces? Designers should never skip this step, even when they have access to fully mature research methods with customers. Ultimately you are going to have to guide a team to build something; most of the time you are not starting from scratch. So get a lay of the land, and do some critical thinking.

Here I look for completeness. Does this cover the variety of scenarios possible? Have they captured the task end to end? How is their judgement on the existing scenario; do they understand the landscape of the use case, technology and business situation? Are they seeing it with fresh eyes? Or might I offer an expanded or alternative view on what’s there?

3. Draft problem statement

There’s plenty of literature and training on well-structured needs or problem statements, from design-thinking to Six Sigma. But to create an informal and speedy checkpoint I really look for this:

When we craft a solution for this thing, will I be able to assess whether or not this problem was solved?

I see a few patterns when folks are learning how to incorporate this into practice:

Misplaced focus. When the statement is formed around the business need, or the team itself, or why the thing is so hard to deal with from an internal perspective, they are off the mark. That’s an easily redirected effort. These conversations are also a good time to clarify what ‘customer’ means in the situation. In fact, I can’t remember in 15+ years of leading design teams when ‘customer’ or ‘user’ was specific enough to describe a real problem; usually there is a better way to describe the person you are solving for. Is it a shopper? A patient? A small business owner? A driver? A parent? Demographics only matter when they matter — who has the problem?

Too lofty or abstract. Being literal about what the user needs out of this portion of the journey is one of the ways that you’ll be able to answer whether or not the problem was solved. For example, in e-commerce, if a person needs more information about a piece of furniture they may buy and that information is hard to find, then that discovery issue should be the focus (not, for example, furnishing their home).

Making assumptions and/or jumping to the solution. This is not just seen with junior designers; I see this often from experienced designers who are simply out of practice stopping at this stage — if they move quickly and have been “doing it in their heads’’ for too long, it can be a muscle memory to re-develop. Again using the e-commerce example, the assumption that the shopper intends to purchase may be misguided — do they need to buy the furniture? Or do they need to understand the specs? Assuming that if the shopper understood the specs that they would want to buy may lead to designing for the transaction rather than understanding.

Reinforce the problem statement

Putting energy into ensuring that designers are crafting great problem statements begs for reinforcement throughout the lifespan of that solution as well (in other words, make sure you get that return on investment!). Here are a few ways I’ve seen it work well; it can be as simple as a conversation to get these things moving at your company:

• Headliner. The problem statement should be the headliner in all presentations or documents — the first slide/screen/page/artboard. Every. Single. Time. Call it out when it’s not there. It should appear so often that people moan or laugh when they see it and can recite it from memory. Then show it again.
• Meeting opener. The problem statement is the starting point for every stakeholder meeting. Even if already discussed. Most stakeholders work tens or hundreds of problems at a time; ground every conversation back at the problem being solved.
• Codified for tracking. Codify the problem statement by adding it to any workforce tracking systems, such as Jira or Asana (rename the tasks!). This is great prep-work for a designer to do for a grooming/planning meeting with their multi-disciplinary team.
• Focus of research plans. Use the problem statement to center plans on how to validate the efficacy of the solution. Research (quant or qual) is derived from it and aligned to it.

Encourage designers to lead conversations based on the problem

Designers can be in possession of the most critical element of success — the problem — by (1) instituting a quality checkpoint on the problem statement such as in design review, (2) gaining alignment and co-ownership of the problem with the team working on it, and (3) reinforcing it throughout the project lifespan. This means they can step into the role of guiding their colleagues through the process of understanding and aligning to it; everyone can remain focused on solving the problem (rather than, say, checking things off a list or shipping code). Discussions on prioritizing team time becomes: which problems are we prioritizing? Inevitable conversations about technical or business constraints now sound like: how might we still manage to solve this problem for this person? Discussions on whether or not to build a new design system component or use an existing one now sound like: if we use the old component are we still solving the problem?

Another benefit of all this reinforcement is setting up designers with meaningful stories about their work. Whether for their next job at your company or another one, it’s the design leader’s job to provide tools and opportunities for growth.

“I solved [a problem]” is so much more compelling, powerful, and rewarding than “I made [a widget].”

Let’s give everyone involved (designers, engineers, product and project leaders, and more), a chance to tell that story. The first step is to know what that problem is.

Layering depth beyond the problem

Once your team has built the muscle of crafting problem statements and reinforcing them through conversations and measurement, the next logical step is quality and depth of the solution. In other words, moving from “how might we solve this problem?”, to “how well do we solve this problem”?