In UX design, understanding user needs is the cornerstone of building solutions that truly resonate. Traditional tools like problem statements have long served this purpose, offering detailed snapshots of user challenges alongside context and business implications. But there’s a newer contender — the Struggle-Focused Approach (SFA) — which strips things down to the essentials: the user’s immediate pain point and blocked goal. If you’re wondering whether SFA is just a redundant twist on problem statements or a valuable addition to your toolkit, this article combines two perspectives to show how SFA stands apart and why it’s worth embracing. By focusing solely on the user’s struggle in a concise, accessible way, SFA complements rather than competes with existing methods, enhancing your design process from discovery to delivery.
Understanding SFA and Problem Statement: Definitions and Practical Examples
1. SFA is Concise and User-Centric; Problem Statements Are Detailed and Comprehensive
SFA: This approach distills the user’s experience into a short, user-voiced statement. For example:
“As a frequent shopper, I’m struggling with a slow login that stops me from accessing my account quickly.”
It’s quick to jot down and laser-focused on the user’s pain point, making it perfect for capturing insights on the fly.
Problem Statement: This is a fuller narrative, weaving in context and consequences. For example:
“Users face delays in logging in due to outdated authentication methods, resulting in frustration and a 15% drop in daily logins.”
It’s built for depth — ideal for documentation or stakeholder buy-in.
Why SFA Stands Out: SFA’s brevity shines in real-time settings like user interviews, where speed and clarity trump elaboration. Problem statements, while robust, can feel heavy for rapid discovery.
2. SFA Keeps Solutions Out; Problem Statements Can Hint at Them
SFA: It’s all about the struggle, not the fix. For example:
“As an online banking customer, I’m struggling with remembering passwords, which stops me from logging in easily.”
No solutions sneak in — leaving space to explore whether the issue is passwords, logins, or something else entirely.
Problem Statement: It might subtly steer you toward a fix, especially with business framing. For example:
“Users struggle with the current login system, causing delays.”
This hints at tweaking the system rather than rethinking the root cause.
Why SFA Stands Out: By staying solution-agnostic, SFA keeps your mind open during early exploration, preventing premature conclusions about what users need.
3. SFA Fuels Discovery; Problem Statements Drive Planning
SFA: It thrives in the empathize and define phases of design thinking, helping you spot and prioritize struggles quickly. It’s about uncovering problems.
Problem Statement: It’s suited for later stages — define and ideate — where you need context to align teams and plan solutions. It’s about framing problems for action.
Why SFA Stands Out: SFA anchors you in raw user insights during research, while problem statements polish those insights for execution. They’re a tag team, not rivals.
4. SFA is Simple for Everyone; Problem Statements Can Get Technical
SFA: Its plain language — like “I’m struggling with finding the right button” — invites anyone (users, support staff, product managers) to contribute without a learning curve.
Problem Statement: It often dips into UX-speak or metrics. For example:
“Users experience friction due to poor visual hierarchy, leading to a 20% task failure rate.”
That can exclude non-designers.
Why SFA Stands Out: SFA’s simplicity makes it a universal tool, breaking down barriers so everyone can pitch in on capturing user needs.
5. SFA Enhances, Doesn’t Replace, Problem Statements
How They Work Together: SFA grabs the raw struggle, and problem statements build on it. For example:
SFA: “As a smart home user, I’m struggling with finding the right button, which stops me from setting the temperature I want.”
Problem Statement: “Users struggle to locate the primary action button due to poor visual hierarchy, leading to task abandonment.”
Not Redundant: SFA seeds problem statements with authentic user pain, grounding them in reality rather than guesswork.
Why SFA Stands Out: It’s a springboard that sharpens your problem statements, making them more precise and user-driven.
Key Differences Between SFA and Problem Statements
Here’s a quick breakdown:
Level of Detail:
SFA: Short, spotlighting the struggle and blocked goal.
Problem Statement: Detailed, including context, causes, and impacts.
Purpose:
SFA: Captures pain points fast, perfect for research and ideation.
Problem Statement: Aligns teams with a comprehensive issue overview, ideal for planning.
Focus:
SFA: Purely user-centric, no business lens.
Problem Statement: Often blends user needs with product or business stakes.
When to Use Each:
SFA: Early on, to identify and prioritize struggles during discovery.
Problem Statement: Later, to formalize issues for stakeholders and execution.
The Bottom Line
If you think problem statements already do the job, SFA might seem like overlap — but it’s not. It’s:
Faster: Captures struggles in the moment.
Stricter: Locks out solutions to keep focus on the problem.
Simpler: Welcomes everyone into the process.
Picture SFA as a scalpel — sharp and user-focused — and problem statements as a Swiss Army knife — multifaceted and thorough. Together, they make your UX toolkit stronger, ensuring user struggles stay front and center from start to finish. SFA isn’t here to replace; it’s here to refine and elevate.