If you haven’t already read the thrilling Part 1 of this interview with Joshua Yearsley.
Well… go ahead.
We’ll wait.
For those of you who have, here’s where we left off. We started shifting away from rulebooks and editing to talking about UI/UX design. We’ll also cover what it means to be a game developer and Leder Games‘ process.
Enjoy!
A lot of what you prescribed and wrote about in your blog mirrors software development UI/UX philosophies. Do you draw inspiration from other disciplines? How do you come up with improvements to your process?
Software UX, especially video game UX, is where I draw almost everything from, honestly. There’s a simple reason for this: right now “UX” is almost synonymous with “software and electronic hardware UX,” so most writing about UX is grounded in these fields. That said, UX itself draws from tons of disciplines: psychology, economics, semiotics, etc., so implicitly I’m drawing from those disciplines too.
A big part of improving my process is critically evaluating my own work, especially in public, and listening to responses. My blog post you mentioned above was a synthesis of what I learned working on Root core and Riverfolk, and for Root more broadly I did a deep dive into UX insights and mistakes at the Games User Research Summit here. For Oath, I wrote a diary about UX here. For Root’s Marauder Expansion, I wrote a couple designer diaries for the Keepers in Iron faction here and here. The stakes feel high working on something that so many people will play and critique, so writing about my own failures and the lessons I’ve learned is a great way to both diffuse that anxiety and get better at my work. It’s a privilege to work at Leder Games because the company makes sure we have the space, even while deep in development, to talk publicly about our process and where we got things right and wrong.
It’s so fascinating to me that the approach you’re taking for these usability problems is so cutting-edge. I’m not sure if you’ve read it but in The Lean Startup, Eric Ries (not to be confused with Eric Reuss, creator of Spirit Island) introduces rapid experimentation.
Where building a product is a constant cycle of hypothesis testing and measurement. It’s all the rage in software circles and sounds like you’ll be following a similar approach. How do you think your background in science has helped you with these UX problems?
Even though materials research and user research don’t share many surface similarities—the former isn’t even research on people—all research shares a basic process of hypothesis creation, experimentation, observation, and hypothesis revision, and likewise an ethos of curiosity and open-mindedness.
In user research, you need to figure out why people are having problems. Unfortunately, people are notoriously bad at hypothesizing why they had the problem, especially if the problem happened a while ago. (All kinds of subtle biases get in the way—they might intuit what you want to hear, they might want to impress you, they might just say the problem is actually their fault, etc.) So instead, we try to observe how people act and what they’re thinking in the moment and use that data to construct our own hypotheses, make a change based on our favored hypothesis, and then test the change on someone new to see if the problem persists. You can try all you want to impose your own vision of how the world should work or how people should act, but that won’t help in the end. You need to meet the world, and people, where they are.
This is a real problem and one you see often. Like when players complain about a card or player power being overpowered, even though they’ve only played once. So what techniques do you use to separate players’ thoughts and complaints, from their actions?
To get closer to people’s true understanding, you might run a full usability playtest, where a group learns and plays the game with nobody guiding them; this will reveal silent confusions, but each test will take you and the playtesters a lot more time, slowing your iteration, and the players may not naturally engage with all of your game. Given this, it’s important to run explicit cold-spot tests, where you ask players to demonstrate how these untouched parts of the game work, either as part of full usability tests or in dedicated tests. Finally, something I started back in Root but have since embraced even more is the materials and aids test. In a perfect world, players could sit down at the table and start playing your game without looking at the rulebook or watching a how-to-play video. For most games this is not possible, but it’s still valuable to work toward that goal by providing useful play aids. In Root, for example, I set the goal that a player should be able to learn basically all of their faction just by reading their player board, and I tested this by only explaining the core game and then asking each player to walk me through their faction’s turn using only their player board. For Ahoy I’ve taken this further by asking players to teach each other the core game using only the game’s quickstart booklets, not the rulebook.
You started developing games with Root, and then with Oath. There’s a lot of information about the process of board game development online, but not as much about the role of board game developers. As a game developer, what do you do?
My sense is that if you ask three developers what they do, you’ll get four answers. I’m not sure why this is true—maybe it’s a sign of the industry’s immaturity in how we define roles compared to other mediums, or maybe it’s a reflection of company structures that have few full-timers and lots of freelancers, or maybe it’s just because different designers need different things and that’s fine. But in the broadest sense, a developer does whatever the designer and publisher need to get the game to the finish line. Here are some things I’ve done as a developer:
Refine the design. The designer might need a sounding board to talk through sticky design problems, or they might even ask the developer to come up with targeted solutions. For example, later in Oath‘s development we realized that we needed to completely rejigger the Campaign action’s dice resolution, so Cole Wehrle (the designer) asked me to come up with some alternatives to try. To do this, the developer will need to have worked on the game for long enough to know what solutions the designer has already tried, and they should have a good sense of the designer’s sensibilities, goals, and aesthetics so they can present solutions that feel like the designer’s own.
Refine the product. Let’s say the game is over budget by 25 cents per copy, which is a lot! So, the publisher or designer might ask the developer to help make the game more efficient at using its pieces. Maybe you can use card backs for randomization instead of dice? Maybe the box is too big for what’s inside? Maybe there’s a system that the designer is attached to but really doesn’t need to be in the game? Maybe there’s a custom component that can be a generic piece instead? To do this, the developer will need to understand what the manufacturer’s capabilities are, where the costs are coming from, and why the designer has chosen the pieces they’re using currently.
Create content. Some games are built in a way where there’s a core system, which is mostly the designer’s responsibility, and then tons of content on top that the developer(s) can make. Oath, for example, has over 200 unique cards, and Cole was going to die if he had to make every single one of those himself! So, every week or two, Cole would have a content meeting with me and Nick Brachmann, another Leder Games developer, where we reflected on which cards were working and not working in playtesting, and we brainstormed and presented ideas for new cards or, as development continued, refinements on existing cards.
Improve usability and accessibility. As a project drags on, the designer often gets so close to their game that it becomes hard to understand the perspective of a new player. A developer can offer a fresh set of eyes and become the lead advocate for new players. They might run usability-focused playtests and rulebook reads, act as lead editor and/or collaborate with copy-editors and proofreaders, and help the game designer, graphic designers, and other production specialists collaborate on improving the user experience. There’s a caveat here: it’s entirely possible for a developer to work on the design close enough and long enough that they fall into the same perspective trap as the designer, which is just one reason why it’s important to engage with players constantly!
Manage playtesting and rules. This can involve a lot of things: setting up a Discord chat server for playtesters, finding and on-boarding playtesters, creating feedback forms, answering playtesters’ questions, making and updating the physical and/or digital prototype, and synthesizing playtest feedback into insights, patterns, and potential changes to discuss with the designer. To give good feedback, your playtesters will also need a reliable, up-to-date rules document, and they will need to know about any rules changes. The designer usually has a dozen versions of the game rattling around in their head at once, so it often helps to have the developer take charge of the rules. The developer might review potential rules changes with the designer once a week, decide which changes will go into the new public version, make those changes, and then write up a changelog for playtesters.
I liken this to my role as a manager, where often I think of myself as the grout between the tiles. Not very flattering, but it means I’m doing the jobs that need to be done, lifting the team by allowing them to focus on their strengths.
So I wonder if you feel like you’re more in that servant leadership role, or is it more hierarchical?
Indeed, much of a developer’s work is figuring out how to pull the most off the designer’s daily plate, so they can focus on what they do best. Projects at Leder Games have always felt collaborative and co-creative—we try to not treat people as “a set of hands.” Rather, we want people to learn new skills, try out various roles, and grow. For example, on Root’s Marauder Expansion, I started as a developer but ended up also designing the Keepers in Iron faction based on Patrick’s original concept. So no, I haven’t felt a strict hierarchy as a developer.
Last question and it’s a gimme after all the fantastic answers you’ve given so far. What are your favourite board games to play when you’re not on the clock?
The game that I’ve played the most times over the past five years or so is Decrypto. It’s an absurd design, and I find it almost impossible to teach without just saying “We should just jump in, and I’ll show you how it works step by step,” but that might just be because it breaks through the expectations of older word games. It’s deeply strategic! It’s a team game! It can be raucous or serious! It allows for wild creativity! I could go on.
As far as the game I’ve put the most hours into, that’s probably Eclipse. When I first played it at a con back in 2011, my friends and I decided on the spot to pool our money and buy an aftermarket copy from eBay, since it was already sold out everywhere. The second edition basically fixes all my nitpicks about the first edition, and I’m excited to play it more now that I’m gaming in person again.
That’s it! Massive thanks again to Josh for being the first victim of Roll to Review and for allowing me to post such ridiculous images. It was fantastic to get a glimpse at what goes on behind the curtain, and it still surprises me how much of my own work is reflected in the board game development process.
Remember to check out Leder Games’ new releases Ahoy, and Arcs later this year to catch a glimpse of Josh in action.
The first interview on Roll to Review. How do you think it went? I would love to know what you think. What questions should I have asked, but didn’t? Let me know in the comments below.
Loading ...
