Today it is accepted as fact that the more intuitive a user interface, the better the user interface. Perhaps the most poinant realization of this is the popular book, "Don't Make Me Think!" in which the author emphasizes design of user interface that stress simplicity over complexity, the obvious over the obtuse, and discoverability over efficiency.In a meeting with some Human Factors people a couple years ago I suggested that a particular feature for a productivity application would be more effective if users had just a little training in how to use it. The reaction from the Human Factors folks was warm, but condescending. "No", they explained speaking very slowly for my benefit, "if its not totally obvious than its not going to work." This is the kind of dogma I encounter on a regular basis and to be perfectly honest its placing sever limits on the potential of human-computer interaction.
To be clear, I agree that any application or web site that will be used infrequently by end users should be extremely simple to operate. You shouldn't have to be a rocket scientist to understand how to shop at the Gap.com. I also agree that the features used the most by beginners should be discoverable and obvious. You don't want people buying software or a device and having to study a manual to do the most common things. For example, if you buy a cell phone but can't figure out how to dial a phone number, the device is poorly designed.
Where I don't agree with the "Don't Make Me Think!" dogma is with productivity applications. Applications that are used every day by users to accomplish a task. In this case, its better to aim for efficiency than discoverability. Discoverability should be reserved for a very few features which are used most frequently by people new to the interface. Everything else in a productivity application should be designed for efficiency.
About a year and a half ago I wrote an article hosted on SYS-CON media entitled, "Engelbart's Usability Dilemma: Efficiency vs. Ease-of-Use" in which I talk about Douglas Engelbart - who invented the mouse, windows, word processing, and hyperlinks - and how his theory of human-computer interaction actually ran counter to the dogma of "Don't Make Me Think!". Engelbart invented the mouse through human-factors studies and chose it as the best pointing device not because it was the easiest to learn or the most discoverable, but because it was the most efficient. The same is true for word processing, hyperlinks, and windows which he and his research associates also invented. In my April 2008 article on Enelbart I wrote:
This philosophy is the core of Engelbart's Dilemma. I explained this in that same article:
"According to Engelbart, in order to achieve the best human-computer symbiosis – an objective that is central to his Augmenting Intellect philosophy – users need to be trained to use the most efficient computer artifacts (e.g. pointing devices, keyboards, etc.). Engelbart did not believe that computers should be easy for novices to use; he believed that people would require lengthy training in order to be truly effective. Specifically, he wanted computer interactions to be based on systems that, with considerable training, were the most efficient – not the easiest to use."
"Engelbart’s dilemma is that his philosophy produced some of the best computer technologies of our age (e.g. mouse, windows, word processing, etc.), but the full realization of his vision is completely counter to way interaction designers think of computers systems today. In fact, Engelbart's belief in efficiency over ease-of-use places him in the fringe of computer interaction design today. That’s sad considering he’s done more for interaction design than any else I can think of."
Today, Engelbart while revered is also regarded as somewhat of a "Crazy Professor" because although the rest of us have decided that discoverability is the most important aspect of UI design, he still believes that efficiency matters more than discoverability.
Although I'm not an extremist, I have to say that as I develop and design user interfaces I'm becoming more and more convinced that, at least for productivity applications, efficiency is far more important than discoverability. Call me an Engelbartean.
As an Engelbartean I'm very concerned that the designers of Natural User Interfaces are focused far too much on discoverability and not enough on efficiency. While it makes sense to design multi-touch tables and walls used in public venues so that they are as intuative as possible, that same design philosophy should not be applied to multi-touch productivity applications. While I agree that the tasks most commonly preformed by beginning users should be easily discoverable, I don't think that all tasks should be easily discoverable. For example, in the development of multi-touch applications the emphasis is on designing gestures that are as closely aligned with real-world gestures as possible. While this works well for some gestures, such as moving items on screen or scrolling by moving the page up with your finger, it doesn't apply to one of the most praised interactions, pinching and stretching. Pinching a photo to make it smaller or stretching to make it larger is not intuitive despite what people say. It's a very learned behavior. People don't expect to be able to resize things on screen with their fingers. Other than playdouh what do people pinch to make smaller in the real-world? This is not a discoverable gesture, its a learned gesture.
Now, just because a gesture or interaction method is learned doesn't mean it has to be difficult to preform. In fact, it should be easy to preform and it should provide the most efficient method for preform a specific kind of task. But learned interactions fly directly in the face of discoverability and that's what so interesting. Learned interactions, if designed properly, enable an extremely efficient and engaging human-computer interaction.
The proper way to design a human-computer interaction is to make a few things discoverable and totally intuitive, but only a few things. Only those things that user new to a productivity application would need to do right out of the box. Everything else should be emphasize the most efficient method of interaction in order to expose the greatest number of features and capabilities. If you can only use those features which are discoverable, than you are not going to be very productive in the long-term. Every tacit task requires a certain level of mastery in order to deal with the nuances of the real-world. Nothing is cut and dried.
Today, however, the idea that interactions should be learned; that we should emphasize efficiency over discoverability is heresy. If the method of interaction for a specific feature cannot be intuitive and discoverable, than the feature should not be included. The result of this kind of thinking is that the human-computer interface is becoming more discoverable and intuitive at the risk of also becoming less effective. Rather than trying to make people more powerful through software and devices, we are just catering to the lowest common denominator. We are designing tools for monkeys, not humans. In that April 2008 article I wrote in my conclusion:
I once heard or read (I can’t remember which) that Engelbart compared his interaction system to that of the violin. In essence, he said that the violin is an awkward instrument for novices but that, with training, a good musician can create incredibly beautiful music. My son trained in the violin for a couple of years, and I can attest to the amount of practice it took to master even simple melodies, but I’ve also seen good students play music that moved me more than any other instrument I have ever heard. Perhaps, like the violin, people could reach a new level of synergy with computers if they followed Engelbart’s philosophy and focused on efficiency over ease-of-use.A year and a half later I still believe what I wrote, but I think the situation is more dire than expressed in the quote above. I think if we were following the dogma of "Don't Make Me Think!" in the development of musical interments we would have stopped innovating after developing the hollow log drum.
The truth is we may never know if Engelbart is right, because the computer is the province of the masses and not just expert users. If we were designing a musical instrument today, our focus on ease-of-use and learning would probably lead us to the kazoo rather than the violin.
4 comments:
I definitely agree with you, but then we seem to work in a profession where people are constantly taking good advice to the extreme, without realizing how that negates it.
I think differentiating between discoverability and efficiency is a bit too narrow. That tools are "discoverable" is only true within the context of the people knowing and understanding the prevailing "abstractions" on which the tool is based. No matter how nice the interface, my 95 year old grandmother is never going to "get" the paradigm. In that way, to "discover" we need exposure to the "abstraction". Once within that context, then the rest should be fairly obvious, as it consistently and expectantly builds on the basis of the abstraction.
In that sense, if the paradigm is based on single actions, then optimizing it for discovery means optimizing it for one-at-a-time operations, which is inefficient. If the paradigm is based on bulk operations (such as early UNIX shell scripting), then once you understand the abstraction you can "discover" things to do "intuitively" that are efficient.
Our problems stem from the fact that we left batch processing environments (scripts, command lines) for single item processing environments (mice, GUIs). Sure our interfaces for the later are more explicit (and thus easier to discover at a faster rate), but the earlier stuff was not explicitly more complex IF you understood its underlying philosophy (abstraction). We quietly traded away efficiency long before we even started harping about discoverability.
What we should do is find a way to bind back the "bulk" operations into these new natural interfaces. Not only would that fix the problem, it would also provide sufficient incentive for people to make the leap from GUIs to the new stuff (which is always a slow process).
Paul.
Thanks for the comment, Paul.
One of the "batch" systems we have had for a while is application macros (e.g. MS Excel). There has been a lot of work in this area to see how we can make macros easier for end-users to create. I think this has been met with some success but limited to power users.
With an emphasis on developing skills, macros in NUI could be pretty nice for productivity applications. Imagine being able to stitch together primitive operations and assign them to your own gesture?
Personally, I think this works better for voice input. For example, "Send to Flikr" would cause a photo to be uploaded to your personal Flickr account without any other commands.
I spoke a while back about how gestures and speech commands can be based on primitives that can be put together to form larger operations - I made an analogy between this and spells.
Here is a link to that post
http://theclevermonkey.blogspot.com/2009/05/magic-as-metaphor-for-nui-design-part-2.html
I have to say first that I'm very happy that someone pointed out this post to me. In my opinion it has been the most interesting and sane posting about designing UIs that I've read in at least one year - or even more.
I'm a strong believer in efficiency over learnability, and the GUIDe / GDD design methods that my wife, myself and others have developed, taught at universities in Helsinki and used in UI design projects reflect this preference.
I have an plausible explanation for the domination of learnability especially among usability professionals: it is the one and only attribute that can be understood from a UI design draft without any knowledge of the actual workflows that the UI is supposed to support. In addition, usability tests bring up almost nothing else than problems in learnability. Thus, from the viewpoint of a usability professional, learnability becomes the main thing.
This is rather sad state of affairs, since it's possible to show that adding efficiency to an extremely learnable UI can easily destroy all the learnability, but adding learnability to this efficient UI tends to work. Thus it makes very much sense to start from an efficient UI although our target would be users that use the software rather rarely.
This is very interesting to me from an architecture/design standpoint. Design decisions should always be based on the "-ilities" (reliability, usability, affordability...), and the trade-offs you have to make in order to favor one over the other. But what I think you've nailed here (and which reverberates in a more general context) is that due to these kinds of rules of thumb, people forget that there's a trade-off being made at all. They may weigh usability against affordability, but to them, usability means "discoverability".
In this context, I think it's totally counter-productive to even attempt to say one method is right over another. The point here is that there's a finer-grained set of attributes that need to be weighed as part of usability: discoverability (i.e. the ease at which a new user can figure out how to use it on their own) versus efficiency of use (how effective and efficient can they be with the UI once they learn how to use it). As you've pointed out, this is a real trade-off, and as such, has no one-size-fits-all answer.
It's a good reminder to think about what we give up with the other "best practices" we take for granted. In an operating room, it would be unthinkable for a surgeon to enter without washing their hands. On a battlefield, in the line of fire, they'd have to be a nutcase to ask for a bar of soap before patching someone up.
Post a Comment