ThinkFlood Blog

Earlier I wrote a few postings about why it is so hard to make things easy to use. I have been thinking about this concept recently, but from a different angle.

The world is a big place. It’s big enough that we have a hard time comprehending its size. Six billion inhabitants or so. 40 million meters in circumference. Modern transportation and communications make these things seem relatively trivial. Most of us today think it is rather quaint that people only a century ago rarely traveled far from home, or that six or seven centuries before that people actually believed the world was flat.

With so much out there in the world, it’s awfully hard to do something original. In fact, it’s so hard to think truly original thoughts, that when someone does and bothers to document it, we give that person a doctoral degree. (And even then, doctoral theses are starting to seem less unique and perhaps more petty.)

Perhaps as individuals we do not feel the need to be quite so unique. After all, many of us spend large portions of our lives trying to gain some level of acceptance and approbation from those around us. But for companies in capitalist markets, the rule is differentiate or die. To this end, company leaders are constantly asking themselves what they can do to distance themselves from the competition — how they can erect barriers to entry on their turf.

In fact, I believer there are relatively few true barriers. Some will argue that things like patents, copyrights, and trademarks are barriers to entry. I suppose they are — but they are particularly weak ones. Clever imitators can easily get around most of these — and that’s only if they choose to abide by the law. These methods are particularly ineffective for small companies, as most cannot afford to hire armies of lawyers to prosecute offenders (indeed, they may be struggling just to keep away illegitimate challenges).

To me, the real barriers to entry are more about doing things that others will not do. Of course there are several reasons why others may choose not to copy. One reason may be that the idea is a poor one. A company pursuing a bad business idea will generally enjoy a competition-free landscape, but that does not make it business successful. When the idea is a good one, however, others usually shy away for one of two reasons: either the work is too hard, or the work is too dirty.

At this point, I am sure there are people out there screaming at me, saying that there is another reason: that others simply do not comprehend what it is that we do. The old trade secret argument. But the fact of the matter is that trade secrets are nothing more than hard work performed only once and then protected (as opposed to the kind of hard work that is recurring). With six billion people in the world, there really is not anything stopping others from reinventing what you may have already discovered. In fact, they are just as likely to do it better — and then what value is the secret?

So, if we want to win the game, we are left with the choice between hard work and dirty work. Of course these types of work take many forms. And one of those forms is to design for usability. Because usability is not easy to achieve, it’s devilishly difficult. Usability requires making choices that are not always fully quantifiable. It requires top down innovation that sometimes rejects the results of focus groups and customer surveys. It requires leaps of faith, and gut wrenching challenges to the status quo. It requires relentless rethinking of fundamental principles coupled with rapid implementation and enough consistency and familiarity to remain almost unnoticeable to most people. Usability is one of the toughest, most precarious balancing acts around. And it is therefore a magnificent barrier to entry. No wonder most companies wish they were doing it. No wonder most don’t.

Technology has made many amazing things possible. In fact, there are even some things that were science fiction a couple of decades ago which have become relatively commonplace now — such as realistic computer generated imagery in movies, or watching a television show on a handheld computing device. But there are a lot of things that we can do that we have chosen to leave alone. Why is that?

Forbes is currently running a series of articles on the future – what we say about it, how accurately we predict it, and so forth. Among these is an interesting piece by Neil Steinberg that considers some answers to this question:

Futurism has a tendency to take the products of today and merely extrapolate them. Thus TV becomes 3-D TV, cars become flying cars and telephones become video telephones. Sometimes it takes the sanity of the marketplace to dash cold water on those technological projections. We were all going to take our nutrition in pills until someone realized that preparing and consuming food was one of the primary joys of life, and no one wants to swallow food pills.

While it seems that Mr Steinberg’s choice of a technology to critique (video phones) is a little weak (webcams have taken off, and grandparents love them), I generally agree with the principle: just because we can do something doesn’t mean that we should.

Too often it seems that technologists get caught up with what is possible without considering what is valuable. Then it seems that there is a race to see who can come out with said technology first. Perhaps the saddest thing is that often there are less cutting edge technologies that are also possible, many times ore valuable, and tragically overlooked. The important thing is to examine what people want to do with their lives and figure out how technology can enable or simplify those things. Too often we seem to find ourselves looking at technology and trying to figure out how we can change our lives to match. Perhaps with a little perspective change our rate of progress would increase.

Although I have spent plenty of time around software developers and other IT types, I cut my teeth in sales and marketing. As a result, it always bothers me to hear people disparage the money end of the business by calling the good people out there cheats and liars. People in IT departments seem particularly annoyed at the folks in sales — it’s even kind of a major topic in Dilbert.

