{"body":"

Ocado isn’t just a serial disruptor and a wonderful company to work for, it also opens you up to things you’d never have thought you would love to do. On my second day, just after work, I was persuaded to play a game of Imperial Settlers with two team leaders and a manager. Today, over four years later, I design board games of my own and attend game hackathons.

Over time I came to a surprising conclusion: the processes of creating board games and creating software are actually stunningly similar. An iterative approach and working with feedback is their bread and butter. However, there are three crucial things that board game designers do differently:

They rapidly prototype their solutions
They test everything they can (on humans!)
At all times, they have in mind the urge to simplify their product

What if we adopted this approach when working with software? Let’s explore the possibilities - read on!

Lesson 1: Rapid Prototyping

In the software world, we do Agile - mostly Scrum and Kanban. Board game designers went one step further and turned to Rapid Prototyping. In fact, it is actually the process when it comes to board game design - everyone does it. Why did a niche methodology like this take a whole industry by storm?

All I have at the start of a game design project is an idea so abstract that it’s hard to describe it to someone else. The only way to communicate (also to myself!) and really understand the idea I have at hand is to make it real. To build a physical prototype. And this statement holds for the whole design process - I am going to need an actual thing at every stage.
The prototype is also there to help me gain knowledge about what works for the players and what doesn’t. Based on that knowledge, I will iteratively change the game, which also means building another version of its physical representation.

As I am going to change the prototype multiple times on the way, so it’s important to take the right approach to building it.

Epically Failed Prototyping

Imagine a perfect prototype of a player’s board. A clear name, places for all 18 resources and a futuristic city in the background. All high-fidelity, with a great level of detail, gradients, shading etc. Can you see it? It looks just like a published game!

When I started my first game, this was what it looked like. I was even more proud of it when I saw how its appearance amazed my early players.

The problem is, after a couple of tests I got the following feedback: “You have too many resources in the game.”

Removing some of them would require me to modify not just the boards, but almost all of the 165 cards I had. You can imagine my horror when I recalled I made all the components one by one in GIMP, and the time it would take to implement the change.

This happened a couple more times. Every other iteration flipped the mechanics of the game upside down, forcing me to spend many hours reworking everything. I was definitely doing something wrong.

More Rapid than it Looks

What if, instead of building the fancy board, I started with the one you can see on the right? With the minimum I need to play, and nothing else?

I’d have to rework everything from scratch - which doesn’t bother me at all, since each iteration flipped the mechanics upside down anyway.
People will not want to play an ugly game - surprisingly, this isn’t true. If they have a great time, they’re going to play the sketch over and over again. And if they don’t, they’re going to give more honest mechanical feedback as they are not distracted by the aesthetics of a game.
I can’t verify that people like the theme of the game - that’s great news, as I shouldn’t be doing this now. Actually, in the majority of cases, the publisher is going to change the graphics, theme and title to fit the market anyway.
When the game becomes stable, you’ll still have to do huge rework on every small change - and that’s when I’m going to change the “technology” behind my prototype to web technologies like HTML, CSS and React.

And there’s one more thing: if I decide that the game doesn’t hold water, I can drop it more easily if I have not invested countless hours in creating it.

Lessons learned

The above attempt, plus a lot of contact with other game designers, taught me two important lessons about rapid prototyping that work equally well with software:

UI doesn’t matter at the start*; UX is king. At the early stage of prototyping, I want to have a product users are having a great time with, not a work of art.
However, the technology behind your UI matters. When prototyping rapidly, the most important design consideration is how quickly you can iterate with the product. So at each stage, use whatever tech drives you fastest.

Lesson 2: Testing with Users

As I mentioned before, the prototype’s main role is to provide knowledge about how users want to use a product. The only practical way** to gather such data for a board game is… you guessed it! To watch people play it. It is called playtesting and has a direct, established counterpart in the software world - user testing.

How to User Test?

A user testing session requires:

A user who sits in a room and performs certain actions using a product
A facilitator who takes care of the user and gives them tasks according to a scenario
A group of observers who sit in another room, but are able to see the user’s actions. They take notes, which will be used to draw conclusions on how to progress with the product

Usually you need to conduct 3-6 tests and aggregate the results to find the top issues you should work on next.

The separate room is there to provide better focus for all participants and make the communication between them impossible. Observers are often tempted to help out the tester (which spoils the results) or get angry at them for not being able to use the product properly. Designers who observe playtests don’t get this much comfort - instead, in order to get the best possible feedback, they simply need to learn to restrain these temptations.

Why User Test?

For me, the great advantage of playtesting, and user testing by analogy, is that it provides insights that are hard to dispute. Even as the game author, keen to defend his creation, I have no answer to the following facts:

Half of the players say that 18 resources in a game is too much
In an average game, I need to repeat how to build cards three times
90% of game winners do not use the Fusion action
Completing the Hazard quest doubles the game duration. Half of the players are upset about its unpredictability
The superpower of Wood is used against its purpose and it enables the leading player to hack the game

All of these are genuine issues that happened to my game at different stages, and hard facts to which my attachment to my creation had to yield.

The above examples also illustrate what I pay attention to during the test:

explicit feedback
player questions
actions they do or do not perform
in-game emotions
various metrics - including play time
last but not least, my intention as a designer

All of these easily map to the software world - including the intentions, which translate to business requirements.

When to User Test?

The most revolutionary idea for software developers regarding the user tests is not even to do them, but when to do them. And the board game creators’ answer is: all the time. Let them be the single thing to drive your development process.

Designers often aim to have a schedule according to which they do playtesting. Let’s follow this idea and do user testing e.g. every week on Wednesdays. All of a sudden our development rhythm becomes organised around the tests:

We need to prepare an increment between one Wednesday and another, i.e. we get weekly sprints and are forced to make stories small enough to fit in
The user tests themselves serve as a form of a demo
The insights we get from the sessions gives us input for the next sprint

As you can see, this way of working should be pretty natural to software development teams.

Obviously, to do user testing regularly, you need to find enough people to test the product on. It’s never an easy task, but my board game experience suggests that it’s much easier if you have great PR, make it easy to sign up, and incentivise your testers. A game studio (and also a board game cafe) from Kraków called Hex Games does it quite effectively: they announce the call for testers on a 3.500-fan Facebook group and give a free drink and a snack to each volunteer. In this way, they were able to have up to 8 testers 3 times a week for an impressive number of consecutive weeks.

Lessons learned

Having done over 200 playtests of my games and a couple of user tests at Ocado, I came to the following conclusions:

Trying to make a really usable product without seeing actual interactions is pure guesswork. People may struggle to do the simplest things without you even knowing. User testing can open your eyes and help you eliminate the friction.
Rapid Prototyping driven by user tests allows you to experiment really quickly. If you have a product or feature that’s hard to get right, make sure to try it out.

Lesson 3: Designing for Simplicity

Software is complex. A lot of the complexity is hidden on the backend, where elaborate algorithms do their invisible jobs. As a result, the users may see a system as simple, even if deep inside there is a Gordian knot of threads and a ton of technical debt.

768px-Mossy_leaf-tailed_gecko_(Uroplatus_sikorae)_Montagne_d%u2019Ambre.jpg

Now let’s map this to a board game… wait, there is no backend there! The complexity has nowhere to hide! Users have to execute all the algorithms by themselves, without any help but the rulebook.

That’s why board game designers need to pay much closer attention to making (and keeping) things simple than software developers. This also means they are much more skilled at it and have worked out ways to identify when a piece needs to be worked on. Some of these methods are applicable with software design as well.

Revealing the Complexity

We’ve already discussed one way of finding places that could use simplification: user testing. For board game designers, this is an obvious place to start. However, complexity doesn’t always come up as a direct user complaint. Sometimes it hides as a smell (similar to code smells) that can be identified by analysing aggregated feedback. Here are some examples:

If users repeatedly ignore a feature (rule), let’s remove it. Hardly anyone will notice, and it adds to the overall complexity of the product.
If a feature (rule) seems detached from the product, it may still be a great idea… for another product (game). If you have an existing product where it fits, why not move it there? If not (and you don’t want to create a new one for it), why not just jot it down and remove it?
If a feature (rule) requires a lot of explanation or training, it’s probably not about the users, it’s about the feature itself. Maybe the same thing can be expressed in a more intuitive way. Remember the example of me needing to repeat 3 times how to build cards? A layout change was enough to fix it.
Lastly, if people keep misusing or abusing a feature (rule), it definitely needs a rework. Its complexity was probably why we missed the possibility of it being used against its purpose in the first place.

Removing complexity

Once we have found the overly complex bits, we need to remove the excessive complexity. Unfortunately, there is no easy way to streamline this process, you have to do it case by case. I don’t think there is a general rule here, except for one: you need to be ruthless and consistent. Search for a solution until the smell disappears.

I call it ruthlessness for a purpose. The hardest obstacle in simplifying my own designs are my own emotions as an author. As human beings, we are biased towards defending or “fixing” our creations even if the user tests have proven without doubt that they are useless. It’s really hard to drop something that you took hundreds of hours and/or pounds to build. Luckily, there are a couple of lifehacks I use and can recommend to you to prevent this:

When I add a new feature/rule, I treat it as a hypothesis. It has to prove itself to earn the right to be called “part of the product”.
The first versions of what the user/player can see is… ugly. Just in case. It’s much easier to drop ugly things than good-looking ones, and as I mentioned earlier, UI doesn’t matter that much for a start.
For me, the ultimate lifehack is Rapid Prototyping. It gets you to spend little time on individual features and creates a build-and-drop mindset by design.

Lessons learned

As software developers, we seem not to need to pay as much attention to cutting down on complexity as board game designers. However if we do, we might find ourselves:

creating applications that are straightforward even for new users
having fewer features to support
building up technical debt more slowly

Summary

Prototyping rapidly, routinely testing the prototypes on players, and designing for simplicity - these are the three main rules of the board game design process that we can easily port to software development. You can also use parts of it if you like - my Ocado team already applies some of these principles to one of our products with great results. If, just like us, you have a product at hand that is exploratory in its nature, needs innovation to be successful, or is all about UX - the Rapid Prototyping + User Testing mix may be a perfect fit for you!

*There are exceptions to this, e.g. layout - the pieces of UI that influence the intuitivity of a product are actually part of the UX.

**Except simulation, which is expensive with board games; yet in some cases it is used to balance them.

","presentation":{"classes":"","theme":"theme-default","columns":""}}

Three lessons software developers can learn from board game development