ThinkFlood Blog

If you have been following along as I unveil my crazed delusions regarding usability, you may have been wondering when I would get around to this principle. It seems that many people place familiarity on the top of the pile. This is a natural thing to do, of course — if we are already accustomed to a particular interface or behavior, why not replicate it? At the very least, it can’t be worse than the original, right?

Well, yes and no. Before I launch into criticism of the idea of familiarity, a disclaimer: of course familiarity is important, and it is an effective way to design interfaces. Metaphors (like the desktop or the trash can/recycle bin), real world controls (like buttons and sliders), and familiar images, colors, and sounds all have a major role to play in intuitive interface design. We humans think associatively, so it is relatively easy for us to learn new things when there are familiar components for us to latch onto. Familiarity as a design principle absolutely deserves a spot on my list.

Now for the diatribe.

There are a lot of places where familiarity breaks down, and one of them is over-reliance upon it. For example, a friend of mine in Illinois once told me how he had watched someone demonstrate a new graphical shell that employed a physics engine. In this brave new world, everything reacted just as you would expect from your experience in real life. This sounds great – until you actually use it. The issue was that it was too realistic. So, when you are trying to move that folder with 30GB of files inside it takes twenty seconds to drag it across the screen because it is supposed to “feel heavy.” I have to wonder why someone would want to build frustration and tedium into an application.

One of the great things about the virtual world is that we do not have to deal with physical constraints. It might seem that this would go without saying, but I see evidence of misguided design everywhere. For example, at the moment everyone seems to love transparency and lighting effects – “reflections are the new drop shadows,” some say. But I have to wonder why it makes any sense to imitate glare on a button face, when most people staring at a computer screen all day do what they can to eliminate glare because it makes things hard to read. In fact, virtual glare is worse than the real thing, because no matter how we try, we can’t block it by adjusting monitor position or closing the blinds. Let’s not through out good graphical design (including high contrast between text and background) just to make things look spiffy.

Another danger with familiarity is that not everyone has the same experience — the old subjectivity argument that I like to bring out. Here’s one that may surprise you. I would bet that just about everyone who has used a computer in the last twenty years is familiar with the cut/copy/paste metaphor. After all, these three functions alone made word processing a killer app. But how many people understand the genesis of the familiar scissors (cut) and glue (paste) icons floating out there on the toolbar in their word processors? As it turns out, people that have come of age since the arrival of the word processor just do not have the experience of cut and paste typewriter correction. Is this an effective metaphor for them? Not really. But they understand it anyway because they grew up with computers (i.e., consistency probably matters more than familiarity here — but I’m getting ahead of myself by a couple of principles now).

While I caution moderation with the use of metaphors, colors, and so forth, there is a type of familiarity that I find particularly lacking — that of physical interface familiarity. I am not talking about representations of the real world, but rather real world interfaces. For example, the keyboard and mouse are unnatural – we do not control anything with these interfaces other than computers. The keyboard is a 19th century replacement for speech — with the QWERTY layout intentionally made inefficient so as to slow down typists to prevent the keys from jamming together at the print head. And the mouse is a sorry replacement for those universal pointing and manipulating devices, fingers. Here we have technological constraints dictating the physical interface, rather than design ideals. Of course there have been many attempts (most failing pretty miserably) at reliable voice and handwriting recognition. But technology improves over time. I think a lot of the interest around the iPhone stems from its bold reintroduction of the finger as the primary pointing and manipulation device. Technology analysts all seem to be talking about how touch screens are on the verge of explosive growth. Personally, I hope they are right.

There are a lot of other physical interfaces that we have left to explore. Some applications today do alright with sound and visual cues as feedback mechanisms, but there are other things. Eye motion, facial expressions, maybe even behavioral patterns. Personally I would be thrilled if those people developing operating system kernels (though they be far removed from interface design) were to recognize that when I start clicking frantically they should give more CPU to the process I am trying to manipulate and put whatever else is happening on hold for a minute.

To sum up, familiarity is a great idea in interface design. It comes a little later on the list because it is subjective (the prior six principles are not subjective, and by their more universal applicability, deserve a more important position), and because it is more helpful to the novice than the expert. When dealing with abstract familiarities (such as metaphors), we need to exercise some caution to make sure that we are not violating other usability principles. But when it comes to physical interfaces, we could do well with a lot more “familiarity” than we see today.

While my blog ramblings may not show it, I have a liberal arts background. Yes, I succumbed to enough traditional schooling that I have become a slavish devotee to Strunk and White’s treatise on writing. Passive voice, bad; active voice, good. Brevity, also good (although I stumble here often). So it is not surprising that I consider clarity — clarity of writing, clarity of interface, clarity of purpose — a virtue, even a fundamental principle for living.

