Writing for Skim Readers

I ran a playtest of Wizard Academy last week, in which the group played a good portion of the rules incorrectly. I think that the problem was that we started quite late in the evening, when people were a little tired and that a rules confusion during setup strung out the setup sequence to take a very long time. By the time the game had started nobody had much patience and the group had played the basic game before, so skimmed the advanced rules and just got on with it.

skimI think it’s important never to blame conditions during playtesting. I could very well say things like “It’d have been best to start earlier in the day when everyone was at their peak.” and it’d be true, but what am I going to do? Slap a warning on the box “Do not play this game if you’re not feeling 100%”? Once the game is out there it’s (hopefully) going to be played by all manner of people engaging under all sorts of different conditions – it should support as many of them as possible.

There’s another principle in game design, which is to identify your target audience and build only for them, but I’m not convinced by this. I think that it’s best to identify said audience and never compromise on what they need, the difference is subtle but important. If you can make an improvement for a non-core audience that doesn’t in any way make things worse for your core audience then you should do it. I can’t think of a single good reason not to.

improveSo let’s talk about improving rules for skim readers who read as they play their first game, without hurting the experience for gamers who like to study rules beforehand. In academia there was a considerable focus on writing for skim reading, during my first couple of years I faced substantial criticism for not including key points in my papers and direct quotes demonstrating that the points were there did not constitute a defence. It took me a while to get the hang of the notion that most academics skim most of the papers that they read (unless directly relevant to their research) and putting key information in a skim-unfriendly way was almost as bad as not including it in the paper at all.

The recommended solution to this was repetition. Repetition could improve the extent to which skimmers noticed something. The weapon of choice, for making sure skim readers noticed a thing was repetition. I always hated it, I couldn’t help but think that writing redundantly was part of the problem and that it inclined people to skip most of what you’d written. In a rulebook it would be even worse, as it would be actively hurting careful readers for the benefit of skim readers. Screw repetition.

screwsA saner option is to utilise order effects, the notion that individuals engage with the first and last items in a block more clearly. In a paragraph the middle is more likely to be ignored than the starting and ending lines, so you can improve rules for skim readers by trying to get the most vital rules into these locations. The middle can be used to elaborate on points that might be unclear or (if you must) raise relevant exceptions. Ultimately the rules can be improved by starting and ending paragraphs with your key points.

It’s also handy to make it obvious when something is missing (see next paragraph).

The main danger to a game is that a player will skip a vital rule and that the game will go wrong without it. It’s bad if they skip something and then have to go looking for it, but worse if they play without it. That could be the difference between wasting a few minutes searching and wasting a few hours playing a crappy game. It’s much better to make it obvious if something has been missed, there are a few options for this. One is simply to reserve attention focusing strategies for rules that will not be obvious if they’re skipped. Another is to liberally use cross-referencing so that players know when they’ve missed a rule. At the moment there’s a bit of flavour on Imps that says something like “Imps cannot be killed by fire, but may drown in water.” It’s not too much more effort to write “Imps cannot be killed by fire, but may drown in water (see p8 for drowning rules) to signpost that there is more to this topic.

drownFinally there are design elements to the rulebook. The reason that pages were skipped during this playtest was that the rulebook gave an unwitting signal that the rules had finished. The text on a page ended halfway down the page and the rest of the page was blank, which normally signifies the end of a document. The real reason was that I wanted a table on the next page not to go over a page break, but the page before was half blank and didn’t signal a lack of blank pages to follow – ultimately I figured I’d use some of the final art here once I had it – but I think it’s important that the playtest rules have something there, even if it’s just a sketch, to signify that it’s not the end. We’ve got some pretty good sketches.

Malakar_01_mediumSo those are the main points for me: Order effects, timing of skippable rules, appropriate referencing and signposting. Do you have any other notions for how to write rulebooks to reduce the chance of rules being played incorrectly? Let me know 🙂

6 thoughts on “Writing for Skim Readers

  1. Great points. I’ve been reading a lot of rulebooks lately. Sometimes we play 3-4 new games a night.

    I’m in the habit of skimming the rules for the main points of the game, then looking at components to provide clues on where I’m missing key points.

    Rules with large paragraphs of rule explanations and gameplay examples that aren’t clearly separated from rules text drive me nuts.

    -AndyP

  2. Pingback: Today in Board Games – Issue #127

  3. I took the bold approach with 404, perhaps I should be doing it here too 🙂

    That’s a fair frustration! At the moment there aren’t any examples of play for WA, but the 404 ones were seperated onto their own pages, which made things clearer.

  4. Pingback: Cardboard Edison Weekly Roundup – Jan. 25-31, 2014 | BTG Co-Op

  5. Pingback: Today in Board Games – Issue #128

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.