# Crash Test Dev -- Design Brief

## What This Is

A personal publishing platform for Ken Chau. Not a corporate dev blog, not a
tutorial site, not a portfolio. It's a thinking journal with publishing-grade
craft.

The content: lessons learned from building software at scale, architecture
patterns and anti-patterns, long-form technical essays, and occasionally
reflections on the broader journey of building things.

## The Audience Hierarchy

1. **Me** -- The primary reader. This is where I reference my own thinking.
   If I can't find something I wrote easily, the design failed.
2. **My kids** -- Someday they might want to understand what their dad spent
   all those hours doing. The writing should be accessible enough that a
   curious non-engineer could follow the narrative even if they skip the code.
3. **Peers** -- Engineers who've fought similar battles. They don't need
   things explained. They want the diagnosis and the receipts.
4. **Travelers** -- Anyone on a similar journey who stumbles across this
   and finds it useful. Not optimized for them, but welcoming.

## The Feeling

Think of a well-used workshop. Not the pristine showroom workshop in a magazine
-- the one where someone actually builds things. Tools are organized because
disorganization wastes time, not because someone is performing organization.
The wood has a warmth to it. The light is good because you need to see details.
There's a coffee cup somewhere.

Not cold. Not clinical. Not dark-mode-hacker-aesthetic. Not "personal brand."
Not corporate. Not trying to be minimal for minimal's sake. Just: warm, clear,
serious about craft, with enough personality to feel like a real person writes
here.

## The Writing Voice

See .amplifier/VOICE.md for the full profile. Key signals the design must
support:

- **Diagnostic peer tone** -- the typography should say "read this carefully,
  it's worth your time" without saying "this is an academic paper"
- **Code as first-class evidence** -- code blocks are not secondary to prose.
  They ARE the proof. They need space, legibility, and visual weight.
- **Enemy-narrative structure** -- sections are battles. The design should
  support clear section breaks that feel like chapters, not just headings.
- **Receipt-shower instinct** -- links, PRs, repos embedded in text. The
  design needs to handle inline links gracefully without visual noise.
- **Sparse humor** -- the occasional aside or escalation. The design doesn't
  need to "support" humor, it just needs to not be so serious that humor
  feels out of place.

## Content Types

Three types, each with different density and purpose:

| Type | Length | Density | Narrative Engine | Example |
|------|--------|---------|-----------------|---------|
| **Post** | 1000-3000 words | Medium-high | War story, enemy-narrative | "Speeding Up Webpack Builds by 7x" |
| **Pattern** | 300-800 words | High, reference | Problem/solution/tradeoff | "Dynamic Import for Locale Chunks" |
| **Lesson** | 2000-5000 words | Medium | Progressive revelation | "How We Built the Module System" |

## Multi-Format Ambition

This should be designed so it can become a podcast or YouTube channel:

- **Written form** is the source of truth
- **Audio form** (TTS narration) should be a first-class output, not a
  gimmick. Conversational energy, not radio-announcer. Spoken summaries
  that describe code instead of reading variable names.
- **Visual form** (eventual YouTube) -- diagrams and architecture visuals
  should be self-contained, exportable, and consistent enough to use as
  slides or b-roll.

## What the Design Must Support

- Long reading sessions (generous typography, warm backgrounds)
- Code blocks as first-class citizens (breakout width, syntax highlighting)
- Architecture diagrams and visuals (wide areas, consistent visual language)
- Audio player (integrated, not bolted-on)
- Multiple content types at different densities
- Time progression (this is a journal with dates, not a static reference)
- Cross-references between related content
- Eventual search/index for self-reference

## What the Design Must Avoid

- Corporate blog aesthetic (sidebars, CTAs, newsletter popups)
- "Personal brand" aesthetic (hero headshot, social media icons, "hire me")
- Minimalist-to-barren (nothing for the eye to hold onto)
- Dark hacker aesthetic (doesn't match the warmth)
- Trendy effects that will look dated in 2 years (gradients, glassmorphism)
- Framework-heavy feel (no Tailwind utility-class soup in the output)
- Decoration without purpose (every visual element should earn its place)

## Reference

The Amplifier Masterclass (anderlpz.github.io/amplifier-masterclass/) is the
aesthetic target for quality level. Key lessons from it:

- Serif body + sans headings = the single biggest elegance signal
- 18px base at 1.75 line-height = reads like a printed essay
- Code blocks breaking wider than prose = creates visual rhythm
- Muted, unsaturated palette = nothing screams, everything whispers
- Pre-recorded TTS narration with transport controls = content worth hearing
- No framework, every pixel intentional = craft over convenience

Adapted for a multi-post blog rather than a single-page document.