You may ask why this principle is not higher upon the list. How is clarity subordinate to proximity, for example? To this question I have to answer that clarity primarily benefits the novice, while proximity benefits both novice and expert. Yes, clarity is about communication, and communication matters most when two people or a person and a concept are far apart. For example, sometimes I can get away with unclear communications to my wife, because we have enough shared experience that she knows the context of my thinking and can deduce my meaning. But I have to be more careful when meeting someone for the first time, because I do not want them to have a foggy impression of my motives, morals, or movements.

Unfortunately, by opening this post with comments about writing style, I have probably led you to believe that I am mostly referring to clarity of written messages. The poster boy for this problem likely to be the following:

To a non-programmer, this error message is completely meaningless. What is 0×1003e8d? Why is there an instruction there, anyway? And who is “reading” what? To a programmer with access to a memory dump from the time of the error, this message is helpful, but without that context this message is too generic to be useful. Why allow anyone to see it, then? Heck, there isn’t even a choice of what to do — the application is crashing and burning, so wouldn’t it be clearer just to say this:

Certainly clarity covers the wording of error messages and other dialog boxes, and there is some need to improve how these read. However, in my opinion spending time writing understandable messages is somewhat misguided. Instead, what can we do to make the interface more understandable (and less error prone) without all the extra words? I see too many pop-up message boxes telling me this or that — if the interfaces themselves were clear, then there would be no need for explanation.

So, how do we make interfaces clearer? Just as much of person-to-person conversation is non-verbal visual cues, so too should much of our person-to-machine conversation use these non-verbal cues. For example, buttons should stand out so that we know they are “hot spots” for action on the screen. That is, they should have some added dimension (color, shading and highlighting, etc), and ideally should deform or change subtly when we mouse over or press them (sometimes we call this last bit “malleability”). Controls should have meaningful icons and clear descriptions. Words like “Go,” “OK,” “Done,” and “Close” do not convey much information, and so we should avoid them. Personally, I am not afraid of a button name that is three or four words long — it beats a thirty word message box to ask me whether I really know what I am doing.

I believe another way to gain clarity is to modify the interface for each specific task. There is nothing more unclear than large numbers of commands that are unrelated or unavailable to the task at hand. Once again minimalism in design — even moment to moment during program operation — will help us highlight available functionality.

I realize that I may be treading close to a classic usability no-no, something called “modality.” Modality is the idea that user actions lead to certain places (modes) in which only a limited choice of options is available. The problem with modality is that it feels limiting — we have to deal with the modal operation first (or cancel out of the mode) before we can move on to do something else. However, when I talk about tailoring the interface to the current task, I am not advocating that we disable other operations. Instead, I see the interface as more fluid than static. When I choose a certain tool or enter a certain space, the related functions and options might rearrange themselves to be more proximate to my action, perhaps reordered to show the most common choices in the most convenient places. Such reordering will attract my attention – it will become the non-verbal communication that tells me what I am most likely to do next, and it helps me find what I need.

In the end, clarity is about making things obvious — hitting the user over the head with the next likely choices. Words are an important part of this obviousness – particularly labels that identify choices – but movement and styling often leave a greater impression on the mind. The highest degree of clarity comes from the most minimalistic of indicators, so as designers we should lean toward succinctness.

By the time we arrive at this principle, we should have already determined that the feature or feature set in question is 1) a necessary part of the overall design, and 2) not completely hidden by automation. What should we consider next?

Because no one seems to read user manuals anymore (did we ever?), a fundamental tenant that most usability professionals espouse is the idea of interface “discoverability” — some pathway whereby we learn as we go. Discoverability has many manifestations (menus; “tip of the day;” Clippy, the much maligned MS Office help assistant), though I have to admit that I am not a fan of most. While I agree with discoverability in principle, I find that many of the features that are designed to make user interfaces discoverable to novices get in the way of expert users. As a result, designers have struck upon the idea of having different interfaces for people with different experience levels (i.e., “normal mode,” and “expert mode”). Oh what a tangled web we weave…

The question remains, then, how can we encourage simple discoverability? I believe the answer lies in one facet of a principle that has even wider design implications, something I will call “proximity.”

Proximity refers to the idea that controls should always be as close to the action as possible. Proximity can apply to physical space (for example, transport controls for a movie or song appear just below or even superimposed above the play window), but also in terms of a clickpath, collapsible tree structure, or menu cascade. In fact, usually the second type of proximity is more important than physical proximity, because burying controls on separate screens or underneath other piles of controls means obscuring options.

