Paul Rezar is ExperiencePoint’s Creative Director and earlier this year he recommended an intriguing book, “The Laws of Simplicity” by John Maeda, a professor at MIT and founder of the  MIT SIMPLICITY Consortium.

Paul had read and even summarized the book for one of our weekly ExperiencePoint “Share” sessions. The ideas were – appropriately – simple and I made a note on my mental ‘to-do’ list to borrow and read for a deeper understanding.

Well, there’s a lot of mental dust on my mental ‘to-do’ list and it wasn’t until earlier this week (thanks to a 5.5 hour flight from SFO to IAD) that I finally followed-through.

In line with the theme of simplicity, Maeda capped his book at 100 pages. That’s it. I’m a slow reader and even I had plenty of time on my flight to go through the book once and then circle back to my favourite points. The book is structured as a collection of thoughtful essays on Maeda’s 10 Laws of Simplicty:

The basics:
1. Reduce – use thoughtful subtraction
2. Organize – make a system of many appear less complex
3. Time – save time to make complex activities feel simpler

The intermediate:
4. Learn – build knowledge to reduce perceived complexity
5. Differences – allow the complex to provide a reference point to simpler designs
6. Context – pay attention to what lies in the periphery of simplicity

The deep:
7. Emotion – engender more emotions
8. Trust – create trust with simplicity
9. Failure – allow complexity to exist where it must

The summation:
10. The One – Simplicity is about subtracting the obvious, and adding the meaningful

Clearly to understand the texture and nuance of these laws, you need to dive into the book itself. Viewing the laws from the perspective of simulation design, I found inspiration in his musings and examples. In all immodesty, there are a number of items EP is already doing exceptionally well :-).

There are also things for us to consider going forward as there are numerous ways we can simplify the user experience. Here are a few examples:

Illuminate the Path
Contrary to the orthodoxy of a free and democratic society, choice is not always a good thing! It can be particularly problematic when there is a defined or preferred user path in a game. Eliminating (Law 1: Reduce) the options available to someone when he or she first enters an experience is merciful and saves time (Law 3: Time). "The Paradox of Choice" by Barry Schwartz and "Stumbling on Happiness" by Dan Gilbert both suggest that too many options can prove frustrating and paralyzing.

In a game, there is invariably a gameplay process that users should follow. Typically in business games the pattern is first read this, then make this decision, then review and analyze this feedback, then make the next decision and so on. Variability and the availability of alternatives matter in a simulation game, but their importance is usurped by the need to have a simple, smooth introduction to the game universe itself. The question then becomes, how do you illuminate this path?

A common approach in software is to ‘grey-out’ buttons, which exist, but are not immediately relevant. This approach reduces complexity and shows a user the way without compromising the ‘full picture’ view of the game’s interface and functionality (which can provide subtle clues to where the game is heading). A pervasive example of this from the world of productivity software is Microsoft Word. In the “Media Equation” by Cliff Nass and Byron Reeves, we learn that Microsoft’s practice of greying-out was born out of social science research on how to make technology more polite!

A more extreme version of this reduction is the excision of all options not immediately relevant. New buttons appear in the interface at the moment their associated options become relevant. This approach sacrifices the initial whole picture view of the game, but it ensures the user is focused on the task at hand and not distracted by presently irrelevant functionality. This is extremely useful in single-user online game experiences where no facilitator is available to encourage the right focus.

A final way of illuminating the path is to present users with a visual that communicates their journey through the game (Law 3: Organize). The visual should map cleanly to the interface – by this I mean its pictures and text should be consistent with the options presented in the interface. Color-coding components of visual and interface is another means of communicating affinity and alignment. An added beneficial layer on the visual is a progress indicator that illustrates which parts of the journey are completed and which parts remain.

Warp Time
The concept of ‘Flow State’ as described by Mihaly Csikszentimihalyi (yes, I had to Google the spelling of his name :-) ) suggests that when we’re engrossed in a task our perception of time warps. Hours pass in what feels like mere minutes. The converse is that when we’re not yet engrossed (for example, when we’re told we need to wait for something to load) the exact opposite will happen – we feel like we’re wasting more time than we actually are.

Both of these perceptions can cause challenges for game designers although it is the latter issue that I will address here (as it relates to Maeda’s third law: Time). There are those moments in a game where a user is caught in the cracks between phases of play. In the case of our flagship game, ExperienceChange, users can feel like time is lost when they:

• Enter the product via our website and have to login, click ‘start’, and finally click ‘simulation’ in order to launch the game;
• Wait for the simulation game to download in their browser
• Wait for the simulation to load a saved game so they can continue playing
• Wait for the simulation to load the debrief report card for a past simulation game
• (In class) wait for team members to return from breaks so they can continue playing

We’ve managed the waits for the computer to process something via progress indicators. When a user downloads the simulation, they see the speed and size of download visually so they have instant certainty of the amount of time the process will consume. When a game or a debrief is loading, users see a steady count of the specific tactics (past decisions) being sequentially processed by the simulation…this also provides the user with confidence that the game she is loading is indeed the correct one. Maeda points out that progress bars create the illusion of time passing more quickly than it actually does. Moreover it assuages concerns that the system is disrespectful of a user’s time.

And to this latter point, demonstrating respectfulness can take other forms. In our facilitated sessions, we typically log in for participant teams before the workshop begins so that when they show up to their breakout rooms, the simulation is ready and waiting for them. Additionally the pre-loader (the progress bar screen) can prepare participants for their first decisions (e.g. in the case of ExperienceChange, naming their simulation game). This is a quick decision, but nonetheless helps users make use of the ‘wait time’.

Regarding the team experience and the inevitable delays caused by participants coming and going, a facilitator can call out this challenge at the beginning of the day and ask participants to agree on how they want their team to handle such situations. Would they prefer an “If you leave the room, we will proceed without you” rule, or would they prefer to jointly determine times when everyone can take a break.

As you’ve likely surmised, I’m merely scratching the surface on some of the ideas posited by Maeda. I look forward to further exploring the implications of these laws for game design.