Can we use ADDIE to make a better rulebook?

Last week we looked at garbage time in board games, wondering if rulebooks should include explicit rules for conceding the game.

This week we continue to think about rulebooks with a possible method for making them better: the ADDIE instructional design model.

There’s no shortage of advice on how to write board game and tabletop roleplaying game (TTRPG) rulebooks.1 A quick survey usually yields tips like:

• Put a game overview and basic concepts first (how to win)

• Use consistent and clear terminology (e.g. token, phase, action)

• Include examples of play

• Clarify edge cases (but not too many edge cases)

• Use diagrams and pictures (show, don’t tell)

All of these are good advice, and I might write up my own “best practices” list in the future. Many of the resources, however, focus on specific things to include or exclude rather than an overall process.

I’ve conducted quite a bit of technical training in the past both in-person and written. To develop courses or programs I relied on instructional design (ID) principals — systematically planning and developing educational materials to deliver effective training. It made me wonder if there is an instructional design process that might work for rulebooks.

If it worked for large and complicated organizational projects, why wouldn’t it work for a board game or TTRPG?

The history of instructional design (also known as Instructional Systems Design) goes back to at least the 1940s with roots in cognitive psychology, constructivism, military training and B.F. Skinner’s programmed instruction. It’s long and complicated, resulting in countless instructional design models.

One model struck me as being the most clear and easy to understand. It also happens to be the basis or foundation for many of today’s ID models — the ADDIE model.2

The ADDIE model was originally developed in the late 1970s at Florida State University with changes continuing into the 1980s.3 It consists of five distinct phases that are used to develop the instructional materials, each focused on different facets:

• Analysis: Problems, objectives, learners, and constraints

• Design: Content sequencing, unit objectives, skills

• Development: Writing documents, creating diagrams, designing assessments

• Implementation: Roll out to learners, test the training

• Evaluation: Gather feedback, analyze outcomes, determine impact

Interestingly, the ADDIE model itself is rather poorly defined and therefore most instructors adapt it as needed. Michael Molenda says in “In Search of the Elusive ADDIE Model” that there is no fixed definition:

What is emerging in the recent literature is a tendency to accept the ADDIE term as an umbrella term, and then to go on to elaborate more fully fleshed out models and narrative descriptions. However, it should be recognized that authors who do this are essentially creating and disseminating their own models as there does not appear to be an original, authoritative version of the ADDIE model to be revealed and interpreted.

That sounds like permission to use and adapt it however we need for rulebooks!

Support Skeleton Code Machine with a Tumulus subscription!

Let’s apply the ADDIE instructional design model to tabletop game rulebook design:

Define the players, context, learning goals, and benchmarking

The first phase of the ADDIE model is focused on doing research on the players, the context in which they will play (e.g. solo vs. multi-player), and what they need to learn. It is important to consider the player’s age, what prior knowledge or board game fluency they possess, and if you’d expect one player to be teaching others how to play. Also consider if players will all be using the same rules or, as in an asymmetric faction game like Root, each player needs to know their own rules.

You’ll also need to define what they need to learn. Write it out, including things like turn-order, game phases, available actions, setup, various victory conditions, and anything else a player would need to know if they want to play the game.

Looking at the rulebooks of similar games can provide a benchmarking opportunity and help with the next phase.

Determine rulebook structure, layout, sequencing, and examples

With a clear picture of your players in mind and a list of learning objectives, you can begin to design the actual rulebook and supplementary materials. In this phase you’ll also decide on single vs. multiple rulebooks, player aids, reference sheets, playbooks, order of sections, and size/format (e.g. small folded vs. large stapled).

Most board games have a single rulebook, but in the wargaming world a separate playbook is quite common. The COIN-adjacent game A Gest of Robin Hood is a good example.

This is the phase to develop your list of keywords and terminology (e.g. Attack, Move, Deploy, Resolve, Exhaust, Pass, Remove). Choose them wisely and stick with them. It’s also easy to accidentally intermix words like player, he/she, and you when writing instructions. Pick one and make it part of your rulebook design.

Write the rulebook and supporting materials