I would like to illustrate with two examples — one good and one bad — from Apple’s iPhone. First for the bad. By now, pretty much everyone has seen what the home screen on the iPhone looks like – black background, square application icons with rounded edges laid out across four columns, with application names displayed underneath. There are three rows of icons up top, and then a special row of icons along the bottom of the screen, but based on the layout, there is room for another row of icons in between these. Here’s what bothers me: in order to access Contacts, we have to click on the Phone icon first, and then choose contacts from one of the five available icons inside the phone application. To me, this doesn’t make any sense. First, I often use my contacts for other things – to look up an address, to send an email, to send a text message. Why can’t I start from a contact and then go into one of these other applications? Second, there is that annoyingly empty row on the home screen, which would be a great place to plop down a Contacts icon. In fact, for the iPod Touch (where Apple seems to be in search of some applications to fill up that empty black space), Contacts does appear on the home screen. Perhaps even worse than Contacts being hidden away, Favorites is equally inaccessible. Whereas on virtually any other cell phone dialing a favorite means punching and holding down a number key, on the iPhone it takes me at least three (often four) taps (slide to unlock, phone, favorites, select favorite). Ugh.

Here’s one that I like better. Watching videos on the iPhone is great — for a mobile device the screen is large and bright, resolution is good for the size, battery life is decent, and the interface is elegant. When you choose a video to watch, the display automatically switches to a horizontal viewing mode, and the video fills the entire screen. Here I don’t mind tapping once to display the video controls – with the entire screen filled, it is natural for me to tap the screen if I want to do something. When I do, I get everything I need – a clock and battery gauge appear along the top; play, fast forward and rewind buttons are superimposed over the bottom third of the screen (large enough to tap easily); there is a scrubber below the clock that shows time elapsed and time remaining, and another button (oddly named “Done”) allows me to exit the video and return to the iPod menu. If I do nothing for a few seconds, the controls fade out harmlessly, or if I am impatient I can tap the video to hide them immediately.

Perhaps some will feel that I am bending my own rule to allow tapping the video screen to display the controls. I consider this a reasonable tradeoff. After all, one of the arguments that curmudgeons will make against proximity is that there is not enough room on the screen to make all the controls available at once. Of course not — we have to make some allowances. I certainly do not want to lose any of the screen real estate on my mobile device in order to persistently display transport controls or the clock. The important thing is that we add as few extra layers as possible. And when we have more than one layer, or when there is some separation, that we thoughtfully place the less important features farther away (or, we could go back to our minimalism roots and eliminate those less important features altogether).

Proximity has other implications in design, as well. Grouping controls that have affinity, displaying appropriate options based on context, and duplicating controls for convenience are some examples. But the best part about proximity is that it improves the interface for both novices and experts alike.

Following along with the arguments that favor minimalism, we can see how automation improves usability. Specifically, automation alleviates the problem of subjectivity by reducing the amount of consumer interaction. In addition, automation also improves usability by eliminating (or at least reducing) repetitive actions, and it can reduce the possibility of human error.

Some of the best systems are highly automated. For example, we can think of utilities (gas, water, electricity, telecom) as “automated” delivery systems — at least from the consumer perspective. In most cases, the purpose of computers, appliances, and other machines is to provide automation, and it is clear that our lifestyle and culture have benefited from their introduction.

Because automation addresses some of the same issues that minimalism addresses, we might be tempted to conclude that automation is nothing more than a special case of minimalism, not significant enough to qualify as a principle in its own right. However, I believe that while minimalist design and automation both address similar problems, there is a fundamental difference in approach that justifies separate treatment. The crux is that while automation seeks only to minimize an interface, minimalism actually questions the inclusion of the feature itself.

From a usability perspective, this difference between minimalism and automation may seem trivial. After all, automating a feature can reduce the interface as much as eliminating the feature altogether. However, in my opinion this is a dangerous argument. If we believe that automation allows us to add features without any increase in the complexity of the interface, we will be inclined to add as many features as we can, so long as they are automated. In other words, automation can entice us to reject minimalism.

If automation really allows us to add features without increasing interface complexity, then why not do so? The answer is that, in practice, automation rarely comes free. In fact, sometimes automated tasks have the most confusing and complex interfaces, because the action taking place is at least partially obscured from view.

A familiar example makes this clear. Cruise control has been available for many years now, and the interface seems fairly stable. There is generally a button to turn the system on and off. A second button sets the cruising speed, a cancel button releases the system back to manual acceleration, and a fourth button resumes the former cruising speed after a return to manual acceleration. There are also buttons to trim the cruising speed down (the deceleration button, usually the same as the set button), and up (the acceleration button, usually the same as the resume button). Finally, tapping the break has the same effect as the cancel button. Phew.

Now let’s consider what cruise control replaces: a single control, the accelerator pedal. We push the pedal toward the floor to accelerate, or release it to slow down. The farther we push the pedal, the faster we accelerate. The direct method of controlling acceleration is significantly more simple and easy to use than the cruise control system.

