Perspectives Blog

Intro

Frustrations are incredibly powerful tools to slice into experiences. Frustrations are memorable. They will be potent. Initially only ‘white hot’ painful frustration is worth solving. If the pain is lukewarm, inertia may well win. If the pain isn’t memorable, it was not painful enough. A sort of classification of pain points is necessary. People (especially Americans) love to complain! Asking the question "When was the last time while using [x tool] you wanted to throw your phone on the ground? What had just happened?" is a great way of getting at those painful points and knowing how to classify them.

‍

NOTE: This might not work as well in other cultures who don't have a culture of complaining. For example, in most Asian cultures (or ME/NA) complaining is not as much of a cultural norm.

‍

Part 1: Understanding User Frustrations

Remember that simply understanding user frustrations isn’t the end goal; all the insights you gather, the frustration you better understand are all leading up to building a better product and helping people. Understanding the user's frustrations are going to help you build better solutions.

If the pain is white hot or recent, personal - all the things that make it white hot, a user might be more willing to share about it - or if they’re someone who likes to complain. BUT keep in mind that is not always the case! There are many reasons people don’t complain or bring up frustrations - culture, societal, personal principles can all play a role. You might have to tease it out, establish this is a safe place for them to share frustrations and concerns. Also remind them that their SPECIFIC feedback is valuable! Their unique experience, whatever that might be - positive or negative - is useful! Ask questions about what blocked them, where they were confused, or if something happened that they did not expect.

Knowing what the frustration is is not enough though, you need to know where and when it happened. A useful framework to find out these facts is the JTBD framework.

‍

Part 2: Exploring the Jobs to Be Done framework

The Jobs to Be Done framework helps us understand why a user uses a product. It also helps us understand how they use it. The “jobs” in the Jobs to Be Done framework, refers to the tasks, goals, or problems that customers are trying to accomplish or solve when using a product or service. These jobs represent the underlying motivations that drive customers to find a specific solution. These jobs go beyond a product or service and look at what the customer is trying to achieve as a whole.

Jobs can be categorized in two ways:

Functional Jobs: the tasks or objectives that the user is trying to do or solve. Users choose a product or service based on what they are trying to accomplish.

‍Emotional Jobs: These jobs relate to the emotional and social aspects of a user’s experience. Emotional jobs encompass how a user wants to feel or be perceived when using the product or service.

The better you understand what jobs the user is trying to accomplish, whether emotional or functional, the better you will understand their frustration! For example, a user who wants to send money to a friend has a functional job to complete - sending money. As they send the money, they might want to feel, like a good friend, someone who handles their responsibilities quickly and well. There’s also the social aspect of “how do other people see me and think of me?” The money sender might want to be seen as responsible or maybe generous. A product might help a user complete some of the jobs, but miss others. Let’s say you pay your friend back, but you’re down to the penny and they see you as being cheap vs reliable and conscientious. The functional job (paying back a friend) is complete, but the emotional (social) job is not.

Understanding both the functional and emotional jobs will help you understand what your user is trying to accomplish and where they might be getting frustrated!

‍

Part 3: Deciding which frustrations to solve.

The Jobs To Be Done framework is incredibly powerful when you’re trying to figure out what the user is trying to accomplish, but you can take it a step further. This framework might reveal many many many frustrations the user is experiencing. How do you decide which ones to solve first? What are the most important, white hot, and potent ones? We’ve all experienced scope creep - where you started out to solve one thing and ended up trying to solve EVERYTHING. What usually ends up happening (if you don’t catch scope creep early) is you run over budget in time and money, or you stay within those, but end up solving everything only partially. Solving all the problems partially might end up creating more frustration for your users. So, the real issue is figuring out how to prioritize what frustrations to solve.

We suggest using methods like MoSCoW. With this method researchers can prioritize frustrations by identifying "Must-solve" ones that have a significant impact on the user experience. “MoSCoW” stands for 'Must-solve,' 'Could-solve,' 'Should-solve,' and 'Won't-solve.’ If you categorize the user frustrations you uncover into these sections you are much more likely to find the most frustrating part of the experience and come up with a solution for it.

Asking a question like “what had just happened the last time you wanted to throw your phone on the ground” gets at those more critical “must-solves” and brings some humor and playfulness into the conversation. It guides the conversation to specific events which can reveal more and more accurately pain points than general impressions or thoughts about a product or service.

‍

Conclusion

In conclusion, if you can understand where your users are getting frustrated, you can find out where you can improve the experience and product. Remember, only those white-hot, memorable pains are worth solving at first. The first part of this process is unearthing the user’s frustrations - keep reminding them that their unique experience (even a negative experience!) is valuable. Use pointed questions on specific events to get at those frustrations. You can also use the Jobs To Be Done framework to dig into 'why' and 'how' of user actions and what they’re trying to accomplish. Once you have the frustrations in hand, remember not all user frustrations are created equal. To avoid scope creep and address the most critical issues first, use methods like MoSCoW. Categorize frustrations into 'Must-solve,' 'Could-solve,' 'Should-solve,' and 'Won't-solve' to pinpoint the most impactful areas for improvement.

‍

Further Reading / Resources

https://adampdarcy.medium.com/jtbd-outcome-based-product-roadmapping-b6e3438b7f0c

https://uxdesign.cc/personas-jtbd-user-needs-goals-pain-points-7eaa81976f0

‍