ThinkFlood Blog

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.