The issue here is that cruise control cannot completely automate control of the car’s speed; it is not an auto-pilot system. While some luxury cars offer more advanced versions of cruise control that use lasers or sonar to ensure a safe distance between us and the car ahead, these systems do not relieve us from the task of monitoring our speed or relative position to cars and obstacles around us. As a result, they have to incorporate other controls (such as cancel, resume, and accelerate) that allow us to make adjustments as necessary. In fact, it seems that the only real benefits of cruise control are that we do not have to check our speedometer to verify that we are driving within the legal limit, and that we can reduce fatigue by taking our right foot off the accelerator pedal to move our leg about a bit.

Don’t get me wrong — I rely upon cruise control when I have to drive for more than an hour or two at a time. Fatigue is a real issue, and every little bit of freedom to move about or to focus on the road (rather than the speedometer) helps. However, this “automation” actually makes the driving interface significantly more complex – enough so that I often leave cruise control off when driving a rental car.

The moral of the story here is that we have to be careful when we choose to automate a feature. Automation is not an excuse to add a feature that we would not have included otherwise. That is, we must stick to minimalism, the first principle of usability. However, given a feature that we plan to include which also offers the possibility of automation, we should consider this option.

I believe that there are two types of automation. The first (and most user-friendly) is the “set and forget” type. With this kind of automation, we configure a few options (even better, the options are well-known and pre-configured), and then the program or device chugs away without any real need for us to babysit the process.

The second type of automation is more like cruise control: it exists to reduce the amount of tedium or fatigue that we would experience through repetitive or sustained interaction with the product. Unfortunately, this type of automation often requires continued monitoring and may not reduce the complexity of the interface at all.

If automation increases the complexity of an interface, we need to determine whether the automation benefits outweigh the potential confusion that complexity will bring. With “set and forget” systems, the answer is often yes – because even though initial setup may require an expert or a few extra minutes of consumer time up front, the payback will come quickly. With fatigue-reducing systems, we may have a harder time justifying the automation — which may be a clue that there is a more fundamental flaw in the product design.

Automation is a great timesaver and can make a product truly worthwhile, but only if the product works as it should (reliability) and does not destroy or corrupt data (preservation).

So, the bottom line on automation is that once we have decided to include a feature, we should explore the possibility of automating it. Particularly if we can design the feature as “set and forget,” we may be able to streamline the interface significantly.

I believe that the next most important usability principle after minimalism and preservation is reliability. Here I do not offer any particularly involved arguments, but instead resort to common sense: how can a tool be useful to us if it is unreliable?

Okay, fine – so we want our widgets to function as advertised; no contest here. But surely no design is intentionally unreliable. And the old 80/20 rule tells us that it can be incredibly expensive to produce a product that is bug/defect free. When we argue for a reliable design, what exactly do we mean?

Of course one enemy of reliability is complexity, but we should have already taken care of that with minimalism. And a major concern with reliability is data corruption or data loss, but we have already taken care of that with preservation. If we rule out obscure and uncommon errors, what’s left? A lot, of course.

A big part of reliability is availability, and high availability is very much a design-time decision. It has everything to do with redundancy. Google, with its far-flung server farms, does a fantastic job on this point. If I am having a problem with Internet connectivity, one of my first tests is always to see whether I can get a browser to load the Google home page, or whether I can ping the google.com domain. Big as Google is, I am sure they are targets of frequent denial of service and other such attacks, but they always seem to be there. This level of availability is part of the reason that I use their search engine — because it is always there, and it just works.

To me, one of the best ways to judge the reliability of a tool is to ask two questions: 1) what is the main purpose of the tool? and 2) how well does the tool fulfill this purpose? For example, there are a lot of cellular handsets on the market that function as nifty personal organizers and media players, but how well do they receive calls? Is voice quality good? Battery life? What about the ease of placing a call?

If this argument is beginning to sound a bit like minimalism, let’s consider a different angle: let’s examine a relatively minimalist device that falls down here. We have a DVD player that I bought about ten years ago, right around the time when DVD players were first available in the US. Generally speaking, it works fine. However, I find that it chokes on DVD’s encoded with ARccOS, an additional digital rights management layer that Sony has used with some titles. Thus, while my DVD player is more than adequate in most cases, it is unreliable because it cannot play all of the mainline digital video discs. The issue is that the player is too minimalistic — it is not sophisticated enough to follow the instructions provided in ARccOS.

When we are thinking about reliability in our designs, we should be asking ourselves

• whether the feature set is sufficient the main purpose of the tool
• whether the product works as advertised
• whether the design is robust enough to withstand a few “shocks and vibrations” (availability)
• whether it produces frequent errors
• whether changes made with the product will “stick”

Finally, although reliability is important, we can tolerate a product a bit more if our data is not corrupted or lost. For this reason, preservation is more fundamental than reliability.

“Primum non nocere” — first do no harm. Doctors consider this advice when planning for the care of a patient. The idea is to pause a moment before embarking on a course of treatment in order to ensure that the remedy is not worse than the illness.

