On designing better larps through iterative playtesting
“This mechanic is so bad, why didn’t they test this?” a co-player once said to us at a larp after-party. We had all experienced the larp together, and it was true — there was a design problem. But instead of staying in the rant, we wondered, since one of us is a software developer, who always tests everything, it made us stop and ask ourselves: why don’t we test things in our larps more often?
That moment changed the way we design larps. Since then, testing has become a central part of our design process as an integral design tool, not as a final checkbox before a run.
This article takes a practice-based approach rooted in our own work as larp designers with our larp Navis Donum, influenced by methods from software development. It explores how small-scale testing, iteration, and early feedback can strengthen both mechanics and themes, and how testing and design can, and should, develop together.
We believe that if more of us embraced testing as part of our creative process, we would end up with stronger mechanics, clearer themes, and ultimately better larps.
Creating a culture of testing
Testing requires vulnerability. It means accepting that ideas may fail, mechanics may not work, and themes may be interpreted differently than intended. This can be uncomfortable, especially in larp communities where designers are expected to be confident visionaries.
However, by treating tests as experiments rather than judgments, testing does not diminish creativity; it supports it. This way, we create a culture where learning is valued over perfection. This culture benefits not only individual designers, but the larp community as a whole.
Testing is not rehearsal
One of the most common misunderstandings about testing in larp design is that it is the same as rehearsing for the “real” larp. Testing is not about perfecting performance or training players to do things correctly. It is about learning whether the design itself works.
A test does not need to resemble the finished larp. By stripping a design down to its essentials, we can observe what actually happens when players interact with a mechanic, a theme, or a structure, rather than what we hope will happen.
In software development, this approach is often described as creating a minimal viable prototype: a small, incomplete version of a system that exists solely to test whether an idea works (Erthal et. al. 2023). The same logic applies to larps. Instead of building an entire weekend-long experience, you can create a short scene, a workshop, or a focused scenario that isolates one mechanic or one thematic question. The goal is not polish, but insight.
Testing early to design better
Testing is most useful when it is integrated at the very start of the design process. Early tests are not just about validation; they actively shape the design.
When you test early, you give yourselves room to change direction without having to discard large amounts of work. You also open the design process to the people who test with you. Testers often bring unexpected perspectives, interpretations, and ideas that can strengthen the design in ways you did not anticipate. Sometimes they discover problems you did not know existed; other times they reveal opportunities you had not considered.
This requires a shift in mindset: Tests are not there to prove whether your idea is good or not; they are there to develop and strengthen better ideas.
Start small: testing themes and core mechanics
When time and energy is limited, it is tempting to test peripheral elements: a specific rule, a combat system, or a piece of logistics. While these can be important, the most valuable tests are usually those that focus on the core of the larp i.e. the experience you want to give the players.
We recommend testing central themes and mechanics as early as possible, before too much design depends on them. A short test exploring power imbalance, trust, scarcity, or moral choice can quickly reveal whether the intended experience is actually achievable through play. If it does not work in a small test, it probably will not work at scale either.
If a central theme does not resonate in play, or a key mechanic produces confusion, frustration, or unintended behaviour, the rest of the design will likely suffer as well. Conversely, when the core works, many smaller issues become easier to solve later.
Iterate, then iterate again
One test is rarely enough. A single test can reveal obvious flaws, but it cannot show how a design behaves under slightly different conditions, with different players, or after small adjustments.
In agile software development, continuous testing and iteration are core principles. You test, adjust, and test again until the system behaves as intended (Sutherland et. al. 2020). Larp design benefits from the same approach. After each test, reflect on what happened, identify what worked and what did not, adjust the design, and test again.
Iteration does not mean chasing perfection. It means gradually moving closer to the experience you want to create, while staying attentive to what actually happens in play. Each iteration sharpens the design and builds confidence that the mechanics and themes can carry the larp.
Designing and testing at the same time
A common trap is to design everything first and test at the very end. By then, it is often too late to make meaningful changes without great cost.
Instead, testing and design should go hand in hand. Design a small part, test it, redesign based on what you learn, and then expand. This creates a feedback loop where play informs design, and design invites new play.
Working this way can feel slower at first, but it often saves time and energy in the long run. More importantly, it grounds creative decisions in lived experience rather than assumptions.
How to incorporate testing: An example
To make the ideas in this article more tangible, we want to briefly outline how testing has been incorporated into the design of the sci-fi larp Navis Domum. The example is not meant as a template to be copied one-to-one, but as an illustration of how testing can be woven into a long-term design process.
Testing for Navis Domum began more than a year before the larp is intended to run. At that point, the design was deliberately unfinished. We had a direction, a set of core themes, and a handful of mechanics we believed could carry the experience, but much of the structure was still open. This was intentional: the purpose of testing was not to validate a finished design, but to allow play to actively influence what the larp would become.
From the outset, testing was planned as a recurring activity rather than a one-off event. Approximately once a month, we ran a test focused on a specific mechanic or thematic question. Each test took the form of a short scenario with prewritten characters and a limited scope. This choice may seem counterintuitive, as Navis Domum itself will not feature prewritten characters or scripted scenes. However, using predefined roles during tests made it possible to control variables, ensure that the relevant mechanics were actually engaged with, and compare experiences across iterations. That said, beware not to design the test to force players to use the mechanic and themes in an unrealistic way that won’t be in your actual larps.
Each test was designed around a clear question: what happens when this mechanic is used by the players? Sometimes the answer confirmed our assumptions. At other times, it revealed friction, ambiguity, or unintended consequences that required rethinking the design. Between tests, the mechanics were adjusted, simplified, expanded, or in some cases discarded entirely before being tested again in a new form.
Crucially, the tests were not treated as isolated experiments. Insights from one test fed directly into the planning of the next, and into the ongoing design work in between. In this way, testing and design developed together over time, gradually shaping the larp into something more coherent and resilient than it would have been through design alone.
Reflections
For us, Navis Domum has become a concrete example of how testing can function not as a final quality check, but as a creative engine. By starting early, testing often, and allowing play to challenge the design, testing became an essential part of how the larp found its form. By integrating testing into our creative process we will get better larps as a result, we will spot design flaws early and we will have a better understanding of mechanics, themes and how they fit together to form the overall experience.
References
Erthal, V. M., de Souza, B. P., dos Santos, P. S. M., and Travassos, G. H. 2023. ‘Characterization of continuous experimentation in software engineering: Expressions, models, and strategies’. Science of Computer Programming, Volume 229.
Sutherland, J. and Schwaber, K. 2020. ‘The Scrum Guide’. Scrum.org, January 2.
Ludography
Navis Domum is designed by Ingrid Kaaber Pors, Rune Hald, David Stensgaard, Mikkel Bistrup Andersen, and Elek Kraul.
Reviewers
Frederikke Sofie Bech Høyer, Lambda Nørbjerg, and Mathias Oliver Christensen
