Projects, topics, or both? The rule we ended up with

Projects end, and that is their best feature

A project notebook is organized around an outcome: run the workshop, publish the essay, finish the client review. It holds the brief, the sources, the meeting notes, the decisions. When the outcome ships, the notebook goes into a “Done” stack as a complete record of how one thing got made. That ending is what makes projects easy to keep tidy. There is a natural moment to stop.

This structure fits people who remember work by the project that produced it. “That was during the Horizon review” is how I remember most things, so project notebooks suit me. My colleague Lena remembers by subject, and the same notebooks drive her slightly mad.

Projects get awkward when the same reference keeps being needed across several of them. We had the same article about interview bias saved in four project notebooks by the end of last year, with four different sets of margin notes. That is the signal to read the next section.

Topics outlive the projects that created them

A topic notebook collects what stays useful after the outcome is gone. Research methods. Writing techniques. Accessibility references. Lena’s “Interview methods” notebook has outlived nine projects and is the single most consulted notebook in our shared stack. You go there when you remember what an idea was about rather than where you first used it.

The failure mode is a pile without a purpose. A topic notebook with sixty saved links and no sentence of your own is a bookmarks folder with extra steps. Give each topic note a question it answers or an argument it makes. “Why leading questions are hard to notice in your own interviews” is a note. “Interview stuff” is a drawer.

I will say the unpopular thing: most people need fewer topic notebooks than they think. We started with fourteen. Two years later, six of them have more than ten notes, and those six are the ones anyone actually opens.

Links do the job a hierarchy cannot

Here is the resolution to the argument. Project-specific evidence stays in the project notebook. When you notice a reusable method inside it, write a topic note and link it back to the evidence. The project note explains where the insight came from; the topic note explains how to use it next time. Backlinks mean the topic note shows every project that ever drew on it, which is the thing no folder tree can tell you.

Tags give a second path across notebooks, and a small vocabulary is enough. We use “method”, “decision”, “needs-source” and a few more. Nine tags total. The first time we tried this we had forty, and nobody, including the person who made them, could say what “insight” meant as opposed to “finding”.

You do not have to choose one structure for everything. I think the argument we had for a year was mostly about pretending we did, and a link would have ended it in week two.

Test retrieval before you move anything

Before rebuilding a hierarchy, pick three notes you needed in the last month and try to find each one from memory. Then write down the clue you used: a client name, a phrase, a subject, a decision. The clues tell you which structure your memory already runs on. Mine were two project names and one phrase. Lena’s were three subjects.

Fix titles and links first, hierarchy last. A note you could not find usually has a title that describes where it came from instead of what it says. Renaming it is a thirty-second fix. Moving it to a new notebook is an afternoon of moving everything else to match.

A structure should be explainable to a colleague in two sentences. If filing a note needs a paragraph of exceptions, the structure is asking for more than anyone will give it on a Tuesday afternoon.

A worked example: one reading note, two homes

Lena reads an article about interview bias while running a study for a client called Horizon. The article changes one decision: she rewrites question four of the script because it was leading. Where does the reading note go? In a pure project structure it belongs in the Horizon notebook, because it influenced a decision there. In a pure topic structure it belongs in “Interview methods”, because she will want it for the next study.

What she actually does: the Horizon notebook gets a short decision note, “Question 4 rewritten, see article on leading questions”, with a link. The “Interview methods” notebook gets the reading note itself: source, the two paragraphs that mattered, and her own line about how she noticed the problem in her script. The reading note’s backlinks show Horizon, and a year later they also show the Daria workshop notebook, where the same note was used to design an exercise.

Three months after Horizon closes, a colleague asks whether anyone has written anything about leading questions. Search finds the reading note in two seconds. Nobody has to remember which client it came from. That one note took Lena ten minutes to write properly, and it has been opened more often than the entire Horizon notebook.

The simplest rule you can explain to a colleague

Here is ours, written in a pinned reference note: material about one specific outcome belongs to its project; material you have interpreted for reuse belongs to a topic; a note that crosses the boundary gets a link, not a copy. That is the whole rule. We tested it against a dozen real notes before adopting it, and two of them did not fit.

Those two exceptions were useful. One was a client’s style guide, which is reference material but useless outside that client. It stays in the project, tagged “reference”. The other was a half-finished method that was not ready to be a topic note, so it waits in the project until it is. Exceptions are evidence that the rule needs a small adjustment, not a reason to build a deeper tree.

We still disagree about edge cases, Lena and I, roughly once a month. The difference now is that the disagreement takes five minutes and ends with a link. A year ago it took an afternoon and ended with a new folder.

Where to go next

Find it again in a year

Learning and research: from sixty saved papers to one argument