In keeping with the spirit of minimalism, perhaps usability design should also adopt such a slogan. Let’s call it “preservation.” It is absurd to think that all the tools we might make would leave the in-process object or data completely unmodified – most of these tools would be useless if they could not make some changes. Instead, the idea of preservation is to eliminate (or at least to minimize) irreversible modifications.

On page 68 of his book The Inmates are Running the Asylum, usability champion Alan Cooper makes a compelling case for the practice of allowing action reversal:

Humans generally don’t make decisions in the same way that computers do, and it is quite normal and typical for a person to change his mind or to want to undo a decision he made earlier. In the real world outside of computers, most actions can be deferred, changed, or reversed. There is no reason that this can’t also be true for software-based products, except that the programmers who create them don’t think that way.

In fact, I will go one step further than Cooper. Not only do we change our minds, but we are much more comfortable using a product when we know we have the ability to make a mistake without worrying that the whole thing will come crashing down around us.

Let’s think about the consequences of preservation for a moment. If I can change my mind later, then I feel free to experiment, to poke and to prod, to explore the limits of the tool I am using. If something does not turn out the way I wanted, I can always go back and try a different path. In this manner, when I have control over final outcome I am the master and the tool is just a tool. By contrast, if the tool does not offer preservation then I become a slave – trying to figure out how the tool wants me to act, encountering frustration when I make a mistake, and generally withdrawing for fear of making a bad situation worse.

In fact, the principle of preservation is quite common in design today, though perhaps not as prevalent as it should be. Here are a few examples:

1. Backwards and forwards navigation. The fact that you are reading this posting means that you are familiar with web browsing and the back and forward buttons. Especially when navigating a poorly designed website, most of us rely upon the back button to find our way on the Internet. Unfortunately, some of the slicker approaches to web design (Flash, AJAX) make the back button meaningless.
2. Undo/redo. Undo is an old standby that harks back to the original Macintosh. Newer improvements include virtually unlimited levels of undo, undo past save points, and even non-linear undo (i.e., undoing a particular action while leaving the rest of the action chain intact).
3. File backup and recovery. File backup is nearly as old as modern computing, but somehow most of us do not bother with it. Online backup services seem like a great idea, since we can store additional copies of our data in remote locations for a higher level of security.
4. Versioning. When paired with a good file backup and recovery system, versioning is a powerful tool that allows us to recover different snapshots of a file or database, potentially rolling forward or backward to find the instance that we want. There are also application specific versioning implementations (for example, Microsoft Word can store multiple versions of a document in a single file).
5. Non-destructive editing. This is a relatively new addition to the preservation bag of tricks, but it is one of my favorites. Some of the more robust photo and video editors allow us to store modifications to the media separate from the media itself. Thus, we can apply filters, adjust colors, and make many other changes without messing with the original image. In this way, we can come back to the file at any time in the future and immediately get back to the original image without any quality loss. Or we can create multiple different versions for different effects or uses.
6. Data consistency. We commonly use checksums and cyclic redundancy codes in networking protocols and data storage devices to ensure that data input and output operations have integrity. Databases also implement locking mechanisms to ensure transaction atomicity.

There are also other areas where we do not see enough preservation in design. For example, I consider software security under the umbrella of preservation. If I enter a transaction online, I want the privacy of my financial information preserved from identity theft. Any security expert will attest that it is easier to design a secure system than to add a layer of security to a system that is fundamentally insecure.

The real issue with preservation is that it can be difficult to implement. For example, non-linear undo can be a nightmare, because there may be dependencies among different actions taken. A great example of a mediocre implementation of preservation is the trashcan/recycle bin metaphor. Rather than implement a real file backup and recovery system (which would require external backup devices and additional management), we throw files away in the trashcan and then can retrieve them later if we realize that we made a mistake. However, personally I rarely undelete a file, and often when I do need to undelete something, I find that I have long since emptied the trash. Annoyingly, Windows XP insists on confirming with me every time that I try to delete something, and then again when I empty the trash. On the Macintosh I do not get these prompts, but I am not sure that I am happy with that, either, since there is no protection against my own stupidity.

Traditionally, arguments against preservation were that it required extra storage capacity or more intensive calculations. However, as storage costs plummet and computing power skyrockets, it is hard to find against things like file backup and non-destructive editing. I believe that the real reason we do not see more preservation designs is laziness on the part of the implementers.

While it may be harder to include preservation in our designs, the payback is real. Preservation does make life better for the people that use the tools we provide, and they are more likely to have a satisfying experience as a result. Moreover, they may be more willing to overlook other design flaws if we can guarantee that no harm will come to their data or possessions. Minimalism helps us to decide whether to include a feature. But once we have decided to do something, we are always better off if we can provide preservation as part of the implementation.

If my posts of the last couple of days seem rather rambling, I am trying to draw some conclusions. In particular, I would like to develop a framework for usability design – a number of principles that are fundamental to the usability puzzle that can help to guide design decisions. I propose that the first of these principles (i.e., the most fundamental) is minimalism.

