Starting from structure
I don’t try to “hold the whole thing in my head.” That’s how I lose the thread. When I start on something new, I open a place where the work can accumulate—a tree of folders, a few READMEs, a handful of templates—and I treat that place like the product before the product exists.
The first move isn’t inspiration. It’s making room for a system.
What I borrow (and what I don’t)
I’m rarely inventing from zero. I’ll look at how other domains solved adjacent problems—flows, naming, lifecycle of a “thing” moving through states. But I don’t treat any of that as a blueprint. It’s raw material: patterns I can steal at the level of mechanics, not screenshots.
The rule I’ve internalized: if I can’t say what I’m taking, I’m probably just copying the surface. What I want is portable structure—how something starts, what can go wrong, what “done” means—so I can adapt it when my constraints show up (and they always show up).
Layers instead of one big document
Early on, I split the mess into layers that answer different questions:
- What are the things? Names, fields, relationships, statuses—the boring spine. If this layer is fuzzy, everything built on top wobbles.
- What happens in time? Scenarios: stages with a beginning, a path, an end.
- What crosses cuts? End-to-end processes that don’t fit in a single screen or entity.
None of these replaces the others. A model isn’t a story; a story isn’t a policy. When I force the wrong layer into the wrong container, I feel it immediately—the doc either balloons or goes hollow.
Templates as a shared grammar
I keep etalon shapes for recurring doc types: a linear beat, a branching beat, a workflow-style narrative. They’re not creativity killers—they’re agreement machines. They remind me what I often forget when I’m excited: entry conditions, exit conditions, what the user sees, what happens when time runs out.
Especially for branching: I don’t let “the happy path” live alone. If there’s a choice, a timeout, a failed check, or an external system that can say no—that’s not a footnote. It’s part of the same stage. Otherwise I’m not designing behavior; I’m writing wishful fiction.
One vocabulary, enforced gently
I pick terms and I don’t translate them away when they become anchors. The glossary isn’t bureaucracy—it’s how future me (and anyone else, including tools) stops improvising synonyms that secretly mean different things.
Small formatting habits matter too: when lists are real lists—one item per line—they’re easier to scan and harder to hide ambiguity inside a comma-separated sentence.
Honesty labels
Not everything in the doc is “real” yet. I mark what’s solid, what’s exploratory, what’s explicitly future. Without those labels, the repository lies—and I start believing my own marketing.
When it’s “good enough” to build on
There’s a feeling I trust: the moment when I can point to a page and know what kind of truth it holds, and when cross-links don’t feel like patches but like seams.
I know I’m getting close when branching stops feeling like exceptions bolted on, and starts reading as the same rules applied under different inputs. And when I can’t explain a decision without reaching for the core definitions—the names and states we already agreed on.
Why this isn’t procrastination
Some people think documentation is what you do after you know what you’re doing. For me, it’s how I find out.
The idea doesn’t arrive fully formed. It arrives as a pile of half-compatible impulses. Structure doesn’t replace intuition—it compresses it until it can be tested: against edge cases, against time, against the question “what would we actually ship?”
I still delete drafts. I still rename folders. I still discover that two “obvious” concepts needed to be one entity, or three.
But the point isn’t the folder tree. The point is that thinking in systems early saves me from mistaking a mood for a model—and lets the work that comes later stand on something that doesn’t collapse the first time reality says no.