268 lines
8.9 KiB
Markdown
268 lines
8.9 KiB
Markdown
# Content Frameworks Reference
|
|
|
|
Quick-reference guide for structuring blog posts and articles. Use these templates as starting points, then adapt to the topic and audience.
|
|
|
|
---
|
|
|
|
## Article Templates
|
|
|
|
### How-To Guide
|
|
|
|
```
|
|
Title: How to [Achieve Specific Outcome] (in [Timeframe/Steps])
|
|
|
|
Introduction
|
|
- State the outcome the reader will achieve
|
|
- Briefly explain why this matters or who this is for
|
|
- Set expectations: what they need, how long it takes
|
|
|
|
Prerequisites / What You'll Need (optional)
|
|
- Tools, knowledge, or setup required before starting
|
|
|
|
Step 1: [Action Verb] + [Object]
|
|
- What to do and why
|
|
- Concrete details, examples, or code snippets
|
|
- Common mistake to avoid at this step
|
|
|
|
Step 2: [Action Verb] + [Object]
|
|
- (same pattern)
|
|
|
|
... (repeat for each step)
|
|
|
|
Troubleshooting / Common Issues (optional)
|
|
- Problem → Cause → Fix, in a quick table or list
|
|
|
|
Conclusion
|
|
- Recap what the reader accomplished
|
|
- Suggest a logical next step or related guide
|
|
```
|
|
|
|
**Key principle:** Each step starts with an action verb. One action per step. If a step has sub-steps, break it out.
|
|
|
|
---
|
|
|
|
### Listicle
|
|
|
|
```
|
|
Title: [Number] [Adjective] [Things] for [Audience/Goal]
|
|
Examples: "9 Underrated Tools for Frontend Performance"
|
|
"5 Strategies That Reduced Our Build Time by 60%"
|
|
|
|
Introduction (2-3 sentences)
|
|
- Who this list is for
|
|
- What criteria you used to select items
|
|
|
|
Item 1: [Name or Short Description]
|
|
- What it is (1 sentence)
|
|
- Why it matters or when to use it (1-2 sentences)
|
|
- Concrete example, stat, or tip
|
|
|
|
Item 2: ...
|
|
(repeat)
|
|
|
|
Wrap-Up
|
|
- Quick summary of top picks or situational recommendations
|
|
- CTA: ask readers to share their own picks, or link to a deeper dive
|
|
```
|
|
|
|
**Key principle:** Each item must stand alone. Readers skim listicles — front-load the value in each entry. Order by impact (strongest first or last) or by logical progression.
|
|
|
|
---
|
|
|
|
### Comparison / Vs Article
|
|
|
|
```
|
|
Title: [Option A] vs [Option B]: [Decision Context]
|
|
Example: "Postgres vs MySQL: Which Database Fits Your SaaS in 2026?"
|
|
|
|
Introduction
|
|
- The decision the reader faces
|
|
- Who this comparison is for (skill level, use case)
|
|
- Summary verdict (give the answer up front, then prove it)
|
|
|
|
Quick Comparison Table
|
|
| Criteria | Option A | Option B |
|
|
|-----------------|----------------|----------------|
|
|
| [Criterion 1] | ... | ... |
|
|
| [Criterion 2] | ... | ... |
|
|
| Pricing | ... | ... |
|
|
| Best for | ... | ... |
|
|
|
|
Section: [Criterion 1] Deep Dive
|
|
- How A handles it
|
|
- How B handles it
|
|
- Verdict for this criterion
|
|
|
|
(repeat for each major criterion)
|
|
|
|
When to Choose A
|
|
- Bullet list of scenarios, use cases, or team profiles
|
|
|
|
When to Choose B
|
|
- Same structure
|
|
|
|
Final Recommendation
|
|
- Restate the summary verdict with nuance
|
|
- Suggest next steps (trial links, related guides)
|
|
```
|
|
|
|
**Key principle:** Be opinionated. Readers come to comparison articles for a recommendation, not a feature dump. State your pick early, then support it.
|
|
|
|
---
|
|
|
|
### Case Study
|
|
|
|
```
|
|
Title: How [Company/Person] [Achieved Result] with [Method/Tool]
|
|
|
|
Snapshot (sidebar or callout box)
|
|
- Company/person profile
|
|
- Challenge in one line
|
|
- Result in one line (with numbers)
|
|
- Timeline
|
|
|
|
The Challenge
|
|
- Situation before: pain points, constraints, failed attempts
|
|
- Why existing solutions weren't working
|
|
- Stakes: what would happen if unsolved
|
|
|
|
The Approach
|
|
- What they decided to do and why
|
|
- Implementation details (tools, process, decisions)
|
|
- Obstacles encountered during execution
|
|
|
|
The Results
|
|
- Quantified outcomes (before/after metrics)
|
|
- Qualitative outcomes (team sentiment, workflow changes)
|
|
- Timeline to results
|
|
|
|
Key Takeaways
|
|
- 2-4 lessons the reader can apply to their own situation
|
|
- What the subject would do differently next time (if anything)
|
|
```
|
|
|
|
**Key principle:** Specifics beat generalities. Use real numbers, timelines, and named tools. A case study without measurable results is just a testimonial.
|
|
|
|
---
|
|
|
|
### Thought Leadership
|
|
|
|
```
|
|
Title: [Contrarian Claim] or [Reframed Problem]
|
|
Examples: "Your Microservices Migration Will Fail — Here's Why"
|
|
"We've Been Thinking About Developer Productivity Wrong"
|
|
|
|
The Hook
|
|
- A bold claim, surprising stat, or industry assumption to challenge
|
|
- One paragraph max
|
|
|
|
The Conventional View
|
|
- What most people believe or do today
|
|
- Why it seems reasonable on the surface
|
|
|
|
The Shift
|
|
- What's changed (new data, your experience, a trend)
|
|
- Why the conventional view no longer holds
|
|
- Evidence: data, examples, analogies
|
|
|
|
The New Mental Model
|
|
- Your proposed way of thinking about this
|
|
- How it changes decisions or priorities
|
|
- 1-2 concrete examples of the new model applied
|
|
|
|
Implications
|
|
- What readers should do differently starting now
|
|
- What this means for the industry over the next 1-3 years
|
|
|
|
Close
|
|
- Restate the core insight in one sentence
|
|
- Invite discussion or point to your deeper work on this topic
|
|
```
|
|
|
|
**Key principle:** Thought leadership requires a genuine point of view. The article should change how the reader thinks, not just inform them.
|
|
|
|
---
|
|
|
|
## Persuasion Frameworks
|
|
|
|
### AIDA (Attention, Interest, Desire, Action)
|
|
|
|
Use AIDA to structure the emotional arc of an article, especially product-adjacent or tutorial content.
|
|
|
|
| Stage | Purpose | Tactics |
|
|
|-------|---------|---------|
|
|
| **Attention** | Stop the scroll. Earn the click. | Surprising stat, bold claim, relatable pain point in the title and opening line. |
|
|
| **Interest** | Convince them to keep reading. | Show you understand their situation. Introduce the core concept or framework. Use subheadings that promise value. |
|
|
| **Desire** | Make them want the outcome. | Show results: examples, screenshots, before/after. Paint a picture of life after applying the advice. |
|
|
| **Action** | Tell them what to do next. | Specific, low-friction CTA. One action, not five. "Clone the repo," "Try this query," "Read part 2." |
|
|
|
|
---
|
|
|
|
### PAS (Problem, Agitate, Solution)
|
|
|
|
Use PAS for introductions, email content, and articles addressing a known pain point.
|
|
|
|
| Stage | Purpose | Tactics |
|
|
|-------|---------|---------|
|
|
| **Problem** | Name the pain clearly. | Describe the situation in the reader's own words. Be specific — "your CI pipeline takes 40 minutes" beats "slow builds." |
|
|
| **Agitate** | Make the pain feel urgent. | Show the consequences: wasted time, lost revenue, compounding tech debt. Use "what happens if you don't fix this" framing. |
|
|
| **Solution** | Present the path forward. | Introduce your approach, tool, or framework. Transition into the body of the article. |
|
|
|
|
PAS works best in the first 3-5 paragraphs, then hand off to a structural template (How-To, Listicle, etc.) for the body.
|
|
|
|
---
|
|
|
|
## Introduction Patterns
|
|
|
|
Use one of these patterns for the opening 2-4 sentences. Match the pattern to the article type and audience.
|
|
|
|
**The Stat Drop**
|
|
Open with a surprising number, then connect it to the reader's world.
|
|
> "73% of API integrations fail in the first year — not because of bad code, but because of bad documentation."
|
|
|
|
**The Contrarian Hook**
|
|
Challenge a common belief head-on.
|
|
> "You don't need a content calendar. What you need is a content system."
|
|
|
|
**The Pain Mirror**
|
|
Describe the reader's frustration in their own words.
|
|
> "You've rewritten the onboarding flow three times this quarter. Each time, engagement drops again within a month."
|
|
|
|
**The Outcome Lead**
|
|
Start with the result, then explain how to get there.
|
|
> "Our deploy frequency went from weekly to 12x per day. Here's the infrastructure change that made it possible."
|
|
|
|
**The Story Open**
|
|
Begin with a brief, relevant anecdote (3 sentences max).
|
|
> "Last March, our team pushed a migration that broke checkout for 6 hours. The post-mortem revealed something we didn't expect."
|
|
|
|
**The Question**
|
|
Ask a question the reader is already asking themselves.
|
|
> "Why does every database migration guide assume you have zero traffic?"
|
|
|
|
---
|
|
|
|
## Conclusion Patterns
|
|
|
|
Every conclusion should do two things: (1) reinforce the core takeaway, and (2) give the reader a next step.
|
|
|
|
**The Recap + CTA**
|
|
Summarize the 2-3 key points, then give one clear action.
|
|
> "To recap: validate early, test with real data, and deploy incrementally. Ready to try it? Start with [specific first step]."
|
|
|
|
**The Implication Close**
|
|
Zoom out. Connect the article's advice to a bigger trend or outcome.
|
|
> "This isn't just about faster deploys — it's about building a team that ships with confidence."
|
|
|
|
**The Next Step Bridge**
|
|
Point to a logical follow-up resource or action.
|
|
> "Now that your monitoring is in place, the next step is setting up alerting thresholds. We cover that in [linked article]."
|
|
|
|
**The Challenge Close**
|
|
Issue a direct, friendly challenge to the reader.
|
|
> "Pick one of these patterns and apply it to your next pull request. See what changes."
|
|
|
|
**The Open Loop**
|
|
Tease upcoming content or unresolved questions to drive return visits.
|
|
> "We've covered the read path. In part 2, we'll tackle the write path — where the real complexity lives."
|