ThinkFlood Blog

Following along with the arguments that favor minimalism, we can see how automation improves usability. Specifically, automation alleviates the problem of subjectivity by reducing the amount of consumer interaction. In addition, automation also improves usability by eliminating (or at least reducing) repetitive actions, and it can reduce the possibility of human error.

Some of the best systems are highly automated. For example, we can think of utilities (gas, water, electricity, telecom) as “automated” delivery systems — at least from the consumer perspective. In most cases, the purpose of computers, appliances, and other machines is to provide automation, and it is clear that our lifestyle and culture have benefited from their introduction.

Because automation addresses some of the same issues that minimalism addresses, we might be tempted to conclude that automation is nothing more than a special case of minimalism, not significant enough to qualify as a principle in its own right. However, I believe that while minimalist design and automation both address similar problems, there is a fundamental difference in approach that justifies separate treatment. The crux is that while automation seeks only to minimize an interface, minimalism actually questions the inclusion of the feature itself.

From a usability perspective, this difference between minimalism and automation may seem trivial. After all, automating a feature can reduce the interface as much as eliminating the feature altogether. However, in my opinion this is a dangerous argument. If we believe that automation allows us to add features without any increase in the complexity of the interface, we will be inclined to add as many features as we can, so long as they are automated. In other words, automation can entice us to reject minimalism.

If automation really allows us to add features without increasing interface complexity, then why not do so? The answer is that, in practice, automation rarely comes free. In fact, sometimes automated tasks have the most confusing and complex interfaces, because the action taking place is at least partially obscured from view.

A familiar example makes this clear. Cruise control has been available for many years now, and the interface seems fairly stable. There is generally a button to turn the system on and off. A second button sets the cruising speed, a cancel button releases the system back to manual acceleration, and a fourth button resumes the former cruising speed after a return to manual acceleration. There are also buttons to trim the cruising speed down (the deceleration button, usually the same as the set button), and up (the acceleration button, usually the same as the resume button). Finally, tapping the break has the same effect as the cancel button. Phew.

Now let’s consider what cruise control replaces: a single control, the accelerator pedal. We push the pedal toward the floor to accelerate, or release it to slow down. The farther we push the pedal, the faster we accelerate. The direct method of controlling acceleration is significantly more simple and easy to use than the cruise control system.

The issue here is that cruise control cannot completely automate control of the car’s speed; it is not an auto-pilot system. While some luxury cars offer more advanced versions of cruise control that use lasers or sonar to ensure a safe distance between us and the car ahead, these systems do not relieve us from the task of monitoring our speed or relative position to cars and obstacles around us. As a result, they have to incorporate other controls (such as cancel, resume, and accelerate) that allow us to make adjustments as necessary. In fact, it seems that the only real benefits of cruise control are that we do not have to check our speedometer to verify that we are driving within the legal limit, and that we can reduce fatigue by taking our right foot off the accelerator pedal to move our leg about a bit.

Don’t get me wrong — I rely upon cruise control when I have to drive for more than an hour or two at a time. Fatigue is a real issue, and every little bit of freedom to move about or to focus on the road (rather than the speedometer) helps. However, this “automation” actually makes the driving interface significantly more complex – enough so that I often leave cruise control off when driving a rental car.

The moral of the story here is that we have to be careful when we choose to automate a feature. Automation is not an excuse to add a feature that we would not have included otherwise. That is, we must stick to minimalism, the first principle of usability. However, given a feature that we plan to include which also offers the possibility of automation, we should consider this option.

I believe that there are two types of automation. The first (and most user-friendly) is the “set and forget” type. With this kind of automation, we configure a few options (even better, the options are well-known and pre-configured), and then the program or device chugs away without any real need for us to babysit the process.

The second type of automation is more like cruise control: it exists to reduce the amount of tedium or fatigue that we would experience through repetitive or sustained interaction with the product. Unfortunately, this type of automation often requires continued monitoring and may not reduce the complexity of the interface at all.

If automation increases the complexity of an interface, we need to determine whether the automation benefits outweigh the potential confusion that complexity will bring. With “set and forget” systems, the answer is often yes – because even though initial setup may require an expert or a few extra minutes of consumer time up front, the payback will come quickly. With fatigue-reducing systems, we may have a harder time justifying the automation — which may be a clue that there is a more fundamental flaw in the product design.

Automation is a great timesaver and can make a product truly worthwhile, but only if the product works as it should (reliability) and does not destroy or corrupt data (preservation).

So, the bottom line on automation is that once we have decided to include a feature, we should explore the possibility of automating it. Particularly if we can design the feature as “set and forget,” we may be able to streamline the interface significantly.