Why minimalism? Once again, I turn to the issue of subjectivity. Different people perceive the same design in different ways; what makes sense to one may be incomprehensible to another. It follows that the more facets there are to a design, the more chance that some facet will be confusing to some people. Stated another way, each aspect of the design confuses some portion of the population. By reducing the number of facets, we reduce the total potential for confusion. I began to allude to this point yesterday when I identified the business tendency to add features as a practice that can hinder usable design.

Before we go crazy over minimalism, however, we need to differentiate this approach from nihilism. I’m not talking about political movements here, but about the knee-jerk reaction to eliminate everything in the name of simplicity. Minimalism does not mean nothingness. Instead, it is the minimum required to accomplish the task. If we cannot accomplish a meaningful task, then even the most clever interface design has no purpose, and is therefore unusable.

The key is to begin with a solid understanding of the design requirements. What are we trying to accomplish? Why? What are the benefits? Who will use it? Under what conditions? We should feel a certain anxiety about these questions. We need to challenge our initial assumptions, and ensure that we are driving at the heart of the matter. Misunderstanding the goal — or correctly understanding the wrong goal — makes it hard to optimize the design.

Once we have a laser focus on the purpose of the work, then we can begin to consider the interface. But here again we need to be minimalistic. We may be tempted to add some feature to make the design similar to existing designs for other things. However, because some people will be unfamiliar with those other things, it is better to make the design simple than similar.

A great example of minimalist design is the common light switch. The light switch is almost barbaric in its simplicity — all it does is turn a light on or off. But this is all that it needs to do. When I was a kid, I used to think that the dimmer switch in our dining room was cool because I could turn the lights down low and pretend we were at a fancy restaurant with candles on the table. But what is the point of turning on lights if they are not bright enough to illuminate anything? Even when I have a multi-stage lamp or a dimmer switch, I rarely do anything other than turn it on full power or turn it off. And for all those places where I do not have any other option, I have never felt deprived of the opportunity to achieve some intermediate level of illumination.

But the light switch offers more than just a way to turn on and off the light. It gives us information about the state of the light’s circuit. In a correctly wired switch, up means that power is flowing to the light, and down means that it is not. If the switch is up but we do not have any light, then the most likely cause is a blown bulb. Yes, the light switch is a debugging tool as well as a functional device. In addition to the up=on, down=off signaling, light switches abhor intermediate states. If we push the switch hard enough to get past a point, the switch springs the rest of the way and offers sensory feedback in terms of a satisfying click that tells us it has arrived at a resting point (i.e., that it is in a valid state). With all of these usability features focused on a simple application, no wonder the phrase “to flip a switch” has become idiomatic for “to do something effortlessly.”

When faced with a minimalist design, the feature nazis often protest that we have not left enough room for “user-friendly” customization. What if the customer wants to do something different than the simple on/off? I suppose this is where the idea of a dimmer switch came from.

Perhaps the idea of a dimmer switch does not seem like much of a crime to you. I admit that they generally are not hard to use. But let’s consider a slightly extreme case. A few years ago when we lived in the Chicago area we had a fancy master bedroom with one of those cathedral ceilings. At the peak of the ceiling above the bed there was a ceiling fan. The fan was great. On warm summer nights it added just enough circulation to the room to allow for comfortable sleep without having to crank up the air conditioner. But as much as I liked having the fan there, the switch was a nightmare.

Four buttons comprised the switch. The top button was for turning the light off and on, and for dimming it. The second button was for turning the fan off and on and adjusting its speed. The third switch changed the direction of the fan’s rotation (one direction to blow air down for a cooling effect, the other to recirculate the air in the room without blowing on us directly). The bottom switch turned all power to the fan and light on or off.

The first problem with this design was that these buttons all looked and felt the same – and did not change position when they were in the on or off state. As a result, it was hard to tell whether the light and the fan were off because the main power switch was off, or whether the main power switch was on but both the light and fan had been turned off individually. Thus, the simple act of turning on the light sometimes took as much as three button presses (cycle main power off and then on, press dedicated light power switch). This annoyance alone was enough that my wife and I had to establish some new etiquette for the light: never touch the main power switch. In addition, the sameness of the buttons made it easy to fumble them in the dark. On more than one occasion I accidentally turned on the light and woke up my wife when I had meant to turn on or off the overhead fan.

