Simplicity: The Distribution of Complexity

by:   |  Posted on

A note
Apologies for my late arrival to Simplicity’s party, but I’ve been pretty busy and I had to work late. The simplicity party has been going on for almost a year, and maybe that explains why it’s been turning ugly lately. Apparently, one of the guests (Don Norman, no less) insulted the guest of honor by suggesting that Simplicity is overrated, and stirred up quite a lot of controversy. But like many things, Simplicity isn’t overrated; it’s just misunderstood. Let me explain…

book: law of simplicitySimplicity didn’t get so popular on its own merits. It really came on the scene last summer—promoted by none other than MIT professor and renowned designer John Maeda in his book The Laws of Simplicity (Simplicity: Design, Technology, Business, Life). But simplicity has never been simple. In my review of Maeda’s book, I praised The Laws of Simplicity for focusing on the subject of simplicity in design, but noticed it failed to represent its own principles effectively. The book itself is an artifact of forced simplicity, with form taking precedent over utility. For example, Maeda intentionally limits himself to exactly 100 pages, to describe exactly ten principles of simplicity. Was it just convenient coincidence that there are ten principles worth discussing—not eight or thirteen?

The book, like many other modern products, was engineered to be simple through a set of pre-defined parameters (number of pages, number of topics), likely prescribed at the outset. Defining a framework upfront is one way to constrain a design to try to avoid complexity, but it is not sufficient. Rather, true simplicity is determined by a set of decisions made during the design process that respect the nature of the subject being designed.

Distributing complexity in the system

The flaw with the simplicity/complexity controversy is that it gives the impression that designers are making a binary choice – but simplicity and complexity are not polar opposites. In fact, making something “simpler” is often a case of relocating complexity, rather than eliminating it from the user-technology relationship. For example, from the driver’s perspective, a manual-shift transmission is more complex than an automatic transmission. But from an overall systems perspective, the automatic transmission is equally or even more complex.

Similarly, simplicity may also be realized or distributed in different ways in a user interface. Consider the classic “breadth vs. depth” choice in information architecture. Information may be organized in a broad, but shallow arrangement, with many choices initially available; or narrowly, with limited choices initially available, but accessible through deeper navigation.

In the broad approach, simplicity is achieved by quick access to visible choices, with a limited number of clicks—in a sense this approach is mechanically simple. Conversely, the deep design achieves simplicity by limiting the number of choices available at any one time. There is less visual scanning required to review choices, and, arguably, less cognitive work required to differentiate and select from among the available choices—it is perceptually simple.

So, given a fixed set of elements (e.g. navigation choices), there are multiple attributes of simplicity than can be addressed to varying degrees. The success or failure of a design is largely dependent on achieving the right balance among these attributes of simplicity. An infamous example of this was BMW’s i-Drive controller, designed to operate a range of automotive systems from a single control. The resulting user experience was confusing and complex as BMW relied too much on mechanical simplicity (a single, clickable rotary control) at the cost of perceptual and cognitive simplicity.

Distributing complexity in the design process

Producing a simple design is challenging. Despite the online debates about the value of simplicity, the real simplicity/complexity controversies occur during the design process, with concern over where to place complexity in the user-system continuum. A user interface solution that thoughtfully places complexity on the system side, rather than the user side, is typically referred to as “simple.” To get to such a solution, the design team will need to deal with issues of complexity, rather than leaving it to the end-user of the resulting product. “…making something ‘simpler’ is often a case of relocating complexity, rather than eliminating it from the user-technology relationship.”

So how does a designer or design team address complexity in the design process? And what guidelines are available for figuring out where to place complexity? Fortunately there are methods to help determine how to allocate functions between people and machines. Fitt’s Law, for example, has been a standard human factors tool for over 50 years, guiding the allocation of tasks between people and systems. Ultimately, design decisions need to be resolved through research methods as well as known principals.

The following examples suggest how design decisions can be resolved through analysis and user evaluation:

Unique vs. Redundant

In software design, redundancy is inexpensive, but in product or environmental design, surface area and space are bound by more costly physical limitations. Therefore, the decision of whether to place a functional control in a single, fixed location versus multiple access points is critical. Typically necessity and/or frequency of use relative to available space is a guideline for making such decisions. Providing multiple control access points can make things easier – for example, some cars offer redundant steering wheel controls for ongoing tasks such as changing radio volume and channel selection. Task analysis methods, which can measure the frequency, sequence, and relationship amongst tasks, are essential for informing such decisions.

Dedicated vs. Multi-Function

In many cases, a single control will be asked to serve multiple functions. Typical clock-radios have buttons that change based on mode. The “+” and “-“buttons may be used for tuning frequencies in the standard mode, but alternate to change the time in time-setting mode. As a rule of thumb, the modal/multiple function user interface is more complex to learn and use, but is widely applied due to the relative infrequency of secondary tasks such as setting time. Compact clock-radios with multiple sets of incremental controls dedicated to different purposes are complex-looking, and often lead to errors of commission when users select the wrong type of control. Comparative usability testing of various control/mode configurations would inform whether additional, dedicated controls improved performance and perception of the product. (Anecdotally, Sony has a clever design with a dedicated toggle for daylight savings mode. Seemingly unnecessary relative to its usage, but placed discretely enough to not interfere with everyday use.)

Fixed vs. Adaptive

Both digital and mechanical interfaces have the capability to conditionally hide or reveal controls and information. Interfaces that utilize this capability to support the user are referred to as adaptive. For example, a cardiac monitor may display several detailed biomedical parameters during normal cardiac functioning, but displace those in favor of limited, but high visibility critical information during alarm conditions. Adaptive interfaces are among the most challenging to design properly as, by definition, they proactively alter the familiar. Ironically, the act of simplifying the user interface to support immediate conditions may complicate the experience for the user who must re-orient him or herself to the system. Achieving a balance between disruption and benefit requires careful consideration, analysis, and testing. Eye tracking is a useful tool for assessing adaptive interfaces, enabling measurement of where users look during the re-orientation step when interfaces change, and determining appropriate display designs.

Maeda succinctly writes, “some things can never be made simple.” This does not mean that things cannot be made simpler.These are just a few of the types of decisions that may be made during the process of creating a design solution. While we may set out to design a “simple” system, it is shortsighted to force it when it may not be appropriate for the end-users or the tasks. Applying user research methods to guide design decisions will assist in the appropriate balance and placement of simplicity in the product, and the exposure of complexity to the end user. Tackling these issues during the design process is the best approach to displace complexity from where it would otherwise end up: the users’ experience.

Finally, one must also concede, as Maeda succinctly writes, “some things can never be made simple.” This does not mean that things cannot be made simpler. But the complexity of many advanced technological systems is frequently addressed beyond just the user interface. For example, balancing complexity by dividing responsibilities among multiple users, or limiting the amount of time an individual can operate on a system to minimize the risk of errors are cases in which complexity is spread out over people or time, rather than contained within the user interface.

So the next time you face a product that’s not easy to use, don’t assume that the designers didn’t consider the problem of its complexity—they may have just disguised it, hidden it, or moved it around. While simplicity is extremely attractive, she can be tricky to get to know.

Well, it’s been fun chatting, but I just heard that Vista is throwing a party—a big one with an open bar, no doubt.