Reducing Complexity while Maintaining Capability
Sure been a lot of debate recently about simplicity in technological products. Simplicity is good. No, it’s over-rated. No, under-rated, not that there aren’t other considerations. There’s an optimal level of simplicity-complexity. Sometimes complexity is good, sometimes simplicity is good. Complexity is simplicity.
Complicating this discussion of simplicity is that no one has defined exactly what is meant by simplicity. “Simple” is a vague term. It can mean “easy.” By this definition, a simple product means it takes few steps to do things and demands little cognitive effort. The user can learn that product quickly, and accomplish his or her tasks quickly. I don’t know about you, but that sounds like just another word for “user friendly.” Isn’t pretty much the goal of usability engineering to make products easy to use? Maybe the product is easy for novices or maybe it’s easy for experts, depending on your targeted users, but if “simple” means easy you can’t be a usability professional and be against simplicity. If “simplicity” is the latest marketing buzzword, and you get more attention for usability by using the word “simple” rather than tired-old “user friendly,” then go for it. But among usability engineers, calling a product “simple” in this sense is like a civil engineer calling a construction “sturdy”; it means everything and therefore nothing.
On the other hand, “simple” can mean “stupid,” as in “simple-minded.” A simple product means fewer features, where powerful abilities are stripped away or at least hidden, a dumbed-down boring product that won’t intimidate Aunt Tillie, but of course will have no appeal for anyone actually living in the 21st century. While there are people outside usability engineering who think that’s what we do, there’s hardly a usability professional who thinks it’s his or her job to make brain-dead products. To us, usability has everything to do with making highly capable, flexible, and efficient-to-use products.
What is Simple?
Personally, I’m going to take a pragmatic approach. I’m not going use the straw-man simple = stupid definition. I’m also not going to use the all-inclusive simple = easy definition, because we already know basically how to make products easy: follow human factors principles, apply usability tools, and conduct user-centered design. For details, see the usual textbooks.
I’m much more concerned about solving a more immediate problem out there. Our users are suffering. They’re complaining that technology is too complex, and it’s not just Aunt Tilly. They might be buying increasingly complex gadgets, but they’re also returning them. There is growing unrest, and if we designers don’t do something to address it, we may have an open rebellion with ugly mobs carrying torches and pitchforks appearing outside our respective windows. For self-preservation alone, we need to address their very real concerns.
What do users mean when they say technology is too complex? Near as I can tell, they mean technology has so much stuff that they are confused. The key word is “confused.” They mean “complex” in the perplexing sense. They don’t know how to use their products. They don’t understand why their products do certain things or fail to do other things. They can’t figure out how to turn off the ringer on their cell phone or why the ringer seems to have changed on its own. Somewhere in the web site they can get the weather for Chisasibi, but they can’t figure out the link out of the dozens presented that leads there. They know their mp3 player has an alarm clock, but they recognize they’ll never be able to remember how to use it. The problem we need to solve is the confusion that highly capable products bring. For the purposes of this post, I’m using the following definitions:
Complex: When the combination of numerous things causes user confusion.
Simple: Not complex.
Not the Problem
Using these definitions, is a web site complex if it’s a single web page with a several bjillion links? Or is it complex if it has half a bjillion web pages each with only a few links? Neither. Or both. By my definition, clicking through umpteen levels of a menu hierarchy is not complex if it doesn’t cause any confusion. It’s merely tedious. Certainly there are products out there that are tedious to use, and we should design things to be as efficient with the user’s time as possible, but don’t confuse that with complaints about complexity. On the other hand, if the menu hierarchy causes users to get lost, stuck, or make incorrect choices, then they are the victim of complexity. Likewise, a page packed with links or a handheld product packed with physical buttons is not necessarily complex, although it might be complex-looking to the casual observer. It’s only complex if it leads the user to make wrong choices or interpretations about the product. Otherwise, such a design might potentially waste the user’s time in searching among the controls for the one thing the user wants (plus, it’s probably ugly), but that’s not a problem with complexity. Optimizing the balance of breadth versus depth for user efficiency is a classic usability problem, but that’s a topic for a later post. It’s not necessarily about simplicity as I’ve defined it.
Simplicity by my definition is also not about compatible coding. Using green to mean orange is not complex. Sure, it may cause confusion, but not because of the combination of numerous elements. I don’t know what I’d call such a design, but “stupid” seems more apt than “complex.” I might even call it “simple-minded,” except it must take a remarkable genius to turn a site for selecting a stadium seat into some sort of satanic Stroop test.
Some have said that waiting makes things seem more complex. It does? Well, waiting sucks and we should eliminate it from our products and systems, but it isn’t complex. You just sit and wait. What could be simpler than doing nothing? Assuming you’re providing sufficient feedback that the user is supposed to wait, confusion is not the problem. Likewise, lifting a heavy TV out of a box is not complex, unless maybe it involves operating a forklift. It’s strenuous, an ergonomic Bad Thing™, but again not what I’m talking about today.
Reducing Features
So how do you simplify? Cutting out features is, I dare say, the most simple-minded approach to simplification. It is obvious even to consumers (at least after using the product) that a large feature set tends to add to complexity, so much so that to some simplification is erroneously considered synonymous with cutting features. Fewer features mean fewer things to learn and understand. Fewer features implies sparser navigation networks, making it less likely your users will get lost. Fewer features allow a shallower menu hierarchy, meaning less abstract menu labels at the top that tend to cause confusion (a Verizon phone I saw had a menu for Tools and another for Utilities. Sheesh). Within the same menu or page, fewer features can cut down on the number of things to name and distinguish, which can otherwise be confused with each other. If your image-editing app doesn’t support resizing your users are not going to confuse it with resampling, for example. If your file manager doesn’t have a Tile view, it won’t be confused with Thumbnails, or vice versa.
Can You Afford It?
It’s true that feature-rich products sell while excellent usability is harder to sell. I believe that’s because it’s easier for a consumer in the store to count features listed on the packaging than to actually try out the product and evaluate the usability. Nearly no one thinks of oneself as stupid, so it is easy to convince oneself that one will figure out whatever features are hawked. Purchases over the web allow no opportunities at all to try out the product. One can try it out vicariously through reviews, but a bias towards features may exist for reviews too: I don’t believe tech journalists really have time to live with a set of products and compare how easy the features are to use. I believe more often tech journalists read the literature accompanying the product, count the features and declare the winner, which encourages higher sales of more complex products. Even if tech reviewers do actually use a product enough to find usability problems, are they actually going to admit it? What does it do to their credibility if they say they couldn’t figure out the latest cutting-edge techogadget? Too often usability problems are blamed on the user.
There may be ways to market usability better and maybe users are ready to be receptive to such marketing. Maybe it can even be done on the web: don’t just say your product has Core Feature X, show how easy it is to figure out how to use it through an interactive simulation. If customers know they can execute Core Feature X on Product A, but they don’t know about Product B, maybe they’ll be more incline to buy Product A, even if it lacks Obscure Feature Epsilon. But in the mean time, do you take the chance of cutting features?
Will It Help?
But let’s get back to engineering, not marketing. However the product is sold, as usability engineers, we want to enhance the user’s experience, and one way to do that is to reduce confusion by cutting unnecessary features.
You might think a flashlight can get by with just two modes –on and off. I’ve a flashlight with six. There’s off, on at three levels of brightness, and flashing at two different frequencies. Of course, I only use the off and brightest level of on. I can see situations when I might need one mode of flashing, like some night I’m walking along a busy highway, but two frequencies? I can also dream of some situation where I’d want the lowest level of brightness, like I’m lost deep in McDougal’s Cave and need to conserve battery life, but three levels? These multiple modes are unnecessary complexity, thanks in particular to a deceptively simple-looking one-button user interface. When the light is off, you press the button to get the maximum brightness mode. Press it again and it cycles to the next level of brightness or to a flashing mode, unless you wait too long, in which case it turns it off. That’s confusing. I can’t always tell exactly what the light will do when I press the button. Have I waited long enough for it to turn off? Have I waited too long for it to cycle to the next level of brightness? Overall, if it must have a one-button interface, I’d be better off with just the classic off-and-on modes. At least until I get hit by a truck some dark night.
So, certainly, look critically through the features of your product. Fight against features that have little or no user value in the context of the activity the product is likely to be used. Consider the possibilities of shifting a feature to another gadget for which it will be easier to use. Maybe that camera doesn’t need red-eye reduction if it’s easier to do it post-production in image editing software. How sophisticated does a camera in a phone have to be to support the expected communications? Maybe you leave the high-quality pictures to a dedicated camera. Is there really a significant proportion of your users that want to use the mp3 player you built into a GPS? What’s listening to music have to do with going from Point A to B? What about including a tape measure? Or a digital loupe? It’s getting that ridiculous.
But Will It Help Much?
Actually, a GPS with an electronic tape measure and digital loupe might be pretty useful if you’re an archaeologist.
And that’s really the rub. While there are some useless features in some gadgets out there, I don’t see feature reduction as having any major impact on the problem of technological complexity, because the whole history of technology is about giving users more capability and more options. Early in human history, if you wanted to get from Point A to Point B, you had one choice: use your feet. Now we have a truly impressive array of transportation modes, each suitable for different situations vastly expanding our ambulatory power. And, yes, as a matter of fact, lots of people do like to listen to music while going from Point A to Point B. Cooking once meant sticking something over a fire. Now it means ovens, stoves, microwaves, deep-fryers, toasters, and chaffing dishes, among others. People want more capability. That’s why features sell. Sure, you can make a GPS without a built-in mp3 player, and you’ll find a niche for it. But if it means users have to also have a dedicated mp3 player when traveling, have you really accomplished much simplification? Each gadget may be simpler to learn, but now there are more gadgets to learn. Controls and displays optimized for a limited function can reduce overall confusion, but the total reduction may not be too impressive. We should be able to make a search through a top-level menu for a fundamental feature easier than searching through a briefcase for a dedicated gadget. Stripping down our gadgets to basic functionality may ultimately be a usability disservice to our users because it may increase the summed amount of cognitive and physical effort across all gadgets.
And speaking of handheld gadgets, we also must recognize that Moore’s Law is pushing these devices to the point that the UI hardware dictates the physical size. The iPod, for example is shrinking down to the scale of a bobby pin. Ten or twenty years from now, people will marvel that we walked around carrying separate cellphones, pagers, mp3 players, GPSs, text messengers, laptops, digital cameras, and PDAs, each replicating a visual display and keypad, and each with their own charging chord. It will be like having separate desktop computers for word processing and spreadsheet use. Quite apart from marketing concerns, I think we have to be prepared for more capability in our devices, not less. The question is how to manage such potential for complexity.
How About Customization?
When it comes to technological capability, users don’t really want choice so much as they want change –something better than they have now. What constitutes “better” is very personal. Every feature may be important, but they’re not important to everyone. It’s said that 80% of users use only 20% of the features, but unfortunately it’s not the same 20% for everyone, but, by golly, the product better have that critical 20% because that’s the thing that makes it better to the user. This implies that feature reduction might work if each individual user gets to pick the features.
There’s several stages in the user experience that customization can be effected:
- At product selection. You can market a wide assortment of products each with a particular combination of features, while most have few features. Your bicycle-courier GPS will be different than your archaeologist GPS, for example.
- At product purchase. Alternatively, as long as features are represented as software, you can allow your user to load a custom suite of features when the buy it. Not unlike loading applications on a personal computer, each feature costs a small amount encouraging users to only load what they really want. They can always buy a feature later, if it turns out they need it.
- At setup. All features are included, but the user can select features to present in the course of setting up the product at home. This can be extended to provide the user the ability to fully customize the UI, controlling not only what features are available, but how they are available. If a user wants pressing the Big Blue Button to immediately silence a ring on their cell phone and switch it over to vibrate, then they can do that.
- On demand. All features are loaded, but their UI does not appear until “activated” by the user. You want an alarm clock for your cell phone? Pick “Alarm Clock” from a sorted and/or searchable comprehensive list of features, and it appears on the menu. This is a highly underused technique that has much promise.
- In use (automatic). I’m skeptical of the ability of software to anticipate from user behavior what features they are likely to need. More likely, this will only confuse the user as the product becomes difficult to predict. However, it is often practical to make the most commonly used features more apparent to the user. A top level menu could list only these features along with an “all” menu item for accessing a complete list, for example.
Of course, at whatever stage it is exercised, customization by the user adds some complexity. The user has to understand the features and their implications before deciding what they want. Customization can work if it removes more complexity than it adds. As long as options are easily understood, options are not paralyzing and choice can be made optimally, although it will still take some time. You can expect users to be especially impatient with a lengthy set-up procedure.
The main challenge with taking a customization approach is designing a system of UIs that scales nicely with various types and numbers of features. For example, to accommodate a large feature set, you may need a multiple level menu hierarchy to keep the number of menu items on each menu reasonable. However you don’t want the user of a few-feature product to have to dig down through the same layers of menus, some with only one or two items on them. Keep in mind the menu names at the top of the hierarchy tend to be the most abstract and therefore most likely to cause confusion. If your few-feature users have to use the same top-level menu you may be defeating half the advantage of a having only a few features. You can dynamically change you menu structure to keep the breadth versus depth reasonable across different numbers of features, but changing the menu by moving features around within the hierarchy should also be avoided. Once users are use to the location of a feature, they’ll surely be confused if it suddenly disappears, moved because it’s no longer used sufficiently frequently or because the loading or activation of some new features has change the hierarchy depth.
Simplifying without Reducing Capability
Design Clarity
Cutting capability is not the only way to simplify. Instead of removing a few modes from my six-mode flashlight, for example, you could improve it by re-working the user-interface to it. The problem with the one-button interface is the same action (button-pressing) has different results depending on the circumstances (length of delay in this case), where the circumstances are poorly communicated (no display if the delay passed its threshold). The whole problem of the un-indicated delay threshold can be obviated by having two independent controls: A two-position switch to turn it on or off, and a five-position switch (such as a rotary switch) to select the intensity/flashing frequency when it is on. No more turning it off when the user just wants a different level of brightness, or vice versa. Furthermore with this design, users like myself simply never touch the five-position switch. As far as we are concerned, it’s an old-fashioned two-mode flashlight. Meanwhile, those flashlight power-users out there have unhindered access to all the flashlight’s uncompromised capabilities.
As this illustration shows, complexity can be often be minimize with good solid human factors analysis and maximizing the clarity of the user interface. Maybe your problem isn’t really all those features but how they are represented in the UI. Compatible controls, clear displays and labeling, excellent organization, avoidance of control modes, and good feedback alone can go a long way. The more features in your product, the more important this is and the fewer concessions you should allow for decoration, fashion, or style. Flashy multi-color pages may look cool, but cannot be tolerated in a sophisticated interface where, for example, it confuses which option the user has currently selected. In the extreme, everything needs to optimize to most effectively communicate with the user.
Here are some common pitfalls:
- Over-use of icons. Unless a label represents something genuinely visual (e.g., literally scrolling a list up and down), words are almost always better.
- Hidden abilities. Anything your product can do should have some sort of inviting visual cue.
- No way out. The means of canceling, stopping, deactivating, or exiting something should be clearly labeled.
- Inadequate feedback. Anything the user does should have some confirmatory reaction from system, even if it’s just a change in an annunciator.
- Disorganization. Similar and related things from the user’s perspective should be proximal to each other.
Standardization
Complexity in design is almost synonymous with a steep learning curve. Once you learn a feature set, you know it. Confusion is no more and complexity goes away. Users complain about complexity, but I wonder how much of that is not the increase in features and capabilities but rather the speed that products change. Just when you learned one cell phone, it’s time to turn it in for another, which not only has new features but a new UI to the old features. Everything needs to be re-learned, and in the mean time confusion reigns.
If you decided to stuff all technology and go live primitively in the Amazon rain forest, you might be surprised how complex that life is. This is edible but that is poisonous, even though they look alike. That’s a sign of prey, but this means a predator; don’t confuse them. This shrub is medicinal, and so on. Wherever or however people live, people accumulate a life-time’s worth of knowledge, but if you learned as a child that a particular shrub is medicinal, then it’ll still be medicinal in your old age. You don’t have to worry about them coming out with Shrub 2.0. It takes far less time to teach someone to figure out his or her position with a handheld GPS than with a sextant and chronometer, but the sextant and chronometer were largely unchanged for over 200 years. Upgrading to the latest sextant did not mean learning a new menu system and terminology.
The call for simplicity may actually mask a need for UIs to stop changing so often, requiring re-learning. More standardization should be achievable at least within a particular company. Technology may change, but humans remain the same, so the most human-compatible means of interacting with a product should remain largely the same. Market pressures demand that new products look new to attract consumers. That demand can be met while minimizing complexity by keeping the new look superficial, limiting it to such things as color theme, font, and some shape aspects. Trousers change fashion regularly but always have two legs and at least two pockets (for men, anyway). It would seem the same level of stability can be applied to electronic devices. Preserving UI consistency into new models may encourage more existing users to upgrade rather than move to a competitor’s.
Vision
Having a user interface vision for your product also allows high capability with low complexity. A UI vision means a single, cohesive, internally consistent logic to your user interface. It means have a small set of simple rules for interaction that can apply to any feature, existing or future. Users will need to learn the rules, but once users learn the rules for one feature they can generalize it to other features, reducing the chance for confusion. On the other hand, if each feature follows its own rules, then users are left to memorizing the use of each feature independently by rote, with plenty of opportunities for confusion from proactive and retroactive interference. Learning 3 rules is simpler than learning 30 unique interfaces.
In the desktop world, direct manipulation is an example of a vision for a UI. Data is represented as objects. Data is manipulated by the spatial arrangement of the objects or their visualized attributes. Once you understand that for a game of solitaire, it’s not hard to generalize to a file management application. Handheld products typically lack the screen real estate for direct manipulation, so they may need a different vision. The iPod’s simplicity is largely rooted in its commitment to a single UI vision: nearly everything is controlled by shuttling through hierarchically organized vertical lists.
For your vision, you need rules for:
- How to select a function (e.g., make a phone call, play a song)
- Specify the parameters for the function (e.g., number to dial, song to play).
- Cancel a function (e.g., not make the call, not play the song).
- Execute the function (e.g., dial the number, start the song).
- Stop the function (e.g., disconnect the call, discontinue playing the song).
Is there a reason your phone-with-mp3-player has the user dial a phone number with a hardware Send button, but start a song with a soft key? That doesn’t sound like a product with vision. Why are some functions on your PDA, like the address book, access by dedicated button while other functions, like a Minesweeper game, access by menu? Maybe there’s a reason, but it should be a reason that’s clear to the users, a rule they can pick up merely by interacting with the product, something that allows them to predict how to access the camera function. The use of documentation, metaphor, graphics, and layout can be used to communicate the vision, but mostly just getting the users to use one feature should be enough.
For simplicity, it’s important to have a single vision for your product, not two visions even if both visions are complete. Ideally there should only be one good way to do something. There’s a usability myth that you should provide the user with multiple ways of doing the same thing. For example, on the desktop, you can execute a given command through a pulldown menu, toolbar, accelerator, context menu, and drag and drop. On web sites, the user may navigate to a page through any number of combinations of links. Like all myths, there’s a deeper level of truth to it. Users have different backgrounds or work under different situations and one way may have an advantage over another. But this comes at the price of complexity. Rules for different visions may be confused with one another, displays become cluttered as they attempt to communicate competing visions, and users may only pick up a few of the rules from each vision and never develop a coherent sense of any one vision. You’re adding complexity without even adding any features. Sticking to a single vision means the UI is not necessarily optimize for every feature. There might be an extra step occasionally, but it will be an extra step that actually reduces complexity.
Abstraction
With a vision, you recognize that different features can have essentially the same UI. With abstraction, you recognize that different features are really the same feature. This way you cut down on the apparent number of features, and the attending UI, while giving up none of the capability. Windows Explorer in Vista has separate toolbar items for emailing a file and burning a CD, plus a menu item for copying files, but aren’t all these processes copying files? What was wrong with having one way to copy a file whether it is to an email, a CD, or another folder? Abstracting all this capability to one feature would reduce the screen clutter and potential confusion that comes with it.
Why provide a separate alarm clock feature in your electronic organizer when it already has an appointment book? Let the user just schedule a wake-up appointment. If your GPS already has a camera, then don’t have a separate digital loupe feature. Just give the camera a macro-capable lens and combine the two. Your electronic tape measure can be implemented the same as getting the distance between two waypoints.
Abstraction has the potential to substantially simplify products, reducing apparent features and promoting UI consistency while maintaining full capability. The primary risk is that you can abstract the features right over the user’s head, and end up with a UI that is divorced from the way the user thinks. Will it occur to a user that emailing a document is just another form of copying? Will a user realize that you can look through a camera even when you don’t intend to take a picture? Will anyone other than the designer see the connection between an alarm clock and an appointment book? In Unix the same command is used to move a file as to rename it, but does that make any sense to anyone not familiar with file systems? Abstraction can reduce your product’s complexity, but you have to be careful it doesn’t produce a different kind of confusion, not from numerous things but from an alien way of thinking.
Automation
Finally, there’s automation which can simplify by giving the user less to worry about. That can work but only if the automation just works without any user involvement. Success is most likely if utilization work is automated, reducing the amount of technology-specific knowledge the user has to have. Often, however, automation isn’t perfect for all situations, which can add to confusion. When the automation doesn’t always work the way the user wants it to, the user is force to try to figure out the automation to trick it into doing what is wanted. Given the sophistication of some automation, this can be a hopelessly complex task. Alternatively, you can give your automation multiple modes and leave it to the user to select the appropriate mode for the situation, where one of the modes is typically manual. Now by trying to simplify the task you’ve actually made it more complex: the user has to learn the modes, when each applies, how to set the modes, as well as how to use the product manually. Without automation, the user only has to learn the manual part. Automation won’t solve everything.
Summary Checklist
Problem: Users troubled by complex products.
Potential Solutions
- Recognize the problem is the confusion that results from the combined effect of numerous things.
- Eliminate unnecessary features.
- Support customization, such as features on demand.
- Maximize the clarity of the UI.
- Maintain a standard UI across generations of the product.
- Have a single vision for the UI.
- Abstract features into a single feature.
- Automate utilization work.