Tug Brice
Researcher for Hire
I am a UX researcher and conceptual designer. I've got an MS in Games for Learning from NYU and a BS in Psychology.
​
I founded Ice 9 Design in 2011 with several friends to work on projects and train up the skills we would need to get jobs. Since then, we have published Notes and String, set up a nationwide non-profit to help the homeless, developed some board games, and created an AI.
​
I'm looking for work as a UX researcher or designer.
Click the button below to set up an interview.
Lifecycle of a Research Project
See a walkthrough of my process through a real research project, including reports and presentations
Background
I am working on a board game called Flower War and have reached a point in the design cycle where significant elements need testing before I move on. I need to test to see if certain basic game elements are suitable and functional before I work on designing more advanced elements. I ran a playtest at the Cincinnati Game Designers Playtest Night on 11/30/2022.
After the playtest, I wrote up a full report (summarized below) and created two presentations, one for my design team and one for a fictitious executive. These reports can be found at these links:
Step 1: Define the goals
The first step in any research project is to define the test and the goals. In other circmstances, I would be given goals by someone else and I would have to design my test around that, but since I was both the primary designer and primary researcher on this project, this was easy. The main thing I needed to know was if the rough numbers I had set up in the game were right. I also needed to know if I had any mechanics that weren't interesting to the players, and I had a suspicion that the game as it was would end in a stalemate. So those were my three goals for this test.
Playtest definition:
-
Test the numbers:
-
Is the game competitive?
-
Is the game too challenging?
-
Is the game too easy?
-
-
Test the mechanics:
-
What mechanics are used/ignored?
-
-
Test the end-game:
-
Is the endgame going to result in a stalemate?
-
Step 2: What are my obstacles?
Every test has obstacles it has to overcome. In my case, the two main obstacles with this test were my materials and the fact that this was a new game. Since I didn't have a production copy of the newest version, this test was going to have a very rough player experience. I was also going to have to explain the rules since no one has played this version of the game before. I didn't have pre-printed rules sheets, which was going to be yet another thing that was going to make the player experience rough.
Obstacles:
-
Materials:
-
Not production-ready.
-
Very rough UX for this version.
-
-
Rules
-
Players will not be familiar with the rules.
-
Don’t have pre-printed rules sheets.
-
Step 3: Recruit Participants
Now that I know what my goals and obstacles are, it's time to recruit participants. Participants should be carefully chosen to match the test. In my case, I wanted to choose participants that can handle new games and are okay with rough player experience. The Cincinnati Game Designers Meetup has a Playtest Night on the 3rd Wednesday of every month. This is the perfect place for me to test my game: they will be expecting to play new games, and since they are game designers themselves, they will be used to works-in-progress.
Participants:
-
Cincinnati Game Designers Playtest Night - 11/30/2022
-
Recruited two attendees to participate in the test
-
​Step 4: Run the Test
Once participants have been recruited, it's time to run the test. Once I arrived at the Meetup, I set up my supplies and recruited the participants. Once I had players, I explained the rules and started the game. The game ran well, although the experience was just as rough as I expected it to be. We reached the endgame, and the expected stalemate happened. I let it go on for a few rounds until it was clear that there wasn't going to be a quick solution, then ended the game there and solicited feedback.
Procedures
-
Set up the board/get materials ready to play
-
Hand-wrote rules cards/references.
-
Set up the board.
-
Loaded spreadsheet/RNG necessary for cards
-
-
Recruited players/explained rules
-
Players were other game designers who had come to test their games.
-
Two other people participated in the test.
-
-
Played game.
-
I participated in the test to help things run smoother.
-
The game ran until the endgame stalemate.
-
-
Solicited feedback.
Step 5: Analyze Results
Once the test is done, it's time to analyze the results. Gathering data doesn't do much good if that data isn't used for something. In this case, I wanted to see how the test's gameplay and player feedback matched up with the test's goals.
The game's numbers were right where they needed to be. Nobody got too far ahead or behind, and while these numbers will change with the introduction of new mechanics, they are a great place to build from. Some mechanics were ignored, but most were used. The ignored mechanics were ignored for a good reason, and I think that already-planned mechanics will induce changes in player behavior that will make the ignored mechanics more attractive. The game did end in a stalemate, but again, already-planned mechanics should change the game balance enough to break that stalemate.
There were some possible problems that I didn't account for, but most of those can either be chalked up to the bad UX or for reasons that were washed out by the bad UX. I will need better resolution to investigate those problems. Without a production copy, I can only investigate the overall shape of things. Deeper dives will require better UX.
Results
-
Numbers good
-
The game stayed very competitive.
-
There was some resource hoarding, but not enough to constitute a problem.
-
Hoarding was caused by the endgame stalemate issue and can be addressed in several ways.
-
Faith penalties can probably be raised slightly to keep making the game feel more apocalyptic.
-
-
Mechanics are mostly used.
-
Movement mechanics were used in the late game but not the early game.
-
No resource pressure early meant players saw no need to move, but late-game scarcity caused players to use the mechanic.
-
Combat/Trade ignored.
-
Combat wasn’t well explained and didn’t have a lot of incentive to use.
-
-
Apocalypse mechanics probably didn’t get enforced.
-
Caused by bad UX and excessive bookkeeping needs.
-
-
-
Endgame Stalemate happened
-
First-past-the-Post caused an endgame stalemate.
-
No one could get the resources to move the figure two steps at once.
-
This resulted in a stalemate.
-
Characters should solve this by changing costs and resource gain.
-
Characters should also give incentives to move one figure vs. the other.
-
Step 7: Communicate the Results
Normally this is one of the most important steps of the research process, but in this case, I am the primary designer. I do have one other person on my design team, but I can tell them everything they need to know about this test with a phone call. But I wrote up reports and presentations for this playtest anyway.
​
Normally I do three different things to communicate results: I do an extensive internal written report, which then gets boiled down into a presentation for the research team. That gets turned into an executive report for communication outside the research team. My executive reports are generally a slideshow that follows this format: A title slide, a slide summarizing recommendations, a slide with the test goals, a slide with test results, and then one slide each going into the recommendations in depth.
Recommendations
-
Keep the numbers as they are.
-
The balance is good for now. We will need to rebalance after advanced mechanics are added, but these numbers are a good base to build on.
-
-
Add advanced mechanics.
-
Start with Characters. Characters should solve most of the problems within this playtest.
-
-
Build a better copy of the game before the next test.
-
Once Characters are added, this test will need to be rerun. Get a better copy of the game to run that test.
-
Step 6: Make Recommendations
Results are all well and good, but what most executives really want is insight. Research is done for a reason, and so should come with recommendations. A researcher is more than just a person gathering facts, they are also part analyst. Their job is to turn data into insight.
​
In this case, the insight is that I should keep the numbers the same and implement the mechanics I have planned. They are good enough to build on right now, and I will have to rebalance them after I add the new mechanics anyway. Most, if not all, of the issues that came up in this test with player behavior can be solved with clever implementation of these new mechanics. So my next step is to implement those mechanics.
But before I test again, I need to get a better prototype of the game so that I can get better resolution in the next test. This will be especially important because the next time I test the game it will be more complicated, which means bad UX will have a bigger impact.