February 1, 2007, 10:16 am
Your. User. Is. Not. You.
By Henry Woodbury
That advice from computer science instructor David Platt could be carved in stone. It pretty much applies to everyone that makes anything for other people, but Platt has a particular target in mind. Programmers, he asserts, don’t think like users:
People who write software programs value control. The user, on the other hand, just wants something that’s easy to operate.To illustrate his point, he notes that computer programmers tend to prefer manual transmissions. But not even 15 percent of the cars sold in the United States last year had that feature.
Business executives don’t think like users either. Frankly, users don’t think like users. Here’s David Thomas, executive director of the Software & Information Industry Association’s software division:
You don’t want your customers to design your product. They’re really bad at it.
What you want to do is ask people what they want, then compare it to what they actually do.
Platt’s Suckbusters web site is here. A typically entertaining lede:
The common technique of confirmation, popping a dialog box into the user’s face and asking, “Are you really Really REALLY sure you want to do that?” is evil. It’s unfriendly, it’s distracting, and it’s completely ineffective. Have you ever, even once, said, “Whoa! I didn’t want to do that. Thanks,” and clicked No? Have you seen anyone do that? Have you even heard of anyone doing it? I haven’t. It shouldn’t exist. Anywhere. Ever.
Comments
Platt is both right and wrong.
Primarily, users want something that solves their problem. Ease of use is important, but secondary. Oddly, designers often confuse that with making something obvious for a true novice. This is a big mistake; the key should be that its easy to learn and once learned, easy to do again.
I totally disagree with Platt about confirmation dialogs and have enough experience to state unequivocally that he’s dead wrong. Most users not only like confirmation dialogs, but complain when they aren’t there.
As for his blanket statement; I have often said “Whoa! I didn’t want to to that. Thanks,” and clicked No. In fact, I just did that yesterday. (And two years ago, had a user go ballistic over me not putting such a confirmation dialog in a notes window. In hindsight, I should have with the option to never be prompted again.)
I roll my eyes at CS and UI people who declare engineers are idiots then launch into some pet diatribe. It makes me question all their assertions, perhaps unfairly.
Posted by Joe on February 2, 2007 at 1:20 pm
Joe– Platt uses hyperbole to make his points, but let’s filter the message from the messanger for a sec.
He’s actually proposing more than just doing away with the convention of confirm boxes. Instead, he proposed far more powerful undo features.
I can’t tell you the number of times I’ve clicked the wrong box in a confirmation dialog.
To think of an extreme example, imagine having to hit a confirm dialog before taking any action in Photoshop. Yikes. Yes, really crop that. Yes, really change the levels. Over and over. How much better is life since the introduction of the history pallet, where I can go to ANY previous state of the document.
Much more time consuming to program and implement. Maybe the history function needs to be built in as a library/API at the OS level, so that any application can implement it more easily.
It would take a lot of work, though, to change the expectations of users to adopt a pure “don’t worry about it, you can undo” attitude.
Posted by EB on February 9, 2007 at 10:53 am
While Platt may use hyperbole for some things, I take him at his word that ALL confirmation dialogs are evil. I have been dealing with this fringe element for years. I happen to agree with the general aims; a rich undo system is desirable. Changing a design so as to reduce confirmation dialogs is also desirable, but to go to an extreme–which MANY in Platt’s camp really are advocating (I’ve heard it from their very lips)–does nobody any good. (Plus it really is rather hypocritical to denounce engineering dogma then pronounce your own when neither serve the interests of the customer or the company.)
By the way, one problem with the “rich undo” concept is that it can be so difficult as to render it cost ineffective.
(Beyond that, there is the problem of defining what Undo is anyway–often a very complicated question, especially when working with complex data sets. Plus, there are operations that can’t be undone simply, if at all–like emptying your trash can or recycle bin. In the case of financial transactions, the undo is simply going back to a previous state, but a new transaction. Seems to me that these types of operations should have a confirmation associated with them.)
Posted by Joe on February 12, 2007 at 2:45 pm