Monthly Origami Logbook

Why I Track Every Fold

I started keeping a log of my origami work about three years ago, mostly because I kept forgetting the sequence for anything more complicated than a crane. My memory works fine for standard models, but once I get into double‑unit base variations or wet‑folding work, I lose track of whether I did the reverse fold before or after the squash fold. That used to cost me about twenty minutes per attempt, sometimes more if I was working on something delicate. The Monthly Origami Logbook is really just a structured way to record what you did, when you did it, and what went wrong. It isn't a commercial product you download from a store — at least, not one I've found that's worth buying. Most people in the hobby end up building their own system or adapting a notebook template. The idea is straightforward enough that you can set it up in about ten minutes.

Getting Started With Your Monthly Origami Logbook

Here's what I actually use. A single A5 notebook with a tight grid, or a simple spreadsheet if you prefer searchable records. I stick with paper because I'm constantly measuring paper weights and fiber directions, and having the model physically next to your notes matters. But some of us work digitally, so either approach is fine. The essential fields are model name, designer, paper type and weight, step count, whether you followed an instructions diagram or a video, any deviations you made, and the final success rating. I also track the date and how much time it took, plus a rough difficulty score from one to five. Keep it simple. The second you add more than eight fields, you stop filling it out. I've seen people build elaborate systems with color‑coded tabs, separate sections for cranes versus tessellations, and even a database for tracking paper inventories. That's fine if you have the patience, but it usually takes about six months before the system itself becomes the thing you're maintaining rather than the thing helping you maintain. Your Monthly Origami Logbook should serve the work, not the other way around.

What I Actually Record

When I pick up a new model, I write down the designer's name first. That matters more than you'd think. Akira Yoshizawa's sequences are structured differently from Robert Lang's, and knowing who designed a model helps you anticipate whether you'll run into parameter‑heavy geometry or more traditional folding approaches. Next I note the paper. Weight in grams per square meter, side count, whether it's single‑sided or two‑sided, and how it behaves when wet. I once spent forty‑five minutes debugging why a particular layer wouldn't nest properly, only to realize I'd picked the wrong paper grain direction. That entry in the log saved me from making the same mistake twice. The step count is useful but often misleading. An eighty‑step diagram doesn't tell you whether those steps include a series of intricate reverse folds or just a long sequence of mountain and valley creases. I mark whether the instructions were clear, whether I had to re‑read any section more than once, and whether I found a published correction on the model's thread. Those details compound over time.

I rate each attempt. Not the model itself, but my execution on that particular day. Paper condition, lighting, fatigue level — all of those matter. A model you crush at 9 PM after coffee is a different beast from the same model at 7 AM when your hands are still stiff. This is where people usually skip entries. Don't. The pattern shows up after about forty logs.

Edge Cases and Workarounds

I ran into a specific problem last spring that almost made me abandon the system entirely. I was working on a modular kusudama — thirty units, each with a double‑layer collapse that I needed to perform in a precise sequence. The instructions showed the collapse, but didn't indicate which layers to squash first. I got through fifteen units perfectly, then on unit sixteen something shifted and the entire assembly started binding. I spent an hour trying to work backward through the fold sequence, checking each layer against the diagram. Nothing matched. Eventually I took the partially completed module apart and realized the issue: I'd compressed the inner layer too early, before the outer collapse had fully seated. The diagram never mentioned that timing. I wrote up the fix in the log, including a small sketch showing the correct layer order, and marked it with a red flag so future entries for that model would pull that correction up immediately. The workaround isn't fancy. It's just writing down what actually happened, not what the instructions said should happen. That distinction matters. Most published sequences assume a level of paper control and hand flexibility that most of us don't have on day one, or even on day one hundred.

Pitfalls I've Seen People Hit

The biggest mistake I see is treating the log as a trophy case. If you only record successful models, the data becomes useless. The failures contain more information than the successes, usually. A collapsed unit, a torn layer, a sequence that simply won't nest — those entries tell you what to avoid next time. Successful folds just confirm what the instructions already said. Another trap is over‑documenting. I've watched people spend more time photographing each step than actually folding. That's not logging. That's content creation, and it's a completely different activity with different goals. If you're logging to improve your technique, keep the entries lean. A paragraph per model, a sketch if needed, maybe a photo of the final result. That's plenty. Sometimes the log breaks down because the model is too large or too complex to fit in your standard format. Tessellations with hundreds of pre‑creasing steps, or large‑scale installations that take multiple sessions, need a different approach. I use a separate tracking sheet for those, with phase dates and session notes rather than attempt dates. The Monthly Origami Logbook template doesn't handle that well, so keep the two systems separate and cross‑reference when needed.

What I'd Change About the System

If I were building this from scratch today, I'd add a field for paper recovery attempts. When a fold goes wrong, do you cut the paper and start over? Do you try to rebend the layer? Do you abandon the model entirely? That decision has a huge impact on material cost and time, and it's something most logs ignore. I track this now, and it's one of the more useful entries for planning future projects. I'd also separate the difficulty score from the execution score. They're correlated but not identical. A beginner might struggle through a moderate model and still produce a decent result, while an experienced folder might rush through a simple one and tear a critical layer. Two scores give you cleaner data for deciding whether to revisit a model or move on. The Monthly Origami Logbook works because it forces you to be honest about what happened. That's uncomfortable at first. Most of us want to remember the good attempts and forget the bad ones. But the log doesn't care about your feelings. It just records what you did, and over time it becomes the most reliable source of information you have about your own process.

I recommend keeping it for at least three months before judging whether the system is worth the effort. The first month is always annoying because you're still building the habit. By month two, you start noticing patterns. By month three, you catch yourself thinking ahead: if I had written this down last time, I would've known to adjust the paper angle on step twelve. That's when the system pays for itself.