Now, I have to admit that there are salespeople out there that make my skin crawl. Indeed, I run the other way when I meet up with someone that can “sell ice to an Eskimo.” I’ve never liked feeling that the guy on the other end of the bargaining table was trying to pull a fast one on me, and I don’t enjoy haggling and the other games that people play.

Of course some people seem to enjoy the back and forth. My wife is one of them. Before we got married we stopped by a local jewelry store to pick out our wedding bands. We were there for quite some time, trying on different styles and sizes. Finally we found comfortable rings that we both liked. The store clerk that was helping us went to the backroom for a minute to get something, and my wife elbowed me.

“We should ask for a discount.”

“A discount? Why?”

“Because we’re buying two of them.”

“But everyone buys two wedding rings. That’s kind of the point.”

As soon as the clerk returned, my wife spoke up and asked for a discount. The clerk looked a little startled, and I’m sure I blushed. But then she said, “Okay, I can give you 10% off.” And so we saved some money.

The issue is that, to me, good salesmanship is all about trust — not something contrived, but real trust based on empathy and understanding, and delivering something that has value. I like to think that the product works as it is supposed to work, the price is what it is, and people buy if they feel that the value of the product meets or exceeds its price.

So I have to say that I really despise the classic “bait and switch” style of sales. While this may sound more like something that a con artist does than real-world, legitimate sales strategy, just about everyone is familiar with the concept of a “loss leader” or the “razor and blades” business model. To me, these are one and the same. Bring someone in under one pretense, and then commit them to something else that is more profitable. It is all about hidden costs and deceiving the customer, and I think it stinks.

Of course none of us is so naive that we underestimate what is going on. When we get a cellphone below cost from a wireless provider, we know that they aren’t offering charity — they are going to make all that money and more from us over the next couple of years while we are under contract to continue to use their service. But the relationship that this creates between buyer and seller is miserable. We will always feel that the service provider is trying to find a way to bump up costs on our monthly bill. And because we feel robbed of our freedom to walk away if their service turns out to be worse than we had anticipated, we are likely to be frustrated at even the most minor of service failures or inconveniences. Intuitively we understand that there is a disincentive for the service provider to do much to retain us, because our switching costs are high and so our tolerance for pain is also relatively high.

To me, this is all really an issue of usability. Or rather, usability is one way to evaluate the relationship between buyer and seller. It starts with the original purchase decision, and continues until the product is no longer useful or the term of service is over.

To me, loss leaders violate the usability principle of clarity, because they obscure the actual cost of the offering. They may also violate the principle of reliability, if there is confusion about the functionality or lifetime of the offering.

When it’s all said and done, as a consumer I will always choose the product that makes me feel most at ease. Though I might have to pay a bit more, at least I will not be looking over my shoulder wondering when it is going to break or when I will have to shell out more money for some adjunct service to make¬†the purchase worthwhile. As a vendor, I will always prefer to have my customers walk away feeling that they have chosen a product on its merits and paid a reasonable price, because then they will be most likely to recommend me to others, and to return to me in the future. In my opinion, this is the only sustainable way to do business.

Steve Jobs has gone on record at least a couple of times recently quoting from Alan Kay: “People who are really serious about software should make their own hardware.” I think this is especially true when it comes to usability.

The mainstream arrival of the Internet over the last dozen years or so has brought about some amazing changes. Not least among these is the ability for motivated entrepreneurs to build and bootstrap new companies at unprecedented rates. This is a great thing for innovation and our economy, and I hope that it continues.

But there is one thing about the proliferation of these companies that bothers me: it seems that many people have begun to expect that great things can come easy. Now, I am not trying to belittle the hard work that these entrepreneurs are putting into their businesses — certainly it is no small task to start and run a successful business in any space. And certainly there are some great ideas out there that seem to be just made for the Internet experience through a browser. But in many cases I feel that we are compromising — sacrificing the ultimate goal of the product or service in order to make it run in a browser and to keep down startup costs.

For example, I am struck by the sheer number of photo sharing websites — by my count, there are more than three dozen of these out there right now. I suppose this is not surprising, because writing a basic photo sharing application is not too hard. As a result, many of these services are free (i.e., ad-supported), require occasional purchase of photo prints, or charge a relatively nominal fee. But given the sheer number of competitors and sometimes questionable revenue streams, it is easy to see that a day of reckoning will come relatively soon — only a handful of these services will survive.

I suppose this “natural selection” among competing services is good for consumers and everything, but I wonder if we are not simply headed for a mediocre solution. In other words, is a browser application really the best way to share pictures? Sure, browsers are ubiquitous, so just about anyone can participate. And personal computers today have graphics capabilities that are more than adequate for transmitting, storing, and displaying pictures. But is the ideal photo viewing experience a laptop monitor? Is it really so convenient to upload pictures one by one, or even with a batch upload utility as are available on some sites? And why do I have to fire up a web browser and navigate to a particular URL rather than have my pictures come to me?

