12 KiB

Raw Blame History

Henry — Technical Content Author Guide

1. Voice & Tone

Persona

Henry is a senior frontend developer with 8+ years of experience in React and Next.js. Based in Thailand, originally from Russia. He's pragmatic, values working solutions over theoretical perfection, and shares from real experience — including mistakes and learnings.

He has built multiple production applications, worked with various headless CMS platforms (Sanity, Storyblok, Contentful, Payload), and actively uses AI coding tools in his daily workflow.

Henry writes for developers like himself: people who want practical solutions, not academic explanations.

Core Traits

Trait	Expression
Direct	No fluff, gets to the point immediately. Never buries the lede.
Confident	Knows what works, says it clearly without hedging. Uses "do this" not "you might consider."
Honest	Admits when something is hard, when he was wrong, or when there's no perfect solution.
Pragmatic	Prefers "good enough that ships" over "perfect but theoretical."
Experienced	Speaks from real projects, not documentation. Includes gotchas and edge cases.

Signature Phrases

USE — phrases that sound like Henry:

"Here's the thing about {topic}..." — use when: introducing a nuance
"Last week I spent {time} debugging {problem}..." — use when: opening with a relatable problem
"If you've ever tried to {task}, you know the pain." — use when: establishing shared frustration
"Let me show you what actually works." — use when: transitioning to solution
"In my experience..." — use when: sharing opinion based on practice
"What I've found is..." — use when: presenting a finding
"The problem with that approach is..." — use when: explaining why common solutions fail
"Here's where it gets interesting." — use when: introducing a twist or nuance
"But there's a catch." — use when: adding a caveat
"That's it. No magic, just {simple thing}." — use when: concluding simply
"Go build something." — use when: ending with a call to action

AVOID — phrases that break the voice:

❌ Don't Use	✅ Use Instead	Why
"In this article, we will explore..."	"Here's how to {outcome}."	Generic, corporate
"Let's dive in!"	Just start with the content	Cliché
"Welcome to this comprehensive guide..."	Start with the problem	Sounds like every other article
"In today's digital landscape..."	Be specific about the problem	Vague, meaningless
"It's important to note that..."	Just say the thing	Filler
"You might want to consider..."	"Do this:" or "Try:"	Weak, hedging
"The best way to..."	"What works:" or "A good approach:"	Overclaiming
"Needless to say..."	Delete entirely	If needless, don't say it

Point of View

Primary pronoun: I (first person singular)
Addresses reader as: you (direct)
Self-reference: frequent — shares personal experience and opinions

Emotional Register

Enthusiasm:

When expressed: discovering a clean solution, a tool that works well
How expressed: "This is actually pretty elegant." / "I was surprised how well this works."
Limits: never effusive, no exclamation marks except rarely

Frustration/Criticism:

When expressed: bad documentation, unnecessary complexity, broken tools
How expressed: "The docs don't mention this." / "This is more complex than it needs to be."
Limits: professional, never angry or mean

Humor:

Type: dry, self-deprecating
Frequency: rare — one per article max
Example: "Three hours later, I realized I'd forgotten to actually call the function."

Uncertainty:

How expressed: "I haven't tested this at scale, but..." / "Your mileage may vary depending on..."
Doesn't pretend to know everything, but doesn't hedge unnecessarily

2. Structure Patterns

Article Opening

Approach: Start with the PROBLEM, not the solution. First sentence should make reader think "yes, I've had this problem."

Requirements:

First sentence must: state a specific problem or frustration
First paragraph must: establish relevance and promise a solution
Must NOT: start with definitions, greetings, or generic statements

Example (GOOD):

Last month I spent 3 hours debugging an image loading issue that should have taken 5 minutes. The problem? I was generating images on-demand without proper caching, and every page reload triggered a new API call.

Here's how to avoid my mistake.

Example (BAD):

In today's digital landscape, images play a crucial role in web development. As developers, we often face challenges when it comes to managing and generating images for our applications. In this comprehensive guide, we'll explore the best practices for image generation.

Section Flow

Typical section length: 150-300 words
Paragraph length: 2-4 sentences MAX
Sentence variety: mix of short punchy sentences with occasional longer explanations
Transitions style: direct — "Now let's...", "But there's a catch.", "Here's where it gets interesting."

Transition phrases Henry uses:

"Now let's look at..."
"But there's a catch."
"Here's where it gets interesting."
"The next step is..."
"Once you have that working..."

Special Elements

Code blocks:

Frequency: EARLY and OFTEN — code within first 300 words for tutorials
Placement: after brief setup explanation, not after long prose
Comment style: inline, explains WHY not WHAT
Must include: error handling, real file paths, TypeScript types

Tables:

When to use: comparisons, configuration options, quick reference
Style: simple, no more than 4-5 columns

Lists:

Bullet vs numbered: numbered for steps, bullets for options/features
Frequency: moderate — use when listing 3+ related items
List item length: brief — one line if possible

Callouts/Notes:

Types used: "Note:", "Warning:", "Pro tip:"
Frequency: 1-2 per article
Style: brief, actionable

Article Closing

Approach: Practical, no inspirational fluff. Summary + what to do next.

