Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
January 18, 2018
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Board Games in Education - Cardboard Prototyping

by Michael Heron on 01/08/18 10:09:00 am

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


You can read more of my writing over at the Meeple Like Us blog, or the Textual Intercourse blog over at Epitaph Online.  You can some information about my research interests over at my personal homepage, or on my profile at Robert Gordon University.

This is a modified version of an article that first appeared on Meeple Like Us.


Let’s talk about cardboard prototyping, and how I have found yet another way to get board games into my work life.  I swear I am a grown up and I do this for entirely justifiable pedagogic reasons.  I SWEAR.

One of the modules I teach at Robert Gordon University is called User Centred Design, or UCD.   It’s a third-year unit aimed primarily at our Digital Media students.  If you’ve never encountered this philosophy of development before it’s about making sure that every stage through which a project passes has a heavy, integral focus on the eventual end users.   Traditionally it’s considered a kind of software development methodology but its actually relevant for anything where the designers of a system are not necessarily its intended primary audience.    The core philosophy of this module is simple – you can design the greatest, most technically perfect thing in the world but it’s worth nothing if people won’t use it.   User Centred Design works to maximise perceived user benefits, and as you might imagine from the central thesis of Meeple Like Us my approach is all bound up in a context of accessibility.

If people can’t use your product or process, it’s an accessibility problem.   That’s generally the accepted definition of accessibility.  My view is more holistic.  If people don’t see the value in your product or process, it’s an accessibility problem.   It’s one where the inaccessibility is in how you present it to your audience. If people don’t want to use your product or process, it’s an accessibility problem.     The inaccessibility is because you haven’t framed your work in a way that convinces people the benefits exceed the costs.

The UCD module frames each part of the product pipeline as incorporating a series of accessibility challenges to be overcome.   These might be physical, cultural, sociological or perceptual.   They might be real problems or they might exist entirely in the head of a user.   In all cases, the solution is the same – if you want people to use a product you need to design it for them.  If you don’t want to deal with an inaccessibility, whatever its source or manifestation, you have to be prepared to accept a restricted potential audience as an inevitable consequence.  It’s never quite this simple of course – sometimes to address one accessibility issue for one group is to introduce an inaccessibility for another.   While the approach in the module is straightforward, that doesn’t mean any of it is easy to do.

User Centred Design is not a proscriptive philosophy – it’s not really about applying frameworks or testing products against fixed guidelines.  There are set techniques often employed within UCD but they’re not the goal of the endeavour – they’re just a part of the toolkit.   Really, UCD is about building the capacity for meaningful empathy and calibrating that empathy with ongoing interaction with a user-base.    There are certain lessons learned from the field that have general applicability, but a core insight that comes with the whole process is that every audience is unique.   UCD is an encompassing philosophy of design that stretches from usability to construction of aesthetic through to the emotional reaction people have to a product and how it is pitched and advertised.

There’s a problem though when it comes to teaching this to students that don’t have a product on which they are actively working.  User centred design is a process that thrives in the energetic intersection of people and systems.   The problem is that it’s really difficult to explore this in a meaningful way within a classroom setting, certainly within the relatively affluent context of a higher education institution within a Westernised democracy.

Have you ever heard of the acronym WEIRD?  It’s sometimes used to illuminate much of the problem with user facing research in technological, medical and sociological fields.   Approximately 95% of subjects in experimental trials share the following characteristics:

  • Western
  • Educated
  • Industrialised
  • Rich
  • Democratic

Now, the WEIRD acronym isn’t a particularly useful lens in and of itself – grab any random collection of people and you’ll be able to group them together in a wide variety of ways.  Just because there’s a catchy term it doesn’t necessarily mean it’s a grouping algorithm with generalisable merit.   WEIRD though is a manifestation of another, more widely applicable concept – what I’ve occasionally referred to on this blog as the ‘people like me’ bias.   It’s easy to design for people that are like us, and difficult to design for people that are not like us.   That likeness is multidimensional and complex, and very febrile in its intersectionality.   It might be contingent on temporary group dynamics or larger cultural trends.  It might be based on nationality, but it might not be – I have more in common with a random university lecturer in France than I do with a random member of parliament in Britain, for example.   It might be educational, but perhaps not.  It might be based on ideology, or experience, or simple geographical context.   It’s a malleable property that can’t really be nailed down in a strict sense except when defined in opposition – it’s relatively easy to identify people that are not like us even if we might not be able to precisely enumerate our reasons.

