Problem
How to present a problem clearly enough for viewers to understand who is struggling, where friction exists, what causes it, and why it is worth solving.
Do not begin with the solution
Many project stories start with “we redesigned,” “we built,” or “we launched.”
Without a clear problem, those are activities rather than justified responses.
A problem is not a symptom
Low conversion, user drop-off, or slow teams are often symptoms.
The problem may be unclear pricing, fragmented information, ambiguous ownership, or missing context.
Framework: Who → Friction → Cause → Consequence
Who — who is affected?
Friction — what blocks desired behavior or outcomes?
Cause — what is driving that friction?
Consequence — what continues if nothing changes?
Who: anchor the problem to a specific actor
“Users struggle” is too broad.
New users, returning customers, sales teams, managers, and operations teams behave differently.
Friction: describe the obstacle
Friction may be cognitive load, lack of trust, too many steps, inconsistent information, slow response, or manual process.
Cause: look beyond what is easiest to see
Checkout drop-off may not be a visual design problem. It may come from pricing confusion, hidden fees, limited payment options, or weak trust signals.
Consequence: explain why the problem matters
What happens if nothing changes? Lost revenue, longer cycle time, more errors, lower trust, wasted capacity, or churn.
Problem framing is a form of judgment
Two people can look at the same data and frame different problems.
Your framing reveals analysis, prioritization, and understanding of the system.
Applying this on Forwork
Each Project should include a standalone Problem block: who is affected, what friction exists, what causes it, and what consequence follows.
Conclusion
Do not ask “What did we build?” before answering “What problem were we actually solving?”
Who → Friction → Cause → Consequence.