Random Acts of Architecture

In 2005, Robin Hunicke, Marc LeBlanc and Robert Zubek wrote an academic paper titled “MDA: A Formal Approach to Game Design and Game Research“. It was and is an influential attempt at quantifying game design and theory.

The “MDA” acronym stands for “Mechanics, Dynamics and Aesthetics”. Mechanics refers to the algorithms and data structures that drive the game, such as how running characters animate or the arc of a character’s jump. Dynamics refers to the run-time interaction between the mechanics and the player, such as the pressing this button to jump or showing the character’s health as a bar at the top left of the screen. Aesthetics refers to how the player enjoys the game and what the player gets out of the game.

Aesthetics is often the hardest to describe to non-gamers. Some games may offer multiplayer where players enjoy the social and competitive aspects, like the an online game of “Call of Duty” or “Doom”. Other games offer an easy way to pass the time, like “Angry Birds” or “Candy Crush”. Others provide intense challenge, like Chess. Most games focus on a few core aesthetics and this is reflected by the difference audiences for each game.

As the paper points out, game designers and developers approach games from the mechanics side then dynamics, which hopefully impart the desired aesthetics. Game players, however, experience the aesthetics through the dynamics. Outside of statistic-heavy role-playing games and sports simulations, players rarely encounter the mechanics. Game designers should always keep aesthetics in mind, if possible.

Recognizing different layers and viewpoints gives game designers a nomenclature for understanding games’ inner workings and highlighting shortcomings. For example, a game aimed at a social aesthetic needs some form of multiplayer or social network integration. A game aimed at competition needs a visible score or ranking and consistent, well communicated rules.

How does this relate to enterprise software? The MDA framework layers have equivalents. Mechanics refers to the code and database queries software developers create along with business processes. Dynamics is unchanged, referring to user experience and interaction with the software. Aesthetics refers to the business value.

Also like game design, enterprise software customers and users approach the benefits the opposite way to software developers. Like game designers, software developers tend to start with the mechanics and work up to dynamics. Management aims for the aesthetics and, for those that directly use the software, the dynamics. While some software developers may enjoy the technical challenges of enterprise software, they must not lose focus of the business value.

As with any classification or taxonomy, the MDA framework provides a way of dissecting and comparing different applications. For example, two applications can aim for the same aesthetic (business benefit) but use different dynamics (user experiences). One might be a touch-heavy mobile application. One might be a web site storing its data in the cloud.

The MDA framework can point out where a business need (aesthetic) is not supported through user experience (dynamics) or a user experience does not relate to any of the defined business needs. Software developers and architects could also create a reusable mapping of dynamics to aesthetics or mechanics to aesthetics, like linking tactics to quality attributes.

Software developers have traditionally split systems into different layers or components. The aim was to improve maintainability by localizing the effects of changes. However, the MDA framework reminds us that changes in one layer can and do affect other layers. For example, a database query change (mechanics) may affect the results shown in the UI (dynamics) and the business value (aesthetics). Conversely, new or different aesthetics may require changes to both dynamics and mechanics.

The MDA framework also reminds us of requirement compartmentalization. For example, problems occur when management or business users specify dynamics (user experience) instead of aesthetics (business requirements). Management and business users should have opinions and input but user experience designers are experts.

With the increasing popularity of IT consumerization and gamification, game design has already encroached on enterprise software. The MDA framework goes deeper by identifying things important to the target audience (whether they be games or management) and a structured way of providing them. The fact that a closely related field has also produced something similar to existing software architecture and design best practices reinforces them.

Indeed, despite the fact that games are also created with limited time and resource constraints, enterprise software has a poor record of user experience design. There is probably a lot more game designers can teach software developers about improving enterprise software, considering games succeed or fail purely on their ability to satisfy users.