Dev Log 4: User Centered Design
Introduction
When it comes down to user centered designs, I often find that the best approach is to establish an idea of your user and then try to solve problems for them in relation to what you're designing. Take our board game for instance. We have target demographics already established. These demographics are characterized by personas. These personas each represent a single one of our most common intended user. Aiden Tremblay is a 13 year old that browses social media in most of his free time. He is one of our personas, being the perfect age-group for someone to start learning about Cybersecurity. With Aiden in mind for our game, we have an established user to design for.
Keeping it crystal
Being a 13 year old, Aiden has been through most of elementary school. He might be most of the way through 8th grade. We already understand the reading comprehension level for our intended audience. This is where one of our pillars of design comes in: Clarity. Our design should be completely readable by people of 12 years of age or higher. When it comes to writing for this age group, we must also understand what it takes to keep their attention. There is a way to handle this without alienating more mature demographics as well. The solution is: Write concise statements. Aiden will understand phrases like "Move clockwise around the board," "Roll the dice and collect a card," or "The first to the end wins."
And just like that, you already have a pretty concise idea of how our game works and what it takes to progress and wind. There's obviously some more nuance to the design, including interactions between players and some income tracking, but otherwise it's a fairly simple concept that should give no player a hard time understanding it.
Is it possible to balance a race?
Our other pillar of design is Fairness. Aiden, like most of us, are playing board games to have some sort of fun. As the designers, our goal is to ensure that fun is kept high and consistent. Aiden can start a game with some friends and be hit with sabotage and attack cards while consistently rolling low. He's behind and being picked on. If I were in Aiden's shoes, I wouldn't be enjoying myself. Much less, I'd have no idea what the game is trying to teach me. The goal of the the Fairness pillar is to make it so each player never feels like they don't have a chance to play or do something. We seek to eliminate the described situation for Aiden. Our game is structured like a race where you gain benefits/hinderances based on the space you land on. You can also spend points to supplement these effects. We're using the beat map described in the previous Dev Log to break down the best ways to map out the board from a space to space basis. Where each negative and positive exists is crucial, the goal is to ensure that no one gets too many beneficial effects sequentially, while ensuring the opposite doesn't happen either.
On top of this, the sabotage cards were changed to be playable on any players turn, rather than on just the turn of the player who owns it. We felt that giving each player a chance to act and strategize while they were waiting for each other's turns to finish was a great way to emphasize Fairness. All in all, it looks very possible to balance this race-like game.
Conclusion
With Aiden Tremblay as our focus, it's easy to understand and create scenarios that we want to either construct through our design, or avoid entirely. We know what Aiden is thinking and what Aiden wants, allowing us to use him as the user to center our designs around. The pillars we've constructed help emphasize this by giving us guidelines to criticize contributions and changes through.
Game Practice Dev Logs
A recap and debriefing on game design lessons I've learned in this week.
Status | Prototype |
Category | Other |
Author | MisterSpectre |
Tags | design-practice, development-log, dev-log, game-practice, info, information, journal, solo |
More posts
- Dev Log 11: Post-ProductionApr 04, 2022
- Dev Log 10: Planning and ImplementationMar 21, 2022
- Dev Log 9: Playtesting and Production IIMar 11, 2022
- Dev Log 8: Playtesting and ProductionFeb 15, 2022
- Dev Log 7: Pre-Production PrinciplesJan 30, 2022
- Dev Log 6: Learning Reflection - How will this prepare me for next semester?Nov 26, 2021
- Dev Log 5: Scheduling My WorkNov 19, 2021
- Dev Log 3: Beat MappingOct 22, 2021
- Dev Log 2: Project ProposalSep 30, 2021
Leave a comment
Log in with itch.io to leave a comment.