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…
Simplicity 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)
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.
You misspelled “Maeda.”
It seems that it is challenging to create devices that look simple to the customer and are in fact simple to use. I have a feeling that most people that are not familiar with usability and design believe that a device with fewer buttons is easier to use and is less intimidating. Well, it is true in some cases, consider an IPod. In many other cases a few buttons mean several modes (as mentioned earlier by the author), which can be tricky. I am just thinking that would be interesting to test user perceptions by presenting interface with the same functionality but with different number of buttons (interface with few buttons would be actually harder to use). The users should respond just by looking at both interfaces without using them. Maybe, the findings would show that simple interfaces are deceiving but customers are willing to buy them because they look simple and slick.
First I’d like to say that simplicity is really nice and helps usability and adoption of a product.
But, the unfortunate thing is that product teams and development are often run by people who try to compete on features, and ultimately in order to build a better product you keep adding stuff. Examples:
MS Word. OK I think it’s BIG ENOUGH now. Stop adding more menu items!
Yahoo! Finance: Are there enough links on the nav bar yet? Is there enough content on the page? Why not stuff some more and we’ll be better right?
An AIWA Walkman clone I owned: It had literally 20 extra little buttons on it, ranging from auto-reverse to selecting the type of tape (ie. Chrome, Metal, etc.). I just wanted to press play and stop!
The problem with adding features is that in the easy sense, you end up increasing complexity and reducing usability. A harder challenge is to add functionality but make a product SIMPLER.
Note that I change my wording from “features” to “functionality”. Features, to me, seem like more discrete things added. Functionality, to me, means the product gets more powerful in a more overall, holistic sense.
That leads to potentially reaching a limit on the amount of “features” a product can have, and definitely a limit to the value of adding yet another button, or menu item, or the 51st link on a nav bar of 50 links. A new solution is called for.
I think Abstraction and Experience Overall are two possible solutions. Abstraction in the sense of rising above the inidividual features and looking at higher level ways to think about the task(s) in different ways. Experience Overhaul means just that; you may (painfully) need to scrap everything and just start over and reorchestrate the user experience and design to contain all the things you know people want to do, but start from the ground up to make the whole thing simpler.
Simplicity is the ultimate sophistication.” – Leonardo da Vinci
From my experience complexity sometimes is due to the customer. @David: Sure, Microsoft does add features and features and therefore makes the application more complex. I’ve developed an Excel-Access based application that did one thing very good. It was simple. However, I was asked if it could do this and that. Then I did implement some additional features but not all because they would have made it a lot harder to keep it simple.
To me, keeping someting simple starts with the feature list. Reduce it as much as possible and stay focused. I’d rather have 4 apps each doing one thing perfect that 1 doing 4 things acceptable.
The problem here is mistaking Simplicity for Clarity, something Richard Saul Wurman has been distinguishing for, what, 20 years? Simplicity is about limiting data, information, and choices. This is, usually, counter-productive for true understanding, especially for experts. Simplicity is probably only relevant for absolute novices. Most of the time, we need more clear information and choices and it is only because most people lack the necessary organizational, verbal, (and often) visual skills to make things clear that cutting out choices is usually the direction taken. For designers of all stripes, simplicity is a mistaken approach, and often one that leads to poorer solutions and offerings, not better ones. For example, practically no one today would be happy living a simple life. However, almost everyone is striving toward a more clear one.
Also, if there is a “simplicity party” at all, it certainly didn’t start last year.
who said, simplicity is only for insects. what did I say, simplicity is not the issue , the issue is utility. Things are made (rather marketable things) are developed not because they are simple, but because they are useful. Moreover simple is only an abeeration . Look at a car. We only press a lever and the car zooms, but look at the grind, and the slime, and the oil well, and iron ore mountain that made the car possible. We don’t want simple or complex lives, we want useful lives. So utility is is. http://www.searchbox.mobi
The question that Tannen is ultimately posing is: “simple for whom?” Apple Inc. is often lauded as being makers of “simple” (and the cognate “elegant”) software and hardware. Yet, as any Mac fan knows, (at the best of times) the product is only simple from one perspective, typically the lowest common denominator. Crack open the Terminal in OS X and the experience becomes decidedly not simple, but that is the point. Power users need “advanced” features, and this requires a tradeoff of simplicity (although even here there are ways of improving the situation). This same problem occurs in the LIS world when journal database vendors offer a variety of search interfaces: simple, expert, advanced, etc. This is a design feature that is too infrequently implemented—its a sort of “mode switching”. Azureus, the Bittorrent client with its own problems (Java application? Ugh), effectively uses this principle of mode switching. I happen to be a “simple” Bittorrent user, since I mostly leach (and share), but I never create torrents or use special BT trackers. The interface is thus very simple. Mode switching like this should become common, since it doesn’t slow down any legitimate power users, but gets the newbies rolling quickly. There are also other ancillary benefits: segregating the processes can be more cost effective. For example, why have a $50,000/year ALA-accredited librarian standing behind the circulation desk? This is never done because the sorts of tasks that occur at the circulation desk can be easily handled by an $8.00/hour student. Its common sense, but when the design principle is kept in mind its effects are wide-ranging. More is said here: http://iqdupont.com/blog/?p=116 .
In _Envisioning Information_, Tufte wrote, “to clarify, add detail” (p.37). I’m a great lover of the notion of simplifying things (posters, traffic configurations, web pages, apps, radios) to make them more useful and more usable. So this comment from Tufte really grabbed me. It has probably made me think more than any other Tufte comment. I keep it mind when I am advocating to simplify a page by removing features or details. It makes me think critically about when it really helps to strip away. Granted, I may not be able to provide the data density and the micro/macro that Tufte loves about something like the Vietnam Veteran’s Memorial, but it’s good to remember that _it depends_.
I also think Norman’s notion that complexity sells has some power to it. Maybe this is related to our “reptilian minds”?? The reptilian mind recognizes that people say they want X (appeals to cortex) but in practice seek out Z because it speaks to their reptilian mind. So, you can’t just listen to what people say.
Can I spin this back around to Norman who points that people will buy the gadget with more features (complexity)? Sure, even if people buy the more complex thing, it doesn’t mean they like using it or can use it more effectively. So (1) recognize the reptilian pull and design for it on one level (to get people into your product) but also (2) understand what makes for the actual best user experience once inside the product and give that to them. There may be appearances of complexity at play alongside carefully designed simplicity.
Whoa, I am giving myself a headache…. Now if I can only show how this relates to Tufte’s comment that I started with: Maybe it’s the balance/relationship of the macro/micro readings at work.
How would Michael Hartmann explain the current trend in cell phones – cramming more functions in a handheld device that must maintain a small size – and be very successful at that. I say successful because if they were wrong, consumers wouldn’t be buying their products in hundreds of millions around the world. @Michael: “I’d rather have 4 apps each doing one thing perfect that 1 doing 4 things acceptable” is the way I used to think just a few years ago. If we followed this principle, I would have to carry 4 separate devices as soon as get away from my “base” location. Few years ago, I just wanted a good “cell phone” so that I could make and receive telephone calls – simply. But today, I can do that with with a smartphone and listen to hi-fi music, take very decent pictures, have my contacts, calender, to-do; get my emails, and even surf the web. The available technology allows more functionality to be added in a way that is simple to use.
My point: How many “things” one can add to an “app” so that the “app” does all those “things” well and and yet remains simple depends on available technology and its general acceptance by the public at large.
PS: I just discovered this site and am excited to be part of this community.
I don’t think it’s a matter of the semantics of what we mean by simplicity. Robert’s point seems clear; “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.”
Simplicity/Complexity is an attribute that is best determined empirically. An evaluation of context/activity/tasks/goals should inform the distribution of functions represented in the user interface.
Research may indicate that, If the context is selling DVR’s, perhaps aesthetics, or maybe, the reptilian brain may account for shoppers’ initial reactions to the user interface. Ideally, the designer will seek, through iterative testing, an interface that appeals to shoppers’ desire for a technologically sophisticated looking interface while maximizing the usability of the DVR (see Thompson’s comments above).
Likewise, If the context is the control room of a nuclear power plant, then research may show that the novel event is a critical variable to consider in the design of the interface. In this case, the designer will seek, again through iterative testing, displays and controls that allow the operators to recognize and diagnose novel events.
P.S. I think Robert meant Fitt’s List, which can guide function allocation decisions.
the wii is a great example where simplicity can hurt rather than help. Nintendo tends to think that everyone who picks up their controller knows that “waggling” is a type of control input, but in my experiences most do not. So all they see is the giant button A, yes it works in most games, but in fighting games for example it really confuses people. Especially the ones who are used to a multi-button layout.
Can you elaborate more on the following statement: “In software design, redundancy is inexpensive”, because I’m afraid that you have no idea about software engineering.