5 key design lessons I learned while making my first board game

By November 18, 2015Game Design

Note: this is a cross-post of an article I wrote for Medium.

By day, I’m an interaction designer for medical software. It’s a challenging environment with complex, important problems to solve and one where usability is of critical importance. I find it to be a very rewarding yet demanding career. By night, I get to follow one of my biggest passions, board games.

When I decided to start making my first board game, Diabolical!, I learned things about experience design that I never would have expected. Here are the five key lessons I’ve learned so far.

1. Every worthwhile product sits on a rock solid foundation

When I first started working on Diabolical!, I had more ideas than I could count. As is so often the case when we start creating a new product, it seemed like there was no end to the inspiration for what I could do with the game.

After finally managing to put a cork on my ideation process, I strung together several of the elements I had come up with and created my first prototype. When I took it through play testing, it was terrible. It was exceedingly slow, hard to learn, and poorly balanced. What’s worse, there were many situations where a player couldn’t do anything for large portions of the game (which doesn’t make for a very enjoyable experience).

“No problem,” I thought. “This is the first version of the game and there are bound to be issues like these. I’ll just figure out what’s causing the problem and fix it. Then, it’ll be golden.”

What I didn’t realize however, was that in my rush to put all of these features into the game, I made it nearly impossible to identify what was causing the problems within the flow of the system. This was due in large part to the complexity of the system I had created, resulting in emergent effects, where different elements of the game were interacting with each other in unexpected ways.

After flailing around trying to adjust various elements of the game with little success, I came to the realization that I had put in too many features too quickly, and that the only way to address the issues within the game would be to strip it back to its core and build from there.

When working with a complex system (which these days is just about everything), it is vitally important to identify and refine the core of that system before layering anything on top of it. If you don’t get that key infrastructure right, throwing additional features at the product will only create more problems and a worse experience overall.

By stripping the game back to its most basic elements and testing those, I’ve been able to identify and resolve its most significant problems and put the game on a much stronger path toward completion. Now, the core mechanics of the game are far more effective, resulting in a more engaging playing experience.

2. Let go of your less-polished skills and allow your strengths to shine

Like many designers, I can be a bit of a control freak. Sometimes I feel like the only way to make sure things are done to my standards is to do them myself. When I decided to create my own game, I looked at is as an opportunity to do something the way I wanted it done. I was excited at the prospect of having control over every little element.

However, it was that same fussiness that slowed the progress of the game to a snail’s pace. One area in particular was a huge sticking point: the art. Despite being a designer, and despite having an art degree, visual design and illustration are not my strongest suits. I am much more of a conceptual designer, using my design skills to create solid information structures and interaction patterns. Knowing this, I resolved to improve my illustration skills so I could do the art for the game to the level of refinement that I wanted. So I proceeded to spend months, and months, and months?—?nearly a year in fact?—?working on a single illustration for the game, and it still wasn’t what I wanted it to be.

Needless to say, this was a frustrating process for me, and I knew the game wasn’t going to go anywhere if I continued to rely only on myself. Fortunately, I know James, who happens to be an incredible artist and someone who I have immense respect for. With a little convincing, he agreed to sign on and do the art and visual design for Diabolical!

Ultimately, we decided that he would have the final say in anything related to the art or visual design of the game. By letting go of control in that area, I’ve been able to focus my time much more effectively on the design of the game itself, and I couldn’t be happier with the results. Not only am I able to work on the parts of the game that my strengths are most apt to handle, but I’m also free from the burden of making decisions in areas of the game where there is someone more competent than myself to handle it.

3. Learn when to defend your design… and when to shut up

One of the most important skills you need to know as a designer is how to defend your designs. If someone asks you why you made a specific design decision, the answer should never be “I don’t know.” There should be a reason for every element of a design from layout and interactions, to typefaces and colors. No matter the project, you will have stakeholders who do not have as much design experience as you do, and it will be up to you to explain to them why you do the things you do. Being able to explain yourself will give them confidence in your expertise and will get you through a project much more smoothly.

Unfortunately, it can be difficult to know when to shut that skill off.

When I started testing Diabolical!, I did so with close friends and colleagues, many of whom are also designers. At first, when they tried to give me feedback, I found myself interpreting their critiques as questions about why I made a certain decision. If they said something like, “I didn’t like how that card worked in the game,” what I would hear was more along the lines of “Why did you make that card work that way?” And I would respond with my reasons for making such-and-such decision within the context of the game. This method of internally rephrasing statements is very effective when working with stakeholders, but can be harmful when working with end-users.