In previous years, I taught this module in a relatively standard way.  Design a product, prototype it, evaluate it, revise it, re-evaluate it.   It works as an approach but it’s not very interesting and it didn’t turn anyone into passionate advocates for the value of the method.    Most of the products designed were safe and cleaved very tightly to the ‘people like me’ mindset.   Students designed things for themselves, or for their immediate social network.   One of the complications I added into the brief was they had to evaluate with someone not like themand feed their responses into their redesign.  Even with that requirement it was rarely possible for students to escape the trap of familiarity.     After all, it’s not like students have vast networks of willing participants they can tap for evaluations.   Even when designing for someone ‘not like them’ it was almost always a friend or family member.  The pressures of pragmatism pretty much guaranteed that would be the case.

As a result, evaluations were never really interesting because the results were never really unexpected.   Similarly, since the products designed were based on concepts they put together for an isolated module there was rarely a need to overcome any deep sociological objection to the relevance of what was designed.  They designed things they thought would be useful for the people with which they’d be testing.  Since in general they knew those people well, there was little serendipitous insight from exploring unfamiliar territory.

What’s needed then for teaching something like this in an optimal way is a scenario where:

  • The product has fixed, formal systems that need well defined with a minimum of ambiguity
  • Designers and audience likely don’t have any deep experience with the topic and thus are forced out of their comfort zones
  • There is some kind of cultural inertia that creates a sociological barrier to the acceptance of the product
  • Evaluating success and failure of the product can only be done through intensive consultation with the end users
  • There is no clear or optimal path that can be followed to achieve a baseline measure of success
  • There is room for creativity and artistry in the engineering of user acceptance
  • The expected audience will include many people who are not like the designers – either in terms of physical or cultural traits or in terms of personal preferences.

And wouldn’t you know it, I happen to have an overwhelming interest in a design scenario where those things all come together in perfect harmony.   It turns out that designing a modern hobbyist board game is the ideal exercise for bringing out all of these traits in a user centred design context.

I mean, let’s look at what we get out of this scenario:

  • Game rules must be clear, complete and unambiguous if a game is to be played without assistance from a designer.
  • It’s still a context where unfamiliarity is high – a lot of research is needed by students before they can really understand what’s involved. It requires a lot of exploration of the problem domain.  True, some students do come in with a greater knowledge of the modern board game scene than others but that’s going to be true of any scenario.  In this case though it’s all but guaranteed their audience won’t.  There is deep unfamiliarity in the space between designers and their users.
  • Whenever you say ‘board games’ to someone that isn’t part of The Hobby, they’ll instantly think ‘Monopoly’ or ‘Cluedo’. There is a powerful cultural inertia that needs to be overcome to make the product sociological accessible.
  • The fun in a game is entirely a subjective outcome, and the absolute only way it can be evaluated is through extensive user testing, followed by revision, redesign, and re-evaluation.
  • If anyone knew how to make a perfect game by following a set of well-defined steps, we wouldn’t be drowning in waves of mediocre Kickstarters. There is an uncertain starting point and an uncertain end point, coupled together by an uncertain path through uncertain territory.
  • The theme and aesthetics of the game can be as important in selling it to an audience as the systems and mechanisms. Theme by itself might be culturally accessible, or sociological inaccessible.
  • Games are for everyone, including players with disabilities. It’s vital to consider the physical accessibility context of play as well as the sociological dimensions of acceptance.

Last year, myself and my colleague on the module (Michael Crabb) put our heads together and redesigned the whole thing around a concept I’ve taken to referring to as cardboard prototyping.  It was, in our view, a wildly successful endeavour.  Not necessarily in terms of universal student enthusiasm (some in the class felt the exercise was unduly frivolous, or the design context was unnecessarily obscure).  In terms of how well it communicated the key lessons of user centred design though I think it’s fair to say we couldn’t have been happier.   Our first attempt at this was in the last session and was primarily exploratory – we’re really doubling down on it for the coming session.  In fact, this entire post is basically a ‘this is why you’re doing this’ manifesto for students in the coming semester.  HELLO FOLKS!

