A note system you can still keep up with in week six

Start from one question, not from a folder tree

Every time I rebuilt my notes, I started with the hierarchy. Stacks, notebooks, a tag vocabulary with colors. It felt productive for about two evenings. Then a real week arrived, and the structure quietly stopped matching what I was actually doing.

The version that survived began differently. Before touching a single note, I wrote down one ordinary question I kept failing to answer: “What did we decide about the export limits, and why?” That question told me what the system had to be good at. It had to keep a decision next to its reason, and it had to let me find that pair in under a minute when a colleague asked in chat.

A tidy hierarchy is not a result. Answering your own question quickly is the result. If you cannot name the question yet, you are not ready to build anything, and that is fine. Write everything into one place for a week and watch what you go back looking for.

One inbox, emptied on a schedule you can actually keep

We use a notebook called Inbox for anything whose destination is not obvious. A screenshot from a support chat, a paragraph from an AI conversation that sounded right, a link to an article I will probably never read. Dropping it there costs nothing, and that is the point. A filing decision interrupts the thought you were trying to save.

The inbox fails in one specific way: it becomes a second archive. Ours hit 140 notes in April before anyone admitted it. The fix was not discipline, it was a smaller promise. Every Friday, ten minutes, newest first, and we stop when the timer stops. Some weeks we move four notes. That is still a working inbox.

When a note moves out, it gets one sentence at the top: where it came from and why I kept it. Without that line, a saved article is just a URL that looks vaguely familiar six months later.

Separate what you are doing from what you might look up

The single most useful split we made was between active work and reference. Active work lives in project notebooks: “Export limits, Q3”, “Onboarding test, round two”. Reference lives in topic notebooks: “Pricing research”, “Interview questions”. The project list stays short because projects end. The topic list grows slowly because topics never do.

Stacks group notebooks when the sidebar gets long, and that is the only reason to use them. A stack called “Active” with five notebooks and a stack called “Reference” with twelve is more structure than most people need. We tried a deeper tree once. Nobody could remember whether “Competitors” sat under Research or under Marketing, so it ended up in both.

A tag answers the question the notebook cannot. The notebook tells you which project a note belongs to; a tag like “needs-source” or “decision” cuts across all of them. Keep the tag list short enough to recite from memory. Ours has nine.

What a review looks like when the week went badly

The review that survives is the one you can do on a Thursday evening after a bad day. Ours has three steps: empty a bit of the inbox, open one active notebook and read its first note, archive anything that finished. Fifteen minutes, no reorganizing.

Reading the first note of an active notebook is the part people skip, and it is the most useful part. That note should say what the project is for and what the next open question is. If it does not, fix the note, not the hierarchy. A folder is never confusing on its own. It is confusing because the note inside has no context.

I will admit we broke this rule for most of last winter. Every review turned into a rename session. Backlinks saved us more than once, because a renamed notebook still showed which notes pointed at it, but the real lesson was simpler. If you are moving notes during a review, you are procrastinating.

A worked example: Daria prepares a workshop

Daria runs customer interviews at a small software company. In March she agrees to teach a two-hour workshop on interviewing for a team of six. She creates one notebook, “Interview workshop”, and the first note has three lines. Audience: six product managers. Purpose: have them running their own interviews within a month. The question she must answer before writing anything: “What do they get wrong today?”

Over two weeks she adds eleven notes. Three are reading notes, each with the source URL, one short quote she wants to discuss, and her own line about why it matters. One holds a PDF of an old training deck; full-text search finds the phrase “leading question” inside it, so nothing gets retyped. Two are checklists for the session itself. The rest are observations from watching colleagues run interviews, with the date and the moment that stood out.

The workshop happens. A week later she writes a closing note: what worked, which exercise ran long, two questions from the room she could not answer. Then she moves one reading note to the topic notebook “Interview methods”, because she will want it again, and the whole project notebook goes into the “Done 2026” stack. Backlinks keep the moved note connected to the workshop. Total time spent on structure across the month: maybe twenty minutes.

A checklist with a stopping point

During a review, ask four things and then stop. Can I explain what each active notebook is for? Do new notes carry enough context that I will recognize them in a month? Is the one source I actually need reachable? Is there finished work still sitting in the active list?

Answer those for the material you need this week, not for every note you have ever written. You do not owe your archive a full audit. The 2023 notes can stay messy. Nobody is going to read them, including you, and that is an honest outcome, not a failure.

The system that lasts is the one with the fewest decisions per note. One inbox, one split between active and reference, one short review. Everything else is decoration, and decoration is what you drop in week six.

Where to go next

Find it again in a year

Learning and research: from sixty saved papers to one argument