| back to the List |
A design problem – or just “problem” – describes the aspect of the world we want to make better. At its most abstract, a design problem describes an obstacle that prevents a user from accomplishing a goal. One view of design is that it’s methodology for solving problems. So the idea of “problem” comes up a lot in doing design.
The intent of this question varies with the tone. In some cases, it’s a prompt to reiterate the central design problem. The question is nearly rhetorical, a way to remind the team about what’s guiding their efforts. As a prompt, this question presumes that the team has taken steps to identify the problem, even if it’s not been well documented or articulated.
But the tone can also be genuine curiosity. Not rhetorical, but instead expressing a real need to articulate a problem. Through this question, I’m encouraging the team to be explicit in what aspect of the world we’re trying to fix, as they understand it.
This question is almost always directed at the core team – the main group of people tasked with developing the product. It’s crucial that this group is aligned in their understanding of the central problem that’s spurring the design process. If everyone on the team is going after a different problem, it will be difficult to feel confident about the solution.
But sometimes I ask myself this question. It’s grounding and reflective – meditative, even. It’s a way for me to refocus my effort and ensure the work I’m doing, even if it feels off track, at least contributes to the central purpose of the effort. A problem is, in essence, a purpose – a reason for doing what we’re doing. By asking this question of myself, I’m reminding myself of my purpose.
Sometimes I don’t know how to answer this question, so I rummage around in the project materials to find out what we’ve said before. What I’ll find is a previous incarnation of our problem statement. Or maybe I won’t find anything where we formally articulated the problem statement. It becomes an opportunity for me to restate, reframe, or just reveal the problem. It turns into an excuse to regurgitate the problem statement from whatever state it’s in right now and ensure we’re all on the same page with the problem we’re trying to solve.
When asking others, though, I’m listening for how they frame the problem – what aspects they emphasize, what perspectives they use. Maybe I’ll hear a difference with how they’ve framed it previously. Or maybe their response won’t align with my understanding of the problem. Noticing any of these discrepancies give us a chance to call attention to them and reconcile them. I usually transition into this stage of the conversation by saying “I want to make sure we’re aligned in the problem we’re trying to solve here.”
Sometimes, though, they say something completely unexpected. On a current project, the product manager is dealing with so many perspectives, variables, and pressures, the answer changes completely almost every time we ask it. Sometimes they state the problem from the user’s perspective and sometimes they will describe a feature we need to add to the product. Sometimes they’ll focus on the technical constraints. It can be whiplash, often shifting the problem space altogether. As above, I take this opportunity to clarify the problem. “Wait,” I’ll say, “I thought we were focused on this.” I don’t find these conversations discouraging (any more - I used to) but instead necessary to any design process, a constant effort to reframe and realign.
It seems like this is where you need to start design, by articulating the problem. You can ask this at the very beginning of a project, but I have a hypothesis about how design works. That hypothesis is that we never truly understand the design problem. We have, let’s say, an understanding that starts very blurry and comes increasingly into focus, but never reaching complete clarity. So, it’s worth asking this question again and again. Every activity in the design process brings the problem a little further into focus. As part of discovery, ask this question (or some version of it) after every activity. Finish a round of stakeholder interviews? Ask the team how they would characterize the design problem now. Run a baseline usability test? Ask the team about the design problem. Run a low-fi brainstorming effort? Ask about the problem. Every step offers increasing clarity, but we’ll never get at that problem in focus if we don’t ask.
I also raise this question, either with the team or with myself, when I get wrapped around the axle in doing the creative work. Sometimes this entails getting excited about an idea that doesn’t directly contribute to a meaningful solution. Sometimes this means getting too far into the irrelevant details of a possible diretion. Sometimes it’s when I step back and look at a design concept and think “there’s way too much going on here”. All of these are different symptoms of the same problem – losing sight of the purpose. Reminding myself or the team of the problem reminds us of our purpose, grounds us, and allows us to re-engage with the creative effort.
As a way to ground and refocus current efforts, the answer to this question usually leads to a series of questions to unpack the work so far, teasing out what’s aligned to the problem and what’s extraneous. So, one possible line of questioning involves flavors of, “How does this aspect of the design concept help solve the problem?”
But in asking the question, we the team might also see the problem in a new light, with better clarity or with a different emphasis. The line of questioning might instead be teasing out this new perspective. This line of inquiry includes questions like “What do we mean by…” and “How does this change our priorities?”
Have we solved the problem?
Instead of asking directly to articulate the problem, you can instead ask whether a design concept or potential solution actually addresses the problem. It’s a nice way of compeling the team to re-state the intent of the design, even articulating criteria defining what a good solution looks like.