Picking the right structure matters less than being able to change it later. Where reorganizing gets expensive, and how to keep that cost near zero.
· Note-Taking Methods · 7 min read
There is a specific moment, usually about two months into any note system, when you realize the structure is wrong. The project you filed under Work turned into three projects. The heading you called "Research" is holding four unrelated threads. The distinction between Reference and Archive that seemed so clean in January has stopped meaning anything, and you can no longer predict which one you would have used.
The standard advice at this point is to design better up front — read about a method, pick the right taxonomy, commit. That advice quietly assumes you can know in January what your notes will look like in June, which you can't. The useful question is not which structure is correct. It's what does it cost me to change my mind. A mediocre structure you can fix in thirty seconds beats an excellent one that takes an afternoon to migrate, because you will be wrong either way, and only one of those two situations lets you do anything about it.
Take a concrete case. You've been keeping meeting notes for a client, and halfway through the engagement you realize the recurring pricing thread deserves to be its own thing rather than a paragraph buried in six different meetings.
In a folder-and-document system, doing that properly means opening six files, finding the relevant paragraphs, cutting them, creating a new file, pasting them in order, adding enough context that each fragment still makes sense, then leaving a pointer in each original so future-you doesn't wonder where the pricing discussion went. Twenty minutes, minimum — and it requires an uninterrupted twenty minutes, which is why it doesn't happen. The reorganization gets deferred to a mythical cleanup session, the notes get slightly less useful every week, and eventually the whole system gets abandoned for a new app that will develop the same problem in a different shape. That's the loop described in Stop Switching Note Apps, and it usually begins right here, with a restructuring that was too expensive to do while it was still small.
Compare the same fix in a system where structure is a tree of lines: select the six subtrees, move them under one parent, done. Ninety seconds. The difference isn't tooling enthusiasm — it's that in the second case the operation is small enough to do at the moment you notice you need it, which is the only time anyone ever actually does it.
Reorganizing is expensive in proportion to how much meaning you've encoded in things that are hard to move. Three culprits account for most of it.
Structure encoded in location. When a note's meaning depends on which folder it sits in, moving it changes what it means, and you have to re-derive that meaning by hand. A file called notes.md inside Clients/Acme/2026/Q2/ is unreadable the moment it leaves that path. The fix is boring and effective: make each note self-describing, so its location is a convenience rather than half its content.
Structure encoded in prose. "As discussed above," "the second point," "returning to the earlier question" — each of these is a small weld between two paragraphs. A note full of them is a monolith. You can't lift any part out without rewriting the seams. Prose that refers to its neighbors by what they say rather than where they sit survives being moved.
Structure encoded at the wrong granularity. If your unit is the document, the smallest thing you can move is a document, and any reorganization below that size becomes manual cut-and-paste. If your unit is the line, with its children attached, then every level of the hierarchy is movable by the same single operation. This is the underrated argument for outlines, separate from any claim about how they help you think: they make restructuring a first-class action instead of an editing chore. What Is an Outliner? covers the mechanics.
You don't need a method for this. You need four operations to be genuinely instant — under two seconds, no dialog, no mouse — because anything slower gets skipped when you're mid-thought.
Move a subtree. Not a line: a line and everything underneath it. If moving a heading leaves its content behind, you will quietly stop moving headings.
Change a level. Indent and outdent, one keystroke each, applied to the whole subtree. Most reorganizations are really just re-leveling — this thing I thought was a top-level topic turns out to be a detail of that one.
Collapse. You cannot rearrange what you can't see the shape of. Folding a three-hundred-line note down to its eight top-level lines turns "where does this belong?" from a scrolling problem into a glance.
Split without breaking references. When a section outgrows its note, it should be extractable into a note of its own with the links to it still pointing somewhere. This is the one most systems get wrong, and it's why people leave things in the wrong place: the extraction is easy, the cleanup afterwards isn't.
In Indenta those are Alt/Option+↑↓ to move a subtree, Tab and Shift+Tab to change its level, Ctrl/Cmd+↑↓ to fold and unfold it, and [[wiki-links]] that get rewritten across every note when you rename the note they point at. The specific bindings matter less than the fact that all four are close to free, which is what lets restructuring happen continuously instead of in dreaded quarterly sweeps. The User Guide has the full set.
A few habits make future rearrangement cheap, and none of them cost anything today.
Prefer shallow and wide to deep and narrow. Three levels of nesting can be reshuffled in your head. Seven cannot. Depth is where structural mistakes hide, because nobody scrolls far enough to notice them.
Let structure be discovered, not declared. Don't create the folder or the heading until you have three things to put in it. A category invented in advance is a guess; a category that emerged because you kept writing the same kind of line is an observation. Folders, tags and links each answer a different question here, and the division of labor between them is worth getting right — links are the only one of the three that survives reorganizing untouched.
Keep the first draft of any grouping in one note. Splitting is easy; merging scattered notes back together is not. Start big and split late — the same asymmetry that governs how big a note should be governs its structure.
Never build a hierarchy you can only navigate by remembering it. If finding something depends on recalling the path you filed it under, then every reorganization also invalidates your memory of where things are. Search and links are reorganization-proof; paths are not.
Cheap restructuring is not an argument for restructuring constantly. There's a failure mode on the other side, and it looks productive: rearranging the outline instead of writing the thing, renaming categories, endlessly refining a system that has no content in it yet. That's the collector's fallacy in a different costume — the satisfaction of tidying standing in for the work.
The rule that keeps it honest is to reorganize in response to friction, never on a schedule. When you can't find something, when a note has visibly become two, when you hesitate about where a new line goes — those are reports from the system that its shape is off, and they're worth acting on immediately, precisely because acting on them is cheap. In the absence of friction, leave it alone. A structure nobody is complaining about is finished, however ugly it looks from the outside.
Open the note or folder you touch most often. Pick one thing in it that's in the wrong place — there will be one — and time yourself putting it right.
Under a minute means your system is fine, and you can stop trying to plan structure in advance; you have the option of fixing it later, so use it. Ten minutes means you've found the actual reason your notes drift out of order, and it isn't discipline. It's that changing your mind was made expensive, so you stopped doing it.
Try it in practice: Indenta is a free, offline-first outliner — nested notes, backlinks, tags, and peer-to-peer sync, with no account required. Start writing in your browser, or read the User Guide first.