Blogs

Build Action Guide: Capturing the Problem

By Georgina Donahue posted 07-11-2024 02:34 PM

  

Now that you've completed the Build course, it’s time to start Capturing the Problem.

Why Capture the Problem? 

In Foundations, you learned to identify market problems through NIHITO interviews. In Design, you developed research-driven user personas. Now, bring these elements together by capturing the problems and pain points within a persona and documenting key use scenarios. 

This task equips your Design and Development teams with essential market context, enabling them to connect deeply with your product's users and make informed solution decisions, resulting in stronger products. 

What To Do Next: 

  1. Start with a Persona: Clearly and objectively articulate a problem opportunity from the persona's perspective. Keep it concise, fitting each within the space of an index card.  

  1. Add the Use Scenario: Describe a story that highlights the condition the persona is experiencing, creating a problem for us to solve. Ensure you write problems from the persona’s point of view. 

  1. Detail the Frequency and Name It: Note how often the problem occurs and give it a short, memorable name for easy reference. 

Following these steps creates a clear, actionable guide (context + persona) for your team and serves as a foundation for ideation sessions. 

How Does It Help?

Developers often ask for more details, and designers may want to be involved earlier or reframe problems. What they really need is context to use their judgment. Instead of specifying solutions, provide more context. 

Start today and see the difference in your team's effectiveness and innovation.

1 comment
153 views

Related Content

Permalink

https://pac.pragmaticinstitute.com/blogs/georgina-cannie1/2024/07/11/action-guide-capturing-the-problem

Comments

Adam Baker
08-07-2025 06:31 PM

I recently used this when building documentation for a complex new product. I was having a hard time making sure I fully understood the new product so I spent time reviewing my notes from customer interviews. I found one specific user that I thought represented this persona very well. 

Let's call him Dan.

So built my notes thinking about the problems Dan was having and I made him the hero of my story - not the product. It really helped me simply the problem, and better understand the user story.