It took one of my friends pulling me aside and telling me that he thought I was being defensive for me to realize my mistake. There is an important difference between defending your designs and being defensive, and it’s a subtle distinction every designer needs to learn. In the context of a stakeholder relationship where you are guiding a team through the design process, defending your design work is a necessary step to creating the best product possible. However, in the context of gathering end-user feedback, defending your design is at the expense of gathering the information needed to do good work.

Being defensive makes people feel uncomfortable giving you feedback. It belittles their experience and can make them feel unnecessarily inferior. When working with end-users, avoid talking about why you made a decision and ask them more questions about why they feel the way they do about your product. Shut your mouth and open your ears, because that information is worth more than gold.

James and I decided to implement an anonymous survey for people to relay their playing experience. This allowed testers to freely speak their minds and also created a consistent format for us to measure our progress against. The information gathered has been integral to our ongoing success.

4. Your ideas are not your children; killing them is not a crime

While working on the board game, I was inspired by many of my favorite games I’ve played throughout my life. I wanted to include elements from many of those games, plus some of my own. However, when it came time to test the game, many elements simply didn’t work together the way I imagined they would. At first, I was very attached to my original ideas, and I was very reluctant to let them go as I iterated on the game. It’s incredibly easy to get attached to an idea like I did.

At face value, ideas can seem a lot like children. They start inside of us, we nurture them, and we work to bring them into the world. With that comes an innate sense of pride and attachment. We even use words like “conceive” to refer to the generation of an idea. Our minds are like a womb, in that an idea that is still in your mind is protected from the onslaught of uncontrolled variables introduced by the real world. Sure, you can take some of those variables into account when you’re coming up with your idea, but ultimately it’s impossible to fully understand and account for every possible thing that could go wrong.

While ideas can seem like children, once you start bringing them into the world, it’s much healthier to think of them as part of a herd. As with any herd, the smaller, weaker ideas will be eliminated through natural selection as the real world exerts its influence. Overall, the herd is better off for it, as the stronger ideas left are more capable of surviving.

When bringing an idea into the real world, there are two key factors that will determine your success:

  1. Your ability to render the idea as it exists in your mind
  2. Your ability to respond the forces exerted on the idea by the real world

Jared Spool?—?one of my design idols?—?defines design as “the rendering of intent.” While I feel that this is a solid definition of design, I believe it fails to consider the impact of reality on that intent. Contrast this definition with a quote from Michelangelo: “Every block of stone has a statue inside it and it is the task of the sculptor to discover it.” While Jared’s definition of design starts with the designer’s intent, Michelangelo’s quote implies the opposite: that the potential statue already exists and expresses itself through the sculptor’s hands.

The truth I believe is somewhere in the middle. Design is a reciprocal process between the designer and the forces of reality. As a designer, you must allow the real world to help shape your creations and to allow your original intent to reshape itself using your hands.

Ultimately, the forces of the real world may say that part or even all of your idea must die. It will be up to you to listen and to cull the herd. When I listened to what the game was telling me through testing and allowed my intent to reshape itself, the game ended up going in a much better direction overall.

5. Slow progress is still progress, but deadlines are mandatory

I’ve been working on this game as a side project for quite some time now. At times, I’ve been disheartened by the fact that it’s taken me years to get where I’m at now (and I’m still far from “done”). However, when I consider that my progress has occurred almost entirely on evenings and weekends, and that I’ve gotten where I have in addition to succeeding in a demanding full time job, while still maintaining strong relationships with my friends and loved ones, I am proud that I’ve been able to continuously move the bar forward in the way I have.

In the US, we have a tendency to worship work. Sometimes, I’ve felt guilty going out for a nice dinner with my girlfriend instead of sitting at my desk, plugging away at the game. This is not a healthy relationship with work, and it leads to burnout and resentment. It’s important for us to remember that there is life outside of what we do for a living, even if we’re lucky enough that our work and passion align.

In our day-to-day lives, we only have so much time. To stay happy and healthy, some of that time must go to rest and being around the people we care about. However, it is equally important that we do not allow ourselves to stagnate. Maybe you have a novel that you’re working on in your spare time, or you have a cool app in mind that you want to develop. Make it a priority and trim the fat in your life. You’re not going to get there by watching three hours of Netflix every night. Nor are you going to get there by working on it every spare minute of the day, ignoring rest and family.

For any side project, it’s important that you set small, frequent deadlines for yourself to keep things moving. James and I use a sprint model for the game, where we have a checkpoint every two weeks where we review our progress from the previous two weeks and set goals for the next two. Having someone else involved to keep me honest has also been extraordinarily helpful. We’re finding that in order to get to the level of refinement that we want, we’re going to have to move a bit more slowly than we originally intended. Be that as it may, if the alternative is burnout and resentment, moving our timeline is an easy choice.