As designers and usability experts, we have always claimed that we "tame complexity." What does that mean? Are we removing the complexity, rearranging it, hiding it, or resolving it in some other way? Depending on the situation, the answer is that all of these methods come into play. We remove, rearrange, and hide, but complexity never really disappears. Designing usable interfaces requires discipline to remove features in some cases, to organize others so they can be found and used, and to shift complexity away from users to more-appropriate places.
Is the complexity necessary? It often is. In many technologies complexity is the very heart of the power and functionality. An oil rig is a physical example of a complex systemthe structure of the platform must be rigid enough for production activity but flexible enough to cope with changing weather conditions. Another system in which complexity is necessary is the mail-routing software used by the U.S. Postal Service. The system must "read" zip codes and addresses, whether typed or written, through a series of optical scanners, and it must route the envelopes to their destination and deal with a variety of errors (e.g., no zip code, unreadable digits, etc.). When the complexity is necessary to the product, we don't remove it but rather focus on putting it in its place (hence the taming).
In consumer products the complexity often comes from "feature creep"the tendency to continually and liberally add new features but never remove or restructure the existing ones. If feature creep gets bad enough, the rare features get in the way of the routine tasks that users are trying to perform.
A few years ago we worked with a client who made automated mailing equipment. Their product had been in the marketplace for years, with additional features added each year to entice users to replace their version. As part of our design process, we used their customer-support call logs as a source of information about where potential usability problems might lie. The support calls for the product revealed a wish list for the product including features that were already present! Consider for a moment that the product was so complex, due to years of feature creep, customers were calling to request features that already existedones they couldn't find in the bloated design.
Feature creep is a well-known design problem. It's akin to software bloat, scope creep, and "the complexity trap" in software development. Although each additional feature may provide a benefit, each feature also clearly has a cost. Each new piece of functionality added to a product competes for the user's attention. While a new feature may produce a marginal functionality gain, it may also create a more widespread usability loss.
In mature products or difficult situations, it is possible that the complexity is necessarythat key functionality has been achieved through the inclusion of many controls, adjustments, and functions. In this case a careful rearrangement of the features and functions based on users' needs is called for.
How can the complexity be tamed without reducing the utility of the product? Consider a racing sailboat, with many lines, blocks, and cleats necessary to control the shape of the sail. The International 470, an Olympic-class sailboat, has halyards, a vang, a cunningham, a mainsheet, jib sheet, spinnaker sheet, an outhaul, a traveler, a topping lift, and so on . Each "feature" controls a different aspect of the boat's performance: The halyard is used for raising the sail and allows you to shorten sail in high winds, the vang provides control over twist, and the cunningham allows the users to move the center of effort of the sail.
Now consider another alternative, a sail configuration called the transition rig, invented by Richard Dryden . The transition rig is modeled after a bat's wing; it provides a series of joints and folds in a variable geometry that can adjust easily and automatically to changing wind conditions. Of course, the International 470 can also react to changing weather conditions, but it requires many individual control lines to achieve the same effect.
Although sailing with the transition rig is more straightforward, manufacturing it is not. The transition rig requires a rotating base and several complicated joints constructed from carbon fiber and stainless steel. Dryden identified a user need (ability to adjust sail shape) that was being met, but with a complex set of controls. He chose to focus engineering efforts on meeting the same need, but with a product that is less complex to use and operate.
What has happened here? Functionality remains the samethe sail changes shape to adjust to wind conditions. The complexity has been restructured in the transition rig's design: Dryden shifted the complexity from the use of the product to its design and construction.
In this case it's impossible to remove individual features (i.e., removing the vang would make controlling the twist of the sail difficult). The new design doesn't try to remove features or limit the functionality of the sailboat. In many cases, and for mature products, this is a desirable trade-off. Where the complexity provides critical functionality, it can be shifted out of the user experience into manufacturethus tamed.
Shifting the complexity away from the user and onto the system may be the best alternative to simply removing features. This shift can be accomplished through active automation (completing your taxes in TurboTax), system manufacturing (the transition rig), or simply a new design metaphor (archiving mail by conversations rather than dates). As computers get more powerful, materials more advanced, and methods more sophisticated, it makes sense to move more of the burden from the user to the product. This is true of all types of products, whether they are physical products, software, hardware, or even websites.
What methods can be applied to combat complexity? How, specifically, can complexity be "moved" so it's no longer a burden on users? How do we handle complexity at design time so it can be tamed once rather than having each individual user puzzle it out every time?
At a high level, the principles of human-centered design espoused in ISO standard 13407 are completely on target :
- The active involvement of users and a clear understanding of user and task requirements. By understanding what users need to do, designers can determine where to focus their efforts, which features to make prominent, which features to remove, and they can begin to determine navigation paths within a user interface that are aligned to the users' tasks.
- The iteration of design solutions. Nobody can burp up a perfect design on the first try; it takes a number of successive approximations, testing alternatives against one another, and a graveyard of failed attempts to design something worthwhile. Design concepts must be tested with users to see how they fare and to determine where changes should be made.
- Multidisciplinary design. Design of usable systems takes a variety of skills. Just as in the example of Dryden's transition rig, you can imagine that expertise in sailing, aerodynamics, metallurgy, mechanics, textiles and sail-making, even biology, is neededhis rig looks to bat wings for inspiration. User-interface and product designers must bring a broad range of skills to bear on a problem and need to collaborate with many other disciplines.
- The appropriate allocation of function between users and technology. People and technology are good at different things. People exhibit judgment but have quite limited short-term memory. It's stunning how quickly computers can perform calculations, but they're poor at recognition, error recovery, and dealing with incomplete information.
In the case of the mailing equipment, where customers were calling to request features that were already present, we were asked to step in and help rectify the situation. We had to take the system apart (metaphorically), organize it, and put it all back together again in a rational, organized fashion. We modeled the information structures visually to diagram the user's mental model. This information-architecture work organizes and summarizes the information space in which users must travel in order to complete their tasks.
Like any design process, the information-architecture work is iterative. We'll draw a representation and ask users and domain experts for feedback. Comments like "no, these two things aren't related," "you forgot X," and "the relationship should be stronger over here" are all clues that we're making progress toward a sensible organization. It's hard work, and it often requires immersion in a complex domain in order to understand the details and create structure. The individual features from the original design will be reordered, regrouped, and restructured to form a more usable, comprehensible product.
That's conservation of complexity in actionnot just reducing the number of features, but also reducing unnecessary complexity. The complexity has to go somewhere: The designers shoulder the burden of understanding and untangling it, making sense of it, and constructing a system that is aligned with users' understanding of the domain. As Leonardo da Vinci wrote, "Simplicity is the ultimate sophistication."
Imagine that there's a certain amount of complexity inherent in any task. Worse, the complexity is increasing as we use a bit of technology to bootstrap ourselves to a higher tier. Once a technology provides something that users didn't have before, we begin to extend that functionality as a means of continual improvement. First, we were satisfied to even have automobiles at all. Then we could worry about fuel economy, safety, and comfort. Eventually, we can tackle social and environmental concerns. As this inherent complexity increases, where does it reside? In the worst case, the burden will all be on the user, as the consumer of the product. This is the classic case of feature creep. There are at least two other more appropriate places where complexity can reside.
First, it's appropriate for a product to take on much of the burden on the user's behalf, especially as the product becomes more mature. Initially, we had to learn to pump our brakes if we needed to stop our car on a rain-slicked or snow-covered street. Now antilock brakes contain that complexity by improving on our abilities and allowing us to focus on other parts of the driving task. It's not that the need (short stopping distances on slippery surfaces) went away, or the complexity was removed (the physics of stopping a vehicle without locking up the wheels). The complexity was conservedthe burden shifted from the driver to the car.
Second, consider the process of design. A lazy approach is simple and straightforward from the designer's perspective: Design each feature individually, jam all the features in a single box, and call it a product. But now every user has to contend with the difficulty of using the thing. At best, it will be cryptic, confusing, and inconsistent, if not frustrating and unsuccessful as well.
The process of decomposing, understanding and reorganizing the system is a formidable weapon in our battle against complexityit lets us distill convoluted and intricate problems in order to make them understandable and manageable. Architect Christopher Alexander influenced a swath of designers and computer scientists with his work on design patterns and incremental improvement. He points out that "there is a deep and important underlying structural correspondence between the pattern of a problem and the process of designing a physical form which answers that problem ." He goes on to argue that the "number of factors which must fall simultaneously into place are enormous ," but that documenting the pattern of a problem is inextricably linked to developing a design solution.
The inherent complexity has to go somewhere, and it's the burden of designers to take on the complexity on behalf of users. Making sense of the intricate interrelationships between features and reorganizing them so they're rational is a critical task.
David Bishop is the director of the Human Sciences Group at MAYA Design, Inc. He has been an interaction designer at MAYA since 1996 and is particularly interested in the positive effects that come from having the fortitude to resist feature creep and the insistence to focus on features that users truly need. His first love is hands-on information architecture and user interface design work for MAYA's repertoire of clients; he has been extending that work to include training in human-centered design processes and measurement of organizations' usability maturity level. Previously, David was a designer of high-end project-management software at Primavera Systems, Inc. He holds a B.S. in applied mathematics and computer science from Carnegie Mellon University.
©2008 ACM 1072-5220/08/0700 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2008 ACM, Inc.