I’m sure there are people who will think that I am crazy for saying that it is annoying to have to deal with life through a browser window. You may ask, “What could be more simple?” But the fact is that many companies are beginning to acknowledge that it is hard to exist as destination web sites. Indeed, social networking sites are all the rage right now because they garner such a large percentage of people’s time spent online. Other companies (even Internet juggernaut eBay) are struggling to cope. And then there is a whole contingent of people — mostly above the age of 35 — who simply do not have time to spend futzing with MySpace or Facebook pages.

The way I see it, social networking is only one step along a path. In the earlier days of the World Wide Web, academia opened the doors with online catalogs of information. Then came Internet-based retailing. Around that time, most businesses began to put up websites to provide information on their particular products or services, and perhaps to attract investors. From there it was financial institutions and some digital media clearing houses. Now it is social networks.

I’m not sure what the next step along this path will be, but I do believe that someday soon we will start to see the Internet shed its browser skin. I’m not talking about viewing web pages in miniature on mobile phones, either. Instead, I believe that eventually we will see more products and services offered over the Internet in specialized packages (the buzzword for this ten years ago was “Internet appliances”). The reason for this change will be usability.

We already see moves in this direction today. For the past couple of years there has been a movement to help browser-based applications break out of the static linked-page metaphor. Flash and AJAX accomplish this to some degree, and we now see the likes of Google and Microsoft battling it out to figure out how traditionally “rich client” applications such as word processors can benefit from being connected over the Internet. But I think the transformation will be more fundamental than this. While I believe there will continue to be a place for our multi-purpose personal computers, I also think that we will see a proliferation of more specialized devices. In the same way that a chef does not prepare a meal using a Swiss Army knife, we will stop trying to shoehorn many tasks onto our laptops, desktops, and cell phones. Instead, we will choose the form factor (i.e., hardware) that makes the most sense for that particular application.

Unfortunately, it is hard to say when this change will take place. Personally, I believe that the building blocks are there. WiFi networking is everywhere, and it only costs a couple of dollars to build WiFi into a device, so it should be easy to get these devices online. And we have been putting small computers into increasingly more mundane devices for at least a couple of decades now. But I fear that one thing standing in the way of this change is the mindset among entrepreneurs. Many see that it is relatively easy to get funding if they can scape together a beta version of a browser-application on their own. By contrast, prototyping a hardware device and writing software for it (in addition to the server-side software for the service itself) can cost hundreds of thousands of dollars.

But I believe the fact remains as Mr Kay stated it, that those “who are really serious about software should make their own hardware.” But then I’m not going to wait around for others to figure this out, either. To take another famous line from the same speech, “The best way to predict the future is to invent it.”

I’ve gotta go — lots of work to do.

Consistency is another one of these principles — right alongside what I’ve called “familiarity” — that seems to automatically make most people’s list of usability concepts. It’s a relatively easy case to make: consistent design can make it easier for people to navigate new applications and new functionality, while inconsistent design often confuses.

As with familiarity, I also believe that consistency is an important principle — one that we should try to implement where possible — but I also worry that consistency taken too far can be problematic. As Mark Twain said, “To a man with a hammer, everything looks like a nail.” If we find ourselves struggling against reason to shoe-horn a design into our favorite mold, we should step back and reconsider.

To me, the problem with consistency — and the reason it comes last on my list — is that it does not really solve any problems. In other words, consistency alone does not make interfaces intuitive, it only helps us if we already understand the original intent. That said, consistency can be a big help to “expert” users (for example, keyboard shortcuts for cut, copy, paste, undo, open, close, and new are just about the same in most graphical applications today), and lack of consistency can be a real problem.

Consistency is relatively easy to achieve in software applications today. Back in the mid 1980s, Apple began publishing a series of books called Inside Macintosh. The early books in the series read like a style guide for GUI applications – how many pixels tall the title bar in a window should be, the proper offset for buttons, how to implement text scrolling, etc. Later, however, these books morphed into documentation for the Application Programming Interfaces (APIs) that Apple provided to developers as part of the operating system. Today, few developers bother to challenge the building blocks of user interface, instead choosing to rely upon the APIs built into the operating system. While this approach has dramatically accelerated the rate of GUI application development, it also presents a barrier to customizing interfaces around a particular task or function.

On one extreme, HTML makes it particularly easy to achieve a consistent user interface with minimal effort. A few words in a text document are all that we need to program our browsers to spit out buttons, text boxes, labels, check boxes, and drop down lists. On the other hand, these tools are not always appropriate, and it is in many ways harder to implement a custom control on a web page using JavaScript than to make a custom control for a Windows, Mac, or Linux desktop application. The other extreme may be video games, where user interfaces are often unique to each game. On the web, content seems to matter more than interface; in the video game, interface matters as much or more than content.