Step one of the Cardboard Prototyping toolkit is to introduce the topic to a wary and suspicious audience.  Shut Up and Sit Down have a video that does this perfectly well for our needs.   The very first lecture in the module incorporates this video to set the scene for the sociological barriers students need to overcome.  It doesn’t hurt at all that Quinns is a charismatic advocate for the hobby and shows in many respects the ‘cool’ credibility that comes from really knowing the ins and outs of designer board-games.   Quinns is, all by himself, an accessibility boon.

From that point on the whole system hinges on a series of core classroom exercises designed to expand student design vocabularies while also introducing them to some of the key tools they have for designing their games.   We introduce paper prototyping early by having students create paper versions of games and then playing them.    For those that haven’t encountered this concept, paper prototyping is basically a throw-away system of very rapidly iterating over the possible design of a system.  You draw very rough sketches of a thing, try them out with users, and then get rid of them and revise them as needed to home in on the most profitable design directions.  A paper prototype, at least in its early stages, should have no more work invested into it than you’re willing to rip up and throw away as soon as it doesn’t work or needs refreshed.   You should scribble things down, score them out, move them around.   As time goes by the prototypes might become more rigid, more formal and more sophisticated but early on these are literally just sheets of paper you treat like collaborative post-it notes.  Emphasising the throw-away nature of this avoids anyone getting bogged down in the sunk cost fallacy.  The cost of starting from scratch is supposed to be very low.  We call this cardboard prototyping because, well, board games are often made of cardboard.  Maybe we need a snappier name for it but the much better ‘Meeple Centred Design’ is already taken.   Patent pending.

Before we unleash paper prototyping, we show how a game works with reference to the actual physical product.  The key message here is that there is a scale of fidelity that they are navigating.  An important skill in user centred design is ascertain the reason why a prototype succeeds or fails.  Sometimes it’s fundamental to the design, and sometimes it’s because the fidelity of the prototype is so low that it distorts or hides or complicates key systems of information and feedback.  Within our Cardboard Prototyping philosophy students look at the physical products and create their own very low-fidelity simulations of these.  In the process they encounter a number of design challenges caused by the medium in which they’re working.   If you’re just ripping up sheets of paper to represent cards how can you make sure they don’t become identifying by their shape?  How can you make sure people can’t see what’s on a ‘card’ through a thin sheet of paper?   How do you hide and obscure information, and what difference does it make to the game if you don’t?   How do you deal with wear and tear on prototype components that are designed to be low-fidelity?    In other words, what are the hidden physical characteristics of the game that production quality might be obscuring?  Cardboard prototyping is a way of exploring both the design and the physicality of products that exist in the real world as opposed to simply within a computer interface.

Most importantly though what you get from this process is an appreciation of the essence of the game – the things that matter and the things that don’t.  It’s a process of analytical precision to extract the systems of the game from their aesthetic context.   That in turn is vital for really appreciating user centred design – it’s all about understanding what matters and what doesn’t.    Engaging in cardboard prototyping is an exercise in separating the purely decorative from the functional, and binding that up in a context that identifies the key physical necessities of production.

The first game we introduce like this is one night ultimate werewolf.  It has very few necessary components and rules that can be learned easily through watching a couple of example rounds.   Volunteers are solicited from the students, and they play out a round or two of the game until everyone understands how it works.   Everyone is then sent back to their seats, assigned into groups, and tasked with making their own prototypes and playing them to make sure they work.    After thirty or so minutes of this, we say to the class ‘Okay, now hold up a random role card from your paper prototype.  Everyone done that?  Good.  Now rip it up

At this point here, we intentionally throw a spanner into the clean design of the game they’ve been playing.  Their job, for the next thirty minutes, is to add a new role of their own design and then playtest it to see if it works.  Their job isn’t really to make the game more fun – it’s to be able to tell if the game is more fun, and why that might or might not be the case.   Important to this whole process is not that students design fun games – what’s important is that they are able to tell why a game is fun or not.    It’s not the end result in which we’re interested (except as board game fans ourselves) – it’s the process through which students arrived at an accurate evaluation of their results.   Having said that, last year students came up with some really interesting modifications to games and that by itself might be worth a post in the future.

