MAYA Design, Inc. | bishop@maya.com
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 system—the 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 existed—ones 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 necessary— that 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.
Shifting Complexity 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 [ 1]. 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.
[ 1] See: http:// www.470. org/ for more information on the International 470.
References:
Archives