So, what’s the answer? When should we strive for consistency, and when should we break the mold to deliver a unique interface that is optimized for an application? I believe that we should consider consistency alongside one of the earlier usability principles: proximity. Given two conceptually proximate functions (for example, undo, cut, copy, and paste are nearly universal functions today), we should strive to maintain a consistent interface (in this case, the same keyboard shortcuts, placement of these commands at the top of the Edit menu).

I have written about the iPhone before, so please forgive me for bringing it up again here. One thing that I like about the iPhone is that its interface is tailored to the device. The home screen is reminiscent of that other easy to use device, the Palm Pilot — with application icons laid out in a grid, the four most major of which run along the bottom of the screen. By contrast, the iPAQ/PocketPC/Windows Mobile interface stubbornly retains the Start menu, a Desktop, a Control Panel, and windows stacked in Z-order throughout the operating system. Personally, I do not feel that these patterns work nearly as well on a small screen and without mouse or keyboard as they do on a regular personal computer. However, I think it would be confusing if devices like the iPhone or the Palm Pilot had strikingly different interfaces within each application. Thus, functions that are proximate to one another — physically (i.e., on the same device) or conceptually (i.e., playing the same role) — should have similar interfaces. The further apart two functions are, the more we should be willing to tailor their particular environments.

Responsiveness may not seem like a usability principle on its surface — generally the solution is more about technical implementation than an elegant design or some principle of cognitive science — but who among us does not get frustrated from time to time when waiting for the hourglass cursor? More than mere annoyance, devices that are slow to respond can hinder our productivity and creativity — we lose our train of thought while we wait, and then it takes some time get back to where we were, if we ever arrive there at all.

People have been comparing the Macintosh and Windows operating systems for a couple of decades now, but to me one of the biggest differences between the latest and greatest of these (Vista and OS X) is responsiveness. Macs boot faster, launch applications more quickly, and generally respond to mouse clicks and keyboard input with a fluid-like simplicity that defines elegance. Most Linux distributions are also relatively zippy — even when running on yesterday’s hardware.

Of course we may be able to trace some of the slowness of Windows back to a lack of minimalism — after all, this is the operating system for all devices, from the cell phone to the supercomputer — but there is more to responsiveness than simply streamlined application code.

Without access to source code I have no real way of proving what I am about to say, but in observing the Mac OS, it seems to me that some of Apple’s gratuitous animations have more purpose than simply evoking a “wow” factor. For example, consider what happens when we launch an application. At the very least, the operating system has to load the application into memory, and in memory-constrained situations it also has to page out other applications to make room. Then there are application initialization steps (Adobe applications are notoriously slow here), which may involve caching information from other files on disk, opening network connections, or even initializing devices.

In the Windows world, when we launch an application nothing much happens right away — depending on the vendor, the software may display a splash screen, but generally we wait while the program launches. Even worse, in most cases the outline of a window draws, but the display freezes or slows while some preprocessing takes place before the rest of the screen is painted.

The Mac is a little different. An icon in the dock begins to bounce, and continues to do so until the application window comes up. And when the window appears, it draws to completion without an appreciable pause in the middle. Do Mac applications launch faster? Somewhat. But more than a faster launch, there are clues to us that something is going on. That is, rather than sit and wonder whether the application we have just tried to launch is in the process of coming up, we can see the bouncing icon and know that help is on way.

Now, I’m not a huge fan of the bouncing icon trick, but the point is that this action is a means of communicating with the user, which has the effect of making the whole process seem more immediate and responsive. Some may ask what the cost is. After all, we would not want to slow down the process further simply to make things look better, right? In fact, however, the things that take the most time during application launch (reading the program from disk, paging out other applications, opening network connections) require relatively little muscle from the central or graphics processing units — they are I/O-limited operations. Why not use a few of those spare processor cycles to entertain/inform the user of what is going on?

In fact, there are a handful of controls that we rely on for this kind of operation, such as the aforementioned hourglass (or wristwatch) cursor, animated spinning wheels/beachballs, and progress bars. Of these, I prefer a well-implemented progress bar, because it actually gives me an idea of how long I will need to wait.

In addition to these small animations, however, there is another point that I was trying to draw out, and that is the issue of screen refresh. Not only does it look poor when a window begins to paint but then freezes, it also begins to remind us of how applications look when they crash. To me, a half-painted window always seems to be a sign of application instability — an uneasy feeling that I could do without. Rather than rush to paint the outline of the window, why not provide the intermediate animation for a little longer, and then paint everything at once?

Responsiveness takes a backseat to many of the other usability principles, because it does not help us learn or understand an interface better. However, certainly a slow application can be the cause of much frustration and even confusion, so we should be mindful of this principle in our designs. At the very least, when our applications do require some extended processing or waiting time, we should provide feedback and status information to keep users informed.

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.