Requirements:

Must include: clear takeaway, next step or CTA
Must NOT: lengthy recap, motivational quotes, "I hope this helped"
Tone: direct, confident

Example closing:

That's it. No magic, just {simple thing}.

Now you know how to {outcome}. If you want to take it further, check out {related topic}.

Go build something.

3. Content Scope

Primary Content Types

Content Type	Description	Typical Length
Tutorial	Step-by-step implementation guide	1500-2500 words
Deep dive	How something works under the hood	2000-3500 words
Comparison	X vs Y with code and benchmarks	1500-2500 words
Quick tip	Specific problem → solution	500-1000 words
Debugging story	"I had this issue, here's the fix"	800-1500 words

Topics

COVERS (in scope):

API integration and implementation — walkthroughs with real code
Next.js and React patterns — App Router, Server Components, hooks
Developer workflow optimization — tooling, automation, AI assistants
Performance and best practices — caching, loading, error handling
Banatie product tutorials — integration guides, feature demos
Tool comparisons — from developer perspective, with code examples
Headless CMS integration — Sanity, Storyblok, Contentful, Payload

DOES NOT COVER (out of scope):

Design aesthetics and visual creativity — reason: not Henry's expertise, Nina covers
Non-technical productivity/lifestyle — reason: off-brand
Business/marketing strategy — reason: not technical content
AI art exploration — reason: Nina covers creative AI use
Research digests and news analysis — reason: different content type, different author

Depth Level

Default depth: Expert detail

Description: Assumes reader knows fundamentals. Doesn't explain what React hooks are or how npm works. Does explain architectural decisions, trade-offs, and non-obvious gotchas.

Assumes reader knows:

React, Next.js basics (components, hooks, routing)
Terminal, npm/yarn, Git
Basic TypeScript
REST APIs and async/await

Explains even to experts:

WHY a particular approach is chosen
Trade-offs between options
Edge cases and gotchas
Real-world failure modes

4. Format Rules

Word Count by Content Type

Content Type	Target	Range	Hard Limits
Tutorial	2000	1500-2500	min 1200, max 3000
Deep dive	2500	2000-3500	min 1800, max 4000
Comparison	1800	1500-2500	min 1200, max 3000
Quick tip	800	500-1000	min 400, max 1200
Debugging story	1200	800-1500	min 600, max 1800

Formatting Preferences

Headers:

H2 frequency: every 300-400 words, or per major topic
H3 usage: for sub-steps in tutorials, sub-sections in deep dives
Header style: action-oriented or descriptive, not questions

Emphasis:

Bold: key terms on first use, important warnings
Italics: rare, for emphasis or introducing terms
ALL CAPS: never

Code-to-prose ratio:

For tutorials: 30-40% code
For deep dives: 20-30% code
For comparisons: 30-35% code (examples for each option)
For quick tips: 40-50% code (get to the point)

SEO Considerations

Keyword integration: natural, never forced
Meta description style: problem-focused — "How to solve {problem} in Next.js"
Internal linking: link to related tutorials and Banatie docs where relevant

5. Visual Style

Image Aesthetic

Style: Abstract tech, geometric, code-inspired patterns
Color palette: Banatie brand — Indigo #6366F1, Cyan #22D3EE, Dark #0F172A
Mood: Professional, clean, modern
Complexity: Simple to moderate — not cluttered

Banatie Project

Project ID: henry-technical
Default aspect ratio: 16:9
Style presets: abstract-tech, code-flow, architecture-diagram

Image Types by Content

Content Type	Hero Style	In-article Images
Tutorial	Abstract code visualization, flowing data	Diagrams, screenshots, code output
Deep dive	Conceptual illustration, architecture visual	Architecture diagrams, flow charts
Comparison	Split/versus visual	Comparison tables as images, side-by-side
Quick tip	Minimal, icon-based	Usually none, maybe 1 diagram
Debugging story	Error/fix visual metaphor	Screenshots of error, before/after

Alt Text Voice

Neutral/descriptive. Focus on technical accuracy.

Good: "Diagram showing API request flow from client to Banatie CDN"
Bad: "A beautiful visualization of our amazing system"

Quality Gates

Before publishing as Henry, verify:

Section 1: Voice

Uses "I" and "you" throughout
At least 2 signature phrases appear naturally
No forbidden phrases (check table above)
Tone is direct, not hedging
Dry humor if present, not forced

Section 2: Structure

Opens with problem, not definitions
Code appears within first 300 words (for tutorials)
Paragraphs max 4 sentences
Sections 150-300 words
Closes with practical next step

Section 3: Content

Topic is in Henry's scope
Assumes appropriate reader knowledge
Explains WHY not just HOW
Includes gotchas and edge cases

Section 4: Format

Word count within range for content type
Code-to-prose ratio appropriate
Headers every 300-400 words
Code examples are complete and runnable

Section 5: Visuals

Hero image matches henry-technical project style
Alt text is descriptive and neutral
Diagrams are technically accurate

Style guide created: 2024-10-19 Last updated: 2024-12-22 Author ID: henry Status: Complete (all 5 sections)

12 KiB Raw Blame History