Your players and learning objectives are defined. You have your structure and layout set and some examples of play. Now it’s time to write the rulebook, quickstart guide, create the player aids, and all the other instructional materials that go with the game.4 Try to use dual-coding concepts when possible.

Understand, however, that this is the first draft. Think of it in the same way you’d think about the first playable prototype of the game itself. Ensure it is complete and that it works — but don’t get too attached.

Playtest the rulebook in guided and unguided sessions

Give your rulebook the same rigorous playtesting that you give your games. There are a few types of playtesting that can be used:

• Guided: The designer is present, guides the game, answers rule questions, and might even walk players through their first few turns.

• Unguided/Blind: The designer may be present but does not offer advice or answer questions. Instead the players are given the rulebook and game and attempt to learn and play the game on their own.

At very early stages, guided playtesting might be helpful to get initial feedback and see where rulebook problems might exist. The only real test, however, is allowing players to struggle through the rules on their own and watching them play your game incorrectly.

Collect feedback and use iterative design

Using the information collected from either direct observation or player reports, you can now conduct an evaluation of your rulebook’s design. You can also ask specific questions, such as having a player explain a rule in their own words. Remember that how you phrase playtesting questions is tricky. Asking “Which part did you find confusing?” will often yield different rules than “Which part would other players find confusing?”

The collected feedback can now be used to create the next iteration of the rulebook. This might include revising the learning objectives from the Analysis phase or creating new materials in the Design phase. Continue to iterate and evaluate until the rulebook is clear, concise, and effective.

In some ways, a strict and formal adherence to the ADDIE model is overkill for a small board game or indie TTRPG project. I’d be lying if I said I followed every step when writing the one-page trifold versions of Exclusion Zone Botanist or Eleventh Beast. So I’m not claiming you need this much process for every game.5

That said, I do think using an instructional design model like ADDIE has some significant benefits:

1. Keeps the focus on players: Rulebooks are instructional tools just as much as a flight instruction manual for a new pilot. It’s a document designed for a specific learner with specific learning objectives. Applying a structured process like ADDIE keeps the focus on the learner. It forces you to answer the question, “Who is this game for?”

2. Leverages iterative design: The ADDIE model is structured around iterative design. The Evaluation phase is useless if not used to revise the instructional documents (i.e. rulebook) using feedback and observations. Designers playtest and iterate their game designs, so doing the same for the rulebooks should come easy.

3. Implements a scalable process: Sure, it’s overkill for a one-page RPG. But becoming comfortable with instructional design principals for small projects allows you to be comfortable with large projects. Learn how to do it now, so it’s a skill you have when you need it later.

These benefits are particularly true for TTRPGs. By their very nature, many TTRPGs are a game and rulebook blended in the same document. Without a board, specialized components, or player aids, it is critical that the rules are clear and effective. Applying the ADDIE model is a good way to make that happen, especially on larger projects.

Some things to think about:

• Instructional design is complicated (but useful): I’m not an expert in ID, and you could spend a long time learning more about the field. The different approaches (behavioral psychology, constructivism, etc.) are really interesting. That said, you don’t need to understand it all to get some use out of the models.

• The ADDIE model works: Like many generalized process models (e.g. DMAIC) the model works because it is inherently broad and open to interpretation. The focus on the player (i.e. learner), objectives, and iterative design can only help make a better rulebook.

• Don’t just playtest your game: Guided playtesting (i.e. designer is present and answering questions) is very common, especially at events like Unpub. Unguided or blind playtesting is just as important, but often harder to execute — but also the only way to know if your rulebook works.

What do you think? Have you ever used instructional design principles when developing a rulebook? Do you think the ADDIE model could help?

— E.P. 💀

P.S. Tumulus 04. Kick open the door. begins shipping in June. If you want to receive Tumulus 03. Keep the wolves at bay. as the first of your four issues, subscribe before June 1. Otherwise you will receive Tumulus 04 as the first of your four issues. 🩻

Skeleton Code Machine is a production of Exeunt Press. All previous posts are in the Archive on the web. Subscribe to TUMULUS to get more design inspiration. If you want to see what else is happening at Exeunt Press, check out the Exeunt Omnes newsletter.