Why People Actually Start Tracking Switch Usage
Most keyboard builders end up buying the same clone switch three times because they forget which one felt best. I've done this myself. It's embarrassing but completely normal. A logbook is just a spreadsheet or notebook where you record switch parameters after testing them on your skin. Not a benchmark score. Not a sound file. Actual tactile impressions paired with measurable data. The reason this matters is that switch feel is one of the most subjective categories in mechanical keyboards. Two people testing the exact same Gateron Milky Swiss 2 will disagree on whether it's smooth enough. But if you write down that you found the spiral rough around the 30g mark and note the force curve numbers, next time you pick switches you're working from evidence instead of nostalgia.
How to Build a Logbook For Mechanical Keyboard Minimalist
Start with something absurdly simple. Google Sheets works fine. The columns you actually need are switch name, factory weight, peak force, bottom out force, spring length, housing material, stem material, homing gap if applicable, smoothness rating on a 1-to-10 scale, scratchiness notes, sound profile one-liner, and your overall take. That's it. Twelve columns max. Anything more and you'll quit using it within two weeks. Here's what I do. When a new switch batch arrives I install it in a bare board or a thocky tester. I type for exactly fifteen minutes using a mix of rapid bursts and slow deliberate strokes. Fast typing reveals different characteristics than slow typing, and both matter. Then I fill in the sheet before the impression fades. Freshly unboxed switches also change over the first week of use, so I usually add a second row after seven days to capture how they settled in. The difference between day one and day seven notes is where most people learn something useful. For the actual testing tools you need is minimal. A digital scale like the Omata or a cheap Amazon kitchen scale works. Something that reads in 0.01g increments. A switch opener. A ruler for spring height. A phone voice memo app for sound reference. You don't need a switch tester with built-in sensors unless you want one. Those cost more than most people realize and the data they produce won't beat your own hands.
I should mention a specific problem I ran into that broke my original system. I was logging Zealios V2s alongside KTT Peons, and since I didn't include a column for actuation point, I later couldn't tell why one felt noticeably faster than the other despite similar factory weights. The Zealio was heavier overall but actuated earlier. I added an actuation point column and never had that confusion again. It took me six months to realize the column was missing. Don't repeat my mistake. If you want a downloadable starting point I keep a bare-bones template at here. It's completely empty except for the columns I listed. No preset ratings. No examples filled in. You can open it in Google Sheets or export to CSV.
Get the Full Details
What Beginners Get Wrong About Logging
The biggest mistake is treating the logbook like a database of specifications instead of a personal reference. Copying switch specs from the manufacturer's page into your sheet is pointless. You already have the page open. The value is in your notes. Your scratchiness observations. Your sound comparison against switches you've already tested. Your force curve observations. Another common error is rating smoothness on an absolute scale instead of a relative one. If you rate every switch you test as a 7 out of 10 because they all feel acceptable, your scale is useless. Force yourself to distribute the ratings. Most switches fall between 3 and 8. A few hit 9 or 10. Some legitimately suck at a 1 or 2. This forces you to actually compare. Sound logging deserves a specific warning. Your environment changes the sound dramatically. Testing in a quiet room at 2pm sounds completely different from testing in a shared apartment with a running HVAC system. If you record audio references, always note the room conditions. Otherwise you'll be confused months later when the same switch sounds drastically different in your memory.
Advanced Usage And Hidden Value
Once you have fifty or sixty entries the logbook becomes genuinely powerful for spotting patterns in your own preferences. I discovered through my own data that I consistently rate vertical linear switches higher than horizontal tactiles even when the horizontal ones are objectively smoother. That's a personal bias the spreadsheet revealed without me admitting it existed. You can also use the data to filter purchases. Instead of buying random switches from AliExpress or Massdrop, sort by your top-rated smoothness scores and your preferred factory weight range. I cut my unnecessary switch spending by roughly 40% after doing this. That's not trivial when you consider how much money goes into switches nobody ends up building with. One thing this approach does not solve is the problem of batch variation. Even within the same brand and model, two production runs can feel noticeably different. I logged a pair of KTT Pinks from two different batches side by side and the second batch required an additional 4g to activate. The factory weight was identical. This is why the seven-day recheck row matters. Batch differences show up in the settled feel more than the initial one.
There's also a limit to how predictive this system is. If you're someone who types with extremely light fingers, a switch rated 7/10 smooth by most people might feel like a 4 to you because you notice imperfections that heavier typists glide over. Your logbook captures your experience, not universal truth. That's a feature, not a bug, but it's worth acknowledging if you plan to share your sheets with other people for purchasing advice. The real test of whether a Logbook For Mechanical Keyboard Minimalist approach is working for you is simple. Three months from now, can you open the sheet and remember exactly why you liked or disliked each switch? If the answer is no, your columns aren't detailed enough. Add more observational fields. The format should serve your memory, not the other way around.
