For the more seasoned Product Designers or UX folks out there, this may be elementary. However, I’ve found that doing a brain dump of my own knowledge is helpful. It both builds my own process and points out areas that I’m weak in.

When a client comes to me with a project, the ask seems to fall on a spectrum. On one end, there’s the open-ended “I don’t know what the hell I want” request. Full of possibilities and unanswered questions. The opposite: “I know exactly what I want and it would be great if you could just build it for me. Please only ask questions if you don’t understand what I want.” In between these two points are varying levels of uncertainty.

If you’re a designer or inclined to be a problem solver, the first half of the spectrum is a lovely place to be. The client knows that they don’t know everything yet - and they want our help to define the project. This allows for in-depth research, analyzing audiences, and asking the triggering question of “Why are we making this?” We get to partner with the client rather than produce for the client.

To be on the other end of the spectrum feels like a trap. Even if the plan that’s been laid out in front of you seems to make sense, all the major strategy has been taken out of it. You might feel like a droid going through programmed commands. Innovation or changes are considered risky, and could upset the client. The more fundamental problem is that the first part of the process never occured. The stuff that comes before creating something.

If I’m currently in this latter space, my biggest concern is that the problem may have not been defined up front. I’m worried that we don’t understand what the true goal is. I’m worried that we will get lost in details that provide no end value. I’m worried that we’re trying to design for something very unspecific, like an app that everyone will use.

Most things are not for everyone. And even if you are a very optimistic person, and imagine your product penetrating every device across the world, you don’t want to start there. You need to get more specific. Specific problems allow for specific solutions.

I’ve generated an incomplete list of questions that can help define problems when working on digital products. These questions could help me wiggle out of a “solution” that won’t work or be discussion starters.

• What problem are you trying to solve?
• Who is it for?
• Who is your ideal person? Be specific (age, gender, demographic, financial status, cultural references, etc). If multiple, define them all.
• What stressful or problematic situations do they find themselves in?
• What does your ideal person’s daily life look like?
• What are they trying to accomplish? What is their goal?
• How would they find your product?
• How do they feel before they use your product?
• How should they feel after using your product?
• How would you explain your product to your ideal person if you met them at a coffee shop?
• How would a user explain your product to one of their friends?
• What other solutions exist that solve their problem (digital or otherwise)?
• Are these other solutions insufficient? Why?
• What makes your product different from other solutions?
• What kind of technology is your user accustomed to?
• Are you hoping the user changes their behavior? Or are you hoping to integrate with something they are already doing?
• What dependencies make your product successful (like improved technology or well written content)?
• What are hurdles that prevent the user from using your product?
• What are your users typical consuming/entertainment/research behaviors?
• Have you done any user interviews? If so, what did you learn?

If I can’t answer most of these questions, then I don’t feel like I have adequate enough information to do a good job. Often, these questions are left to be teased out in various meetings and review cycles. In an ideal world, something like this is worked into a client onboarding process. A friendly questionnaire of sorts. Things do change as the process continues, and it makes sense to review these questions regularly.