The next problem was with the two buttons that acted both as on/off switches and as dimmers. Both buttons functioned in the same way, so I will use the one for the light as an example. Pressing the button quickly cycled the power on or off. The switch had a memory that kept track of the last brightness level, so if you wanted to alternate between off and that brightness level (which was our normal preference), this was the way to go. However, the button was soft and squishy. Sometimes I would push the button thinking I had depressed it enough to turn on the light, but nothing would happen. As a result, I got in the habit of mashing the button and holding it there for a bit just to be sure. The problem was, holding down the button caused the switch to go into “dimmer” mode. That is, if the light was off, pressing and holding the button made it turn on at its lowest brightness level. Hold it for another half second and it would get a little brighter; keep on holding and it would cycle through six levels of brightness until it was at maximum power. Unfortunately, when the light was already on pressing and holding the button did not cycle the brightness, it only turned off the light. As a result, often I would attempt to turn on the light, only to find that I had held it too long. The light would come on at its weakest brightness. But then rather than allowing me to press and hold to increase the brightness, I would have to turn off the light, and try again. There were times when it took me several seconds to turn on the light in the room. I felt as if I was becoming hypertensive.

The end result of this design was that we had all of the customization we wanted – six different lighting levels, six different fan speeds, and the fan direction switch together gave us seventy two unique permutations. But I would have been much more satisfied with a traditional on/off switch for the light next to a dimmer switch for the fan (because sometimes it is nice to be able to adjust fan speeds). Incidentally, this setup is exactly what we had in the other bedrooms in the house – the ones where fixtures were a little less “high end.”

I tell this story not to illustrate how much I fumble with light switches, or to say that the switch in our master bedroom was particularly incomprehensible to me. I understood it, and most of the time I could make it do what I wanted. But sometimes it gave me grief. I did not tend to dwell on it at the time, but there were some real inconveniences. Looking back, I am a little surprised that I did not eventually replace the switch with something more simple, but perhaps it was not worth that much effort. I will say that ever since I have thought much less of that particular brand of ceiling fan.

So, less is more, and simpler is better. Sure, these are trite phrases. But then it is all the more amazing how rarely we actually live by them.

Yesterday I argued that one of the difficulties in designing for usability is fundamental tension in the design process, for example as a simple interface requires complex implementation, or that different people react differently to the same interface. Today I would like to explore the problem of usability from a business perspective.

Once again, I think we need to begin by examining the subjective nature of usability. From a business perspective, the problem with subjectivity is that it is hard to measure. In other words, it is hard to know when we have a sufficiently good interface, or to compare two different approaches. Yes, there are means to make these judgments, but they are expensive and time consuming.

The real issue with subjectivity is that, while usability is subjective, many other aspects of design are not. For example, it is easy to quantify the stability of a program: we can track the number and recurring frequency of bugs, for example. We can quantify the number of features in a given design and justify a particular feature or feature set by describing a target market and the cost of implementation. We can measure application performance in terms of execution time, memory usage, and storage footprint. All of these things are relatively easy to do, and each provides useful input into business decisions.

In fact, the problem may be that all this other information crowds usability out of the design equation. For example, it is much easier to quantify a trade-off between extra features and application execution speed than it is to quantify the trade-off between extra features and usability — largely because it is hard to quantify usability. As a result, we push usability aside – or at least we are tempted to say that it is “good enough.”

Unfortunately, the result is that we tend to overlook the importance of usability. Usable design benefits not only those that have difficulty learning a new technology, it also benefits people who can make do with that technology but perhaps could be more efficient in their actions.

In fact, the existence of consumers with differing skill levels has led some to say that usable design should consider two different extremes: how to make an application accessible to novices, and how to enable shortcuts for “power users.” The classic example here is a menu bar. Individual menu items lay out the possible functions for the novice user to browse, while keyboard shortcuts allow the power user to continue typing without having to move one hand over to the mouse or trackpad, navigate to the menu and select the desired command.

While I understand the logic, I think that this rationalization is a bit of a compromise. To me, the most usable designs will help the novice and the power user simultaneously, rather than offering different systems for them. Instead of keyboard shortcuts and menus, what if the application suggested appropriate actions based on context? Then the power user could focus on the task at hand rather than remembering keyboard shortcuts, and the novice would have immediate access to relevant functionality without having to sift through an array of menu choices.

The traditional approach to usability is to layer it on as an afterthought. First, start with the functionality that we need to bring in as many customers as possible, and then we will get creative and figure out how to present all those functions in as logical a way as possible. But if usability really matters, why don’t we trim back the functionality to its core and then figure out the best way to implement and to present that functionality so that consumers reap the greatest benefit?

It may sound as if I am arguing that function follows form, but I am not. Instead, my question is whether the proliferation of functionality (with the noble business goal of elbowing out competitive products and addressing ever-larger markets) should be prioritized over making the basic purpose of the application or device as accessible as possible. Then, once we have a foundation that is usable, it should be easier to maintain usability as we layer on more functionality.

I believe this is the approach Apple has taken with the iPod, and the reason it is so successful. They started with something simple and basic – a music player. No color screen, no fancy animations, no video. Just a relatively large amount of storage, decent sound quality, a conveniently sized package, and easy synchronizing with a computer. Later came the other improvements. Now the iPod line includes many of the other bells and whistles – color screens, fancy animations, video playback, even (if we include the iPhone in the mix) phone calls, web browsing, email, etc. But the device continues to be easy to use because the foundation was usability. There is a lesson here, but I wonder if we are ready to accept it.

 