We repeat this same basic design exercise with Love Letter.  This also has only a handful of components but packs a lot of game design into them.   We get them to do the same with Skull.   Last year we also got them to try out Tiny Epic Galaxies using the provided paper prototyping kit that was part of the Kickstarter.  Here they learn the importance of fidelity because TEG becomes a much more difficult game to enjoy if you’re trying to do all the action allocation with standard D6s and a lookup table.  I spoke about that a bit in our accessibility teardown of the game.

Through all of this, we want students to focus on the key elements of iterative design – how it tends to improve the quality of a process and how important it is to continually revisit assumptions and expectations as designers iterate upon their product.    We want them to understand both the logistical complexity of testing and how to get the most out of it.  The lessons learned here are intensely generalisable – while we focus on the design of a board game, the process and its key outcomes are exactly the same when you apply it to any other product.   In their honours year, they’ll be given free rein to do exactly that.

This year we’re going to expand the set of games we use for explanatory purposes – we’re probably going to introduce them to Once Upon a Time and Spyfall (to show that sometimes a paper prototype needs variety to bring out the value), Billionaire Banshee (to explore social acceptance of content), Coup and the Resistance (to really stress the need for repeated evaluation that goes along with redesigned roles in a tightly balanced game) and perhaps A Fake Artist Goes to New York simply because I haven’t played it yet and it seems ideal.   These games are selected partially for the design lessons they teach, but also because of the relatively rare way the finished product manifests:

  • Relatively few components
  • Relatively little content required to bring out the sense of the game
  • Relatively modular, allowing mechanisms and content to be swapped in and out
  • Relatively rules light so they are suitable for classroom discussion and demonstration

Cardboard Prototyping has turned out to be a really effective approach – the majority (but not the totality) of students in the class were highly complimentary of the technique.    They found that it made what could be a relatively dry and formal class into something a lot more frenetic and energetic.   That’s only really a secondary benefit though – at the end of the first semester we did this I genuinely felt that students had understood and accepted the value of paper prototyping.    I can really see the difference too as those students undertake their honours projects – they understand much better how valuable it can be to design with users forefront in mind.    With the traditional model of teaching UCD, I felt that I had given students a tool they didn’t really see the point of using.  With cardboard prototyping, I feel they have a tool that they know how to use effectively to properly situate their work in the context of usability and accessibility.   I call that a win, although I think we can still do better.

In the previous year, the assignment was to design a board game and a mobile app that would support it – either a digital implementation or a helper app.  This year it’s going to be to put together a Kickstarter page for the game they design which incorporates testimonials, gameplay footage and a pitch that makes it accessible to a wide range of audiences.   Last year they got to design the game entirely themselves without many constraints on mechanisms and theme.  This year they’ll be given the mechanisms they need to incorporate and told to make the best of them.    That makes introducing students to relevant examples of games in the literature much easier.  These changes to the module are intended to give a more rounded view of user centred design as it works in the context of fixed requirements and culturally situated accessibility.    We talk a fair bit in the module about how accessibility is as much about selling a product as it is about designing it.  These changes will hopefully bring that home in a way that helps students see the marketability value of adopting a strong user focus in all the work they do.

I was very happy with how well incorporating board games went in this module, and I’d be very interested to know what other work is going on in the area.  Are you an educator?  Are you using board-games in an education context? Would you like to?  Get in touch – I’d be very interested to see if there’s some scope for learning from others and also potentially collaborating on innovative teaching approaches.  Are you a student?  Are you learning with board games or wishing you were?  Get in touch too!  Let’s bring together all the lessons learned and lessons not learned and see what we can get cooking here.

Related Jobs

Toys for Bob / Activision
Toys for Bob / Activision — Novato, California, United States

Sr. Software Engineer (Animation) - Toys for Bob - Novato, CA
Island Brains LLC
Island Brains LLC — San Mateo, California, United States

Mobile Game Producer
Qualcomm — San Diego, California, United States

3D Engine Developer
Qualcomm — San Diego, California, United States

Software Engineer

Loading Comments

loader image