Good frameworks have the following in common: they ask appropriate questions, understand and assess a goal (often a good user experience), and apply a structured approach to accomplish that goal.
Step 1: Ask questions to understand the problem
Before you can even start to answer the question, you need to make sure you understand what the question is. It might not be what you think. For example, suppose you were asked, “Design a pen.” That’s a pretty straightforward question, right? Not necessarily.
The pen could be:
- A permanent marker, designed to not come off in the laundry.
- A pen that uses ink that only shows up under special lighting.
- A pen for astronauts to use in space.
- A pen for children to use in the bathtub.
- A pen for scuba divers to use.
Clearly, each of those people would need a very different pen. They would need
a different size, color, and feature set. Are they trying to trick you? Yep, in a sense. However, a PM who just dives into creating a product without understanding the goals might create something that is radically different from what the user needs.
Step 2: Provide a structure
The easiest way to show this is to give a structured answer and call out which part of the structure you’re on. For example, you might say something like, “First I’m going to talk about the goals. Then, I’m going to list out some potential features. Finally, I’m going to evaluate each of those features against the goals. Okay, so starting with the goals…”.
Step 3: Identify the users and customers
Now that you understand the question itself, you should identify who the users
and customers are. Ask more questions if you need to. In some cases, the users and customers aren’t the same person. The customer is the person paying for the product; the user is the one using it. There also may be multiple users.
Thinking about Users
With each question, think about where the product is being used and who else might interact with it. As a good rule of thumb:
- Children’s products may be used by children, their parents, and their teachers. The parent or the school might be the customer.
- Healthcare products (including products for people with disabilities) might
be used by patients, doctors, and insurance companies.
- Sports-related products might be used by athletes and their coaches.
- Products for a professional (e.g., accounting software) might be used by the professional, her assistant, and others in her company.
We have to design for all of those people, so it’s important to call out who they are.
Step 4: What are the use cases? Why are they using this product? What are their goals?
For each user (if there’s more than one), make a list of the use cases. This is a list of the different tasks or scenarios that a user might want to use the product for. For example, if we’re designing a keychain for the elderly, the use cases might include:
- Locating the right key in the keychain to open their house, enter their car,
- Adding a new key to the keychain.
- Removing a key from the keychain.
- Finding the keys in the bag.
- Finding the keys in their house.
You’ll need to assess, either by yourself or by discussing the situation with your team, which use cases to design for. You might decide that all of them are very important, or you might decide that some use cases are less important than others.
You can also think about these goals at a higher level. You can think about not only what you do with a product, but why you do it. What is the underlying motivation? For example, the underlying motivation for the keychain might be independence.
Step 5: How well is the current product doing for their use cases? Are there obvious weak spots?
Go through each use case and assess how well the current products or solutions address those. What are the user’s biggest issues with the product? These are the areas you will focus your design on. If there are multiple users (for example, the elderly person and their caretaker), we may need to assess their use cases separately.
In many cases, and especially when you get a question in the form of “Design a _______ for the _______,” it can be useful to think carefully about what makes this type of user special. For example, an elderly person often has limited mobility and dexterity, but they are about more than just their limitations; they also have particular values. They might care deeply about family connections, or prioritize healthcare or stability. We’ll need to keep this in mind for our design.
Step 6: What features or changes would improve those weak spots?
Up until now, we’ve just been assessing the current problem and needs. It’s good we spent all that time defining the problem. This will help us come up with a solution that’s truly tailored to their needs, rather than to what you personally would want.
In many cases, we will want to solve the issues with multiple use cases at once. For example, the solution to adding a key to the keychain is very closely tied to the solution to remove a key from the keychain.
Make sure to explicitly tie your feature ideas to the use cases or goals. Make it really, really clear you’re coming up with ideas that are customer-focused, not just things you’ve always wanted. If you start to run out of ideas, go back to your use cases and be willing to get a little more creative.
Step 7: Wrap things up
As a final step in the meeting, it can be useful to give the stakeholders an overview of your solution. This is especially important if you’ve been talking for a while. You might have gone over many solutions to the problem, and your stakeholders may be unclear as to your current proposal.
If you haven’t touched the whiteboard yet, this may be a good time to do so.