Simple Isn’t Always Better

A common requirement that I see when reviewing user requirements documents is that the system should be simple. First, stating that the system should be simple is not a valid user requirement, and second, simple is not always the best design.

The entire console of a nuclear power plant can be reduced to a single display indicating if the system is healthy or unhealthy, and a button to toggle between turning the plant off and on. This is clearly a simple design, but it does not provide the user with sufficient information and control to perform their responsibilities. Rather than designing for simplicity, some consideration should be given to designing complicated systems.

In simple systems, the user senses the state of the world, categorizes the situation and selects the best response. For example, you walk into a room, detect that the room is dark, and respond by flipping the light switch. Simple behaviours are quick because the responses to the situation are trained to occur almost unconsciously, known an automaticity. Automaticity frees up your attention for other activities which is fine for routine situations. However, simple systems can lead to complacency which can result in failure in an abnormal or non-routine situation where a different response is required.

We can reduce errors from automatic behaviour by creating systems that are complicated. Complicated systems require users to sense the situation, analyze and select a course of action. Having the user to analyze rather than simply categorize the situation, means that the user is paying more attention to the information present and surrounding events, and is at a higher level of arousal. The Yerkes-Dodson Arousal model, see Figure 1, demonstrates that with increasing arousal, users will achieve higher task performance, up to an optimal point before arousal gets too high and results in poor performance. Complicated designed systems will encourage users to perform in a state closer to optimal arousal.

Figure 1: Yerkes-Dobson Law of Arousal

An example of the difference between simple and complicated systems is the design of road intersections. In North America the 4-way road intersections are typically managed through traffic lights. Users simply need to sense the light and choose an appropriate action (green = go, red = stop, yellow =?). Most of the time the system works, but then there are the times where a driver is distracted by their cellphone, or not paying attention, and they run a light, or don’t go on the green which slows traffic flow. The introduction of the roundabout made the intersection more complicated, by forcing the driver to pay more attention when entering and exiting. The result is fewer accidents and higher traffic flow. In Europe, they’ve gone a step further because roundabouts are common and suffer some degree of automaticity. They now have the “Magic” roundabout, which consists of 5 small roundabouts nestled in a larger roundabout, see Figure 2. While it looks incredibly complex, the magic roundabout works really well, and first-time drivers, while initially nervous, are able to reach their desired exit with little difficulty. By having drivers pay a little more attention to what they are doing and what is going on around them, you improve the performance of the system.

Figure 2: “Magic” roundabout near Swindon UK 

So how do you make a simple system complicated? Well, the first thing you need to do is determine if the design needs to be complicated. If all the possible outcomes from making an error on a simple task pose no serious dangers, safety or performance wise, then simple may be sufficient. Otherwise, if you need your users to perform their tasks with more attention or diligence, you need to add friction to slow them down. Friction can be in many forms. A task may require a user to navigate around a lock-in or lockout behaviour to complete a task. For example, forcing pilots through a checklist prior to departure reduces the chance of missing any details that will impact performance, and prevents impulsive behaviours.

The objective is to identify the type of system that works best for your situation.  Don’t always assume that the simplest solution is the best. Users may react and make decisions quicker, but if the decisions are wrong or lead to errors, then it would be better to spend a few seconds more and to ensure the correct outcome.