In day-to-day newsroom work, pain points and opportunities often surface as loose observations like "the CMS feels slow", "pulling data takes forever", "I wish we could make use of all these FOIA-ed pdfs", etc.
These are very valuable signals, but they are not actually actionable.
Before we start exploring solution ideas or evaluating possible tools we need to get super clear on what problem actually needs solving, who it impacts and what specific value a solution would provide.
Turning rough notes into structured Problem Statements is how we move from intuition to definition.
Problem Statement structure
[User] needs [need] so that [goal].
- User: Who is affected? (Reporter, editor, another specific role, a specific desk or team?)
- Need: What do they need to accomplish, avoid, or understand?
- Goal: Why does it matter? What's the bigger outcome or value?
Why bother creating Problem Statements?
They are the bridge between raw observations in the Empathize stage and informed, testable ideas in the Ideate stage.
Problem Statements help us:
Separate the problem from the solution
When frustrations or ideas are first shared, they often come bundled with assumptions about how to fix them. A structured format helps us pause long enough to understand what the user actually needs before we consider technical options. This protects us from prematurely choosing tools that don't solve the underlying issue.
Reveal gaps in our understanding
When you try to write a problem statement and something feels vague or missing, that's a signal that you need to go back and clarify with the people directly impacted by the situation. Ambiguity is often a sign that you do not understand the user experience well enough quite yet. Writing structured problem statements helps make those gaps visible.
Make the need specific and observable
A phrase like "reporters need an easier workflow" is too broad to design a solution around. The example statement below reveals who is affected, where the friction occurs, and why it matters - making the next stages of design thinking far more targeted and effective.
Metro reporters need to quickly find on-topic, on-the-record quotes in long city council meetings so that they can turn around accurate stories on deadline.
Build alignment across roles
Editors, reporters, researchers, product, audience, and business teams often use different shorthand to describe the same issue. Problem Statements give everyone a common language for discussing the user, the need, and the goal. When the group eventually evaluates ideas, they're all anchored to the same user need and goal.
Connect individual pain points to broader organizational goals
Writing the statement in a "so that…" format pushes us to explain why the need matters in practice. A strong organizational goal makes the downstream value or consequence visible: meeting deadline, avoiding missed context, improving accuracy, covering underheard communities more consistently, or reducing duplication. This helps teams efficiently evaluate which problems are meaningful and worth pursuing in what order.
Enable better brainstorming - and better solutions
Clear problem definitions unlock more creative, targeted ideation. Without them, groups tend to generate solutions that are either too generic, too technical, or disconnected from the actual need. Structured problem statements support better ideation and make it easier to compare ideas later.