It’s obviously beneficial to have written rules when your game is done; after all, “‘you’re not going to come in the box.”’ There are also advantages to writing rules early. However, it’s useful to have the rules written out in the “middle” of playtesting, when some general concepts have been laid down but much is still in progress, as well. Both the tests and the rules will benefit from having a rulebook.

Tests are more useful when run from a rulebook

It’s surprisingly easy to screw up a playtest by teaching the rules incorrectly. Since your rules are probably in flux, at least in the details, it’s entirely possible to teach the wrong version of a rule, or to forget a new addition to the rulebook.

When not caught these errors lead to flawed tests. In the best case you realize you made a mistake and re-teach the game, frustrating the playtesters. (That’s not much of a best case!) Often you’ll end up in the somewhat-worse case, where you detect the problem only after the game is done and the time was simply wasted. The worst case is the flawed test where you never realize you messed up the explanation; you have bad data, but you think it’s trustworthy.

Using a rulebook helps avoid these problems. The playtester reads the rules, and thus is exposed to all of them in their most current form. You don’t need to worry about carrying the burden of knowledge successfully, trying to track the rules and the questions you want to ask and the feedback you’re getting. The existing rules take care of themselves, allowing you to focus on questions and answers.

Rules are better when they’re first playtested with you present

It’s broadly agreed that blind playtests, wherein the players learn the game without the designer’s input, are important–and rightly so! However, a blind playtest with broken rules is only half useful; it shows you where the problems with the rulebook are, but the time spent actually playing is just lost. Playtesting the rules in the middle of the process solves that problem by giving you the opportunity to learn what the problems with the rules are, in an environment where you can fix them and rescue the mechanical aspect of the test.

Blind playtests are often understood as being conducted with the designer not even present. That’s the best way to do it—but it takes a while to get there, and if you do a blind test before that point, with bad rules, the players might realistically never get around to playing the game. Even if they do they’re quite possibly playing wrong, and the data you get is of limited value.

If you’re there you can step in when something’s going wrong, and make sure the game plays out according the rules. That doesn’t mean you should step in often; if you do, you won’t know where the problems with the rulebook are. It only means that when there’s an issue, you can note the necessary change and get valuable information out of the play.

Write early, write often

Having the rules written out is useful at every stage of design. In the beginning it’s helpful to you; at the end it’s primarily for your players. In between it’s great for both. Write your rulebook as soon as possible. You’ll be impressed with the return on the investment.

You don’t need to be a great player to be a great designer, but it does help to play your own games reasonably well—if only so that you can participate better in playtesting. To achieve that, ask what you could have done differently after a loss. The answer to that question will be much more useful than grumping about external factors that may have contributed to your defeat.

Admittedly, it’s sometimes very hard to put a loss on your own shoulders! The temptation to blame the dice, or the cards, or your opponent’s cheesy strategy, can be strong. It’s especially so when the dice were objectively lopsided (don’t trust your memory on this! Write rolls down.).

However, saying “the dice got me” doesn’t tell you anything about your game. That feedback merely teaches that sometimes dice come up with unwelcome numbers at inconvenient times, which is hardly new information.

Taking the emphasis off of the dice, and putting it first and foremost on what you could have done, forces you onto a line of thinking that’s much more likely to end in useful design insights. Was there another strategy you could have pursued, one where the rolls you got would have been sufficient? If so, is that a strategy you want players to rely on when the chips are down? If not, does that point to a design problem, or are you willing to accept that sometimes players will lose despite having made good choices? All of those are much more useful things to think about than “dice sure do hate me sometimes.”

Of course, focusing on yourself instead of on random factors is also a great way to build skill in general—and that will further strengthen your testing. As you improve at a game, or at games writ large, you’ll be able to be say with greater confidence that a different strategy would have worked better, or that you really had no alternatives. There’s no faster or more reliable way to get to skill worthy of reliance than to put your own decisions through the wringer.

Ultimately, asking questions about your own play is a kind of quality assurance for the conclusions you’re reaching about your game. It helps guarantee that you’re identifying the right problems. You’ll find that a valuable contribution; after all, you can’t arrive at correct solutions any other way.