In yesterday’s blog entry I wondered aloud why digital photo sharing is not growing more rapidly. I hinted that perhaps the reason is that it is not as easy as it should be.

In fact, ease of use — usability — is something that everyone seems to want, but few people are able to provide. Why is that? What is so hard about making things easy? Perhaps if we understand why usability is so elusive, we can find a better path to attain it.

To start, we have to acknowledge that usability is subjective. Things that are second nature to me (computers, cars, digital video recorders) are beyond my grandmother. Likewise, some older practices (Morse code, farming, penmanship) and some newer ones (preteen IM chat, pet health insurance, High School Musical 1, 2) have not clicked with me, either. But this subjectivity is not only generational, it is also experiential or cultural. For example, in many Western cultures white is a symbol of purity, and therefore popular at weddings. In some Eastern cultures, it is a symbol of death, and therefore only worn at funerals. Well, maybe those are the same — but you get the point.

The subjective nature of usability is problematic for two reasons. First, it means that a particular interface or design may be intuitive to one slice of the population, and confusing to another. Second, it is costly to measure – requiring focus groups, behavioral analyses, and statistical sampling. The design reality is that nothing will be completely intuitive to everyone, and we may never be really sure what the optimum design is.

Rather than deal with these problems, most organizations instead choose a top down approach. That is, they anoint some usability “experts” to determine the best design, to find the appropriate balance.

There is good reason to take the expert approach. Not only do they save time and enable relatively rapid development progress, knowledgeable experts also have a deeper understanding of psychology and ergonomics, allowing them to see things that technology consumers cannot identify even for themselves.

As I see it, however, there is one major problem with the expert approach: that is, experts must at once be well versed in the details of usability and design, and at the same time have enough empathy to understand how a true layman will react. Sadly, the more expert we become in a particular area, the less empathy we seem to retain for those who come with a fresh perspective.

In fact, this is one of the fundamental problems of usable design: it is always a balancing act between opposing goals. There is no single solution for usability, no way to mathematically derive the appropriate answer. Instead, usability is a tenuous mix — an unstable solution — of opposing themes. Only true artisans seem to have the capacity to weigh all of the considerations and propose appropriate solutions.

Thankfully, there do seem to be ways to learn appropriate design principles even if we do not have this aptitude. But a more in-depth discussion of these methods will have to wait for another day.

Do you snap your pictures digitally? Increasingly, most of us do. It’s not too hard to find a decent point and shoot digital camera (name brand, 6-7 megapixel resolution, optical zoom) for $250 these days. A good, digital SLR body costs less than $1000, and many of our cell phones have built-in cameras, as well.

But what do you do with your pictures after you have taken them? Do you still go down to the photo store to get them printed? Do you print them at home on a photo-quality inkjet printer (the kind where an ink refill almost costs more than the printer itself)? Surprisingly, even though we take a lot of digital photos, we still seem to have a strong desire to print them. According to a recent InfoTrends study, we printed well over 13 billion photos last year Рnot including those prints from traditional film negatives. At the same time, another InfoTrends study shows that we only shared 8 billion digital pictures.

Of course digital photo sharing must be growing faster, right? Catching up to traditional photo prints? Well, yes. But not at the rate you might expect. These same studies conclude that photo printing is growing at about 3% per year, while digital photo sharing is growing at a tepid 8% per year.

Where is the digital photo revolution? Why are we still shelling out $0.12, $0.15, or even $0.20 per print for photographs, when we have complete digital freedom to share, view, and archive them as we wish?

Perhaps the answer is that these activities — sharing, viewing, and archiving — are not yet as easy or satisfying as they need to be. For example, of the 8 billion pictures we shared digitally in 2006, the most prevalent method of transmission was email. But anyone who has ever waited in frustration for the download of a 10MB message (assuming your mail provider allows 10MB messages!) containing a dozen photos knows that email is not the best sharing medium.

Archiving is similarly problematic. Those of us who have experienced a hard disk crash or lost important computer files through other means know that keeping a single copy of our pictures on a desktop or laptop computer is not enough. But how many of us actually take time to back up or archive our digital photos? I even have friends that leave their pictures on their cell phones or cameras rather than deal with uploading them to a PC. For some of these, printing is a means of ensuring that at least one copy of each picture survives the next computer upgrade or accidental folder deletion.

Maybe — just maybe — if there were something that could improve our experience with digital pictures, something that could make it easier, more satisfying, and more secure to share, view, and archive our digital photos… Maybe then we would stop wasting all that money, time, and space on photo prints. Is it possible to bring about the rest of the revolution? Or will our transition to an all digital world take place slowly over the next generation or so? Is there any reason to take things slowly?