Drafting and Structure

Problem-Solution Narrative Outline

Build a factual narrative that defines a problem, explains its mechanism, evaluates possible solutions, and preserves evidence, tradeoffs, and limitations.

Free editable Markdown · Writers, content marketers, and editors · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Problem definition

Reader and situation: [Describe]
Desired outcome: [Enter]
Observable problem: [What happens?]
Frequency and consequence: [Evidence]
Who or what is outside scope: [Enter]
Sources and firsthand evidence: [List]
Assumptions to test: [List]
Unknowns: [List]

Cause map

Symptom: [Enter]
Possible mechanism: [Explain]
Evidence for mechanism: [Reference]
Alternative explanation: [Enter]
Reader control or constraint: [Describe]
Specialist question: [Enter]
Causal language justified: [Yes / No / Unclear]

Option comparison

Duplicate for each option.

Option: [Do nothing / Process change / Existing tool / Proposed solution / Other]
Mechanism addressed: [Enter]
Evidence: [Reference]
Prerequisites: [List]
Effort, cost, and time: [Enter]
Risk and reversibility: [Enter]
Limitations and poor-fit cases: [Enter]

Narrative and review

Opening evidence: [Direct problem statement]
Problem explanation sequence: [List headings]
Solution evidence and example: [Enter]
Required limitation placement: [Enter]
Useful closing action: [Choose, test, read, or seek help]
Reviewer and update trigger: [Name/date/trigger]

No unsupported urgency, fear, or universal claim appears.
Alternatives receive a fair and useful explanation.

How to use this template

Define the affected reader, observable problem, consequence, boundaries, and evidence.
Map symptoms, contributing mechanisms, competing explanations, and unresolved questions.
Compare reasonable options using explicit criteria before choosing a featured solution.
Connect the selected solution to evidence, prerequisites, limitations, and failure paths.
Review every claim and ensure the closing action follows from what the narrative established.

Establish the problem with observable evidence

Describe the affected reader's situation, desired outcome, current barrier, frequency, and consequence. Separate direct evidence—research, support themes, task observation, or first-party data—from assumptions. Avoid opening with a universal emotional claim, invented statistic, or isolated anecdote treated as typical. Define who is not affected and what remains unknown. If the content creates a problem category that only the promoted product can solve, ask whether the page is informing readers or manufacturing anxiety. A credible narrative allows readers to recognize whether the problem matches their own circumstances.

Explain mechanisms and alternatives before selecting a solution

Identify contributing causes and distinguish them from symptoms. One observable failure may have product, process, knowledge, access, or environmental causes requiring different responses. Present reasonable alternatives, including doing nothing, using an existing feature, changing a workflow, or seeking specialist help. Then define selection criteria such as effectiveness, effort, cost, safety, compatibility, reversibility, and evidence. This prevents a solution from appearing inevitable merely because alternatives were omitted. When evidence supports association rather than cause, use language that preserves that boundary.

Connect the proposed solution to bounded proof

Explain what the solution does, which mechanism it addresses, prerequisites, implementation, expected outcome, limitations, and failure modes. Support each material benefit and comparison with current evidence. Use a clearly scoped example rather than an unrepresentative success story, and do not transform customer experience into a typical-result promise. The conclusion should help readers choose an appropriate next action, which may be to gather more information or select another option. Record maintenance triggers because changing product behavior or evidence can break the problem-solution connection.

See the fields in context

Fictional example: inconsistent terminology

The team and workflow are invented; the example does not claim measured business results.

Problem: Fictional help articles use three names for the same setting, and readers report difficulty finding it.
Mechanism: Uncontrolled terminology across product and support copy; evidence comes from an imaginary content audit.
Options: Add synonyms everywhere, rename the interface, or adopt one term with transitional cross-references.
Selected approach: A controlled glossary plus phased updates because it addresses consistency without an immediate interface migration.
Limitation: The approach does not solve unrelated navigation or product-discoverability problems.

Frequently asked questions

How much space should the problem receive?

Enough to establish relevance, mechanism, scope, and consequence without delaying useful options or amplifying fear.

Must the featured product be the only solution?

No. Present credible alternatives and poor-fit cases so readers can make an informed choice.

Can a personal story establish the problem?

It can illustrate one experience, but broader claims need broader evidence and clear limits.

How should the conclusion work?

Offer an action justified by the evidence and reader situation, including further research or no change when appropriate.