Everyone can agree that people love playing games! One of the earliest games created is Checkers, first invented over 5,000 years ago, and still going strong today!

Yet, despite the apparent differences between Checkers, Baseball, or even Angry Birds, all share the same game principles of Mechanics, Interaction, and Experience.

Design Systems also share these principles. Understanding how to leverage Game Design in your Design System helps adoption and scalable growth in the future.

Unlike style sheets or simple pattern libraries, Design Systems have Mechanics, Interaction, and Experience whose purpose is to prevent Inefficiency, Inconsistency, and Invisibility from creeping back into the product and becoming a new version of chaos that it had been created to replace.

Leveraging the discipline of Game Design into Design Systems, we are empowered to create an environment that enables everybody can play together for a common goal and realizes the ROI of the Design System as originally envisioned.

What is Game Design?

Game Design draws from a wide variety of fields such as graphic design, psychology, programming, probability, creative writing, as well as user research. Game designer Robert Zubek divides the discipline into three distinct categories.¹

Mechanics

The most fundamental feature of any game is Mechanics which are the objects and rules of the game.

If you’re a fan of baseball, you probably recognize the basic objects and rules of the game.

OBJECTS

• Baseball
• Bases
• Playing field

RULES

• Two teams play against each other
• Nine players per team
• Nine innings per game
• Three strikes and your out

Just like Baseball, Design Systems have objects and rules. Design System objects are what the players useto combine objects into more complex components such as buttons, input fields, and dialogs.

OBJECTS

• Typography
• Colors
• Icons
• Spacing

RULES

• Navigation bar always placed on top
• Buttons are aligned bottom-right in container, always ordered secondary, primary
• Input components states for active, hover, disabled are defined
• Spacing for padding/margins defined by existing space tokens.

As a Game Designer, your goal is to give your Design System players all the objects and rules they need so they can play the game confidently and effectively so they can have the best Interaction and Experience possible.

Unique Challenges of Design Systems as Game Designs

While Design Systems share much in common with games, there are unique challenges which the designer needs to be aware of to design their game properly.

Consider a game of Monopoly and the connections and objectives of the players. From a user-centric perspective, there are alignments that aid in creating an easily playable and enjoyable experience for everyone involved. Association, Interaction, Language, Rules, and Objectives.

Monopoly Game Alignments

1. Association: Family, friends gathered in the same location.
2. Participation: All players participate the same.
3. Language: Players able to communicate effectively/effortlessly.
4. Objectives: Social interaction/fun.

In the game of Monopoly, we see the players are closely associated, participate the same way, speak a common language, know the rules and share a mutual objective. These alignments are high, which helps create a fun and enjoyable experience for all players. But what about the Design System game?

Design System Game Alignments

1. Association: Coworkers often working in different disciplines, departments, locations, and time zones.
2. Participation: Designers use design tools (Figma, Sketch, etc.). Engineers use code (web, iOS, and Android). Each interacts in a different way.
3. Language: Designers and Engineers speak/think differently, creating a natural language divide.
4. Objectives: Often undefined.

Unlike Monopoly, the alignments of the Design System Game are typically very low.

Players are loosely associated and interact with different tools. They speak different languages, follow diverse rules, and often not aligned on objectives. Understanding that the long-term success of your Design System depends on bringing all players closer to alignment is crucial.

Design Systems are a very complicated game!

Largely due to poorly executed game dynamics and weak player alignments, businesses struggle to increase Design System adoption throughout the entire organization.

They may attempt to solve the adoption problem in several different ways. Some ideas include…

• Building a culture of shared ownership
• Reward co-workers with stickers and t-shirts for adoption
• Recognize contributors with certificates
• Inner-source (or Open-source) the UIKit/Code
• Make use of the Design System mandatory

Some of these concepts may have a positive effect, but if you approach the problem as a game designer you’ll see why these solutions are not sufficient.

Let’s say you’ve created a new board game and discovered it wasn’t selling well. How would you attempt to solve the problem? As the owner of the game company, you call your game designers into a meeting to brainstorm ideas.

“The game would be successful if we created a culture of shared ownership of the objects and rules.”

“The game would be successful if players received t-shirts, stickers, and certificates that recognized their participation.”

“The game would be successful if we allowed users to create their own mechanics, interactions, and experiences through crowd-sourcing!”

“The game would be successful if we pass a law requiring citizens to play the game.”

By thinking about the design system as a game design exercise, we quickly see these approaches are not going to get us to the goal we desire because none address the core issues needed to create a successful game.

The only way to know if your system will be successful is to observe how your users Interact with the Mechanics and measure their Experience.

Game Testing & Design Ethnography

Game designers play and test their game thousands of times, making them experts on the system they’ve built. But the real test happens when they closely observe new players and see how they interact with the game. This is called ethnography or ethnographic research, and it has several defining characteristics.

• Research takes place in the participants’ context.
• Participant sample sizes are small.
• Researchers aim to understand the big picture: participants’ needs, language, concepts, and beliefs.
• Artifacts are analyzed to understand how people live their lives and what they value.
• Data is ‘thick’, comprising written notes, photographs, audio, and video recordings.

During these sessions, the Mechanics (Objects, Rules), Interaction (Language, Association, Participation & Objectives) are fundamentally tied to Experience. If the player is having a poor experience, the designer has an opportunity to discover how to improve the Mechanics and Interaction to make the experience better.

Putting it all together

This is a big task, but extremely important. You have to do your research to ensure you’re system is on the right track, and you have to continue doing it on a regular basis, ensuring you’re documenting thoroughly with notes and video recordings.

You have at least two different users. Designers and engineers working on different products with different technology stacks. As we’ve noted before, the alignments of all players are very loose, so everybody probably has a different idea of how the game is played. To maximize your chance of success, we need to look through both users' eyes.

Do the designers have what they need? Colors, Spacing, Typography, Icons, Components? Can they easily find where it is? Do they know how to use them? Do they know what the space between these components should be? Do the designs look consistent when multiple designers are creating similar views and workflows?

Can developers easily read the design specs on the developer handoff? Do developers have access to a UIKit that can be easily installed which contains tokens, typography, and components? Are designs utilizing the core token-driven specs, or are mystery values still popping up? Are new components being introduced into production where the DS already has them defined?

Most importantly we need to discover how the players felt about the Experience! Were they happy? Frustrated? Were they confident in making and executing design decisions? Did their participation easily map to their language, concepts, and beliefs? Was there any friction in their use of the system? Could the Experience be improved in future editions?

When it comes to designing games, everything is about the Experience. No matter how carefully the Mechanics (rules and objects) are crafted or how well the users Interacted with the Mechanics, it doesn’t matter if nobody is enjoying the game! Following the same discipline for Design Systems makes adoption and scalability much easier.

Though the scope of the task can be intimidating, observing both engineers and designers and following them through their process, including the developer handoff, many (if not all) problems can be identified in very short order. Some problems can be fixed quite easily, such as color tokens. Others may require more time and resources, but identifying problems is the first step to solving them and that is a big win.

Solving a problem before it becomes an issue.

Many first-time creators of a Design System make a common mistake. They define far too few colors to address the needs of all the products in their organization.

I see designers defining two shades and two tints of a base color, creating only 5 levels other designers and engineers are able to choose from. This seems a good idea at first, limiting the palette to its bare minimum to reduce mistakes, but it’s the quickest way to introduce entropy into the system.

Fortunately, the smallest amount of ethnographic research will find and eliminate this problem before it becomes an issue.

The iOS engineer will ask what color should be used in dark mode because his platform must support that feature. The designer will wonder what color they should use for his/her paper-white backgrounds. The web programmer asks what are the approved colors for rules, lines, and borders.

It quickly becomes obvious that five levels of neutral will not solve these issues. There needs to be more. Your players, left to their own devices, will begin adding more and more colors to satisfy their needs, often with an alpha value.

If this were a board game rather than a Design System, you would observe your players create a brand new Object in the Mechanics of the game because, from the users' point of view, the game was unplayable without it. Before long, the original five neutral shades explode to almost every imaginable shade possible. Chaos, once again, rears its ugly head!

But, by actually observing the behavior of the user in their own environment, we can easily see problems and take steps to ensure they do not become more difficult issues to solve in the future. As with any product or system, it is essential to understand your user. More importantly, understand that you are not the user!

Taking your ethnographic research, you go back to the drawing board and expand your color palette. Below is an example of a fully playable set of color objects.

Great! We now have plenty of objects to work with, but how do we communicate which colors should be used? Well, that’s the second part of Mechanics. We absolutely need objects, but no game is complete without a set of rules!

Imagine opening a new tabletop game with lovely playing pieces, a beautiful playing board, and shiny dice. It’s all very exciting until you discover the game is missing the rule book.

That is where a DSM or Design System Manager comes in. It’s the rulebook for how to use the design system. It should be easily accessible to anyone in the organization. ZeroHeight and Storybook are popular tools to share rules and documentation. Some organizations even choose to custom create their own.

For color tokens, I’ve found using a semantic-weighted naming convention is essential for defining core color objects.

As with any good rule book, we want to keep the rules as simple and understandable as possible. If we created a section to describe layout and typography, we’d see a collection of rules such as these.

1. Header text uses token $color-neutral-800 in light mode and $color-neutral-025 in dark.
2. Body text use $color-neutral-600 for light and $color-neutral-050 in dark.
3. There are three background tints. $color-neutral-000 (white), $color-neutral-025, and $color-neutral-050 in light mode. These are transformed respectively to $color-neutral-900, $color-neutral-800, $color-neutral-700 for dark mode.
4. Rules, borders and separator lines are $color-neutral-075 in light mode and $color-neutral-700 in dark.
5. All icons use $color-neutral-400 regardless of light/dark modes.

Now, that’s a lot of consistency in just five simple rules!

Another mistake I see with newly created design systems is thinking the token or component itself represents the documentation. Nothing could be further from the truth.

What if somebody handed you a baseball bat, a ball, a glove but you’ve never played or seen a game of baseball? The bat is simply one object used to play the game, but the bat itself does nothing to explain how it’s used in the context of the game.

Rules show you how to use the object to play the game. That is the importance of documentation.

While the Figma library and code UIKit should contain all the objects your players need, everybody still needs the common rulebook to play the game effectively. When you participate in your ethnographic research, you’ll quickly discover how important it is for your users to find answers to all sorts of questions, and with a DSM, you’ll have a single place to put all of those answers.

I hope you found this article helpful when creating your own design systems. Thinking about your Design System as a Game Design discipline, rather than a design or an engineering problem, offers natural ways to improve and expand your system and create a real ROI for the entire project.

Using Mechanics, Interaction, & Experience ensures you’re approaching the problem as a Game Designer would. The same strategy is valuable in almost any problem-solving exercise, but let’s leave that discussion for another day.

Let me know what you think.

References

[1] Press, The MIT. “Elements of Game Design | The MIT Press”. mitpress.mit.edu. Retrieved 13 November 2020.

Let’s be friends! Follow me on Twitter and Dribbble and connect with me on LinkedIn. Don’t forget to follow me here on Medium as well for more design-related content.