April 9, 2009
When it comes to user interface design, I'm no guru, but I do have one golden rule that I always try to follow:
Make the right thing easy to do and the wrong thing awkward to do.
The things you want users to do should be straightforward and clear -- as simple as falling into the pit of success. Make your software easy to use. Duh. Everyone knows that. The less obvious part of this rule is that sometimes there are things you don't want users to do. In those cases, you actually want your application, or at least certain areas of it, to be harder to use. For example, operations that are risky or dangerous should take more steps.
What you're doing with this design technique is training your users:
The central lesson I learned from exotic animal trainers is that I should reward behavior I like and ignore behavior I don't. After all, you don't get a sea lion to balance a ball on the end of its nose by nagging.
When you make features easy to use, you are rewarding user behavior you like. You are guiding users through your application, giving them a clear and obvious path of least resistance. And when you intentionally choose not to make a feature easy to use, you are effectively ignoring user behavior you don't like. You are indirectly discouraging users from utilizing those features.
If you aren't taking advantage of both techniques in your user interface -- rewarding with simplicity, and (judiciously) ignoring with complexity where necessary -- you aren't properly training your users.
Posted by Jeff Atwood
Q: What to walruses and and ball bearings have in common?
A: They both like a tight seal.
I agree and already try and do that as much as possible.
BUT -yes there is a but-
This idea only works as long as the user uses your site or software. If the user feels he *really* wants to use some feature he likes and you don't, he will try just about anything to do it his way. And if that means visiting another site or using another software, so be it. And once he's *out* of the game, it's pretty tough to get him back.
Sorry, I'm not trying to span you but for some strange reason google chrome didn't show my comment after I made it. Weird!
Donald Norman also mentions these things in The Design of Everyday Things: Deliberately making things difficult.
90%+ of users use default settings.
That's the most obvious way to direct users to desired path.
E.g., give users email me notifications checkbox, but make this checkbox selected by default.
Jeff, why don't I see email me comments checkbox on www.codinghorror.com?
Are you encouraging us not to subscribe for follow-up comments to your posts?
What are a few examples of things you would want to make difficult for your users?
There is a pitfall to this, which is that if you misjudge the common use of the application, you train users to ignore the obstacles you place in their path, and frustrate them, to boot.
Hey Now Jeff,
Nice post! It's kinda like how SO has so many tooltips.
Coding Horror Fan,
What are a few examples of things you would want to make difficult for your users?
A very basic example: want to discourage users from spamming your forum. So you require them to sign up for an account before posting. That's intentionally choosing complexity, vs. the simpler method of just start typing and click save!
What are a few examples of things you would want to make difficult for your users?
Behavior you want to encourage in users is really dependent on the application. Say if you have software that monitors various devices and sensors in a power plant. You want to make it very easy to add/install a new device to monitor in the system but you don't want it to take one click for them to completely wipe out all the devices monitored in the system but it should be possible.
If you're writing a text editor then you'll have a completely different set of user behavior that you may want to promote so it's difficult to give clear cut examples.
I find this to be equally true as well in soliciting project requirements and planning maintenance. Guide the users toward the simplest solution that will solve the problem or add value to the application. Of course, it really helps to not only have good working relations with my multinational user group, but also to have a proven track record of successful deliveries (Go me!).
Errr.... but what if your views about what your users should want to do differ dramatically from what your users want to do? How do you determine whose views take precedence? Is ignoring dangerous behavior really appropriate ó what about actually putting in steps to stop it?
I get rewarding. But ignoring? I don't get. Training even with animals is about both the stick and the carrot. Ignoring is not a stick ó it sends an ambiguous message.
This works well, except for those users who want to perform an advanced task. Often times application developers not only make the advanced task difficult, but they make it impossible.
Take, for example, the huge number of Windows options that can only be adjusted by modifying the registry. Although this isn't impossible, it is effectively impossible to adjust options through the standard configuration process.
In short, being user-friendly means being friendly to ALL users, not just the average Joe.
Hmm. So, fan of UAC?
I must admit, the way it bickered when an application was saving settings in Program Files was an incentive for developers to correct the manner of their applications. But a user could make their life easier by _turning off_ UAC.
Which brings up admin accounts: The whole make-it-easier/make-it-difficult might fall down for the idea of administration. Admins do the path you don't want done. Wipe a disk, remove folders, change accounts - do you really want to make their lives difficult? Should everything the administrator do be made difficult?
Before intentionally making someone's life more difficult, I think it's ethically necessary to show you can't *make recovering from the behavior easier* instead. For example, before pestering someone with confirmation dialogs, there should be a *good* reason you can't let them undo a deleting something.
Also, if you have to make something more difficult, I'm a believer in showing that you have worked through the same hoops you are imposing on your users:
You opened with When it comes to user interface design, I'm no guru, but I do have one golden rule that I always try to follow: Make the right thing easy to do and the wrong thing awkward to do.
This is highly reminiscent of a broader rule I use for any dealing with the general public: It's not enough to make it easy to do right, you have to make it hard to @#$%-up!
If not, I guarantee you someone will @#$% it up. Even if you make it hard (and painful!), someone still will, but then, at least, you'll have a good story to tell and possibly something to laugh at ;)
@Matt: I turned off UAC as soon as I got Vista. So annoying!!! I also think there should be an administarate mode/tool for what your talking about. Allow it only for advanced user/admins.
By the way Jeff, why do I have to enter the word orange before I post?
That's a really interesting point, and something I didn't even realize I was already doing unconsciously. Especially the part about training users with complexity. I'll often make something hard to find, or a little bit confusing, especially if it's one of those ejector seat type features.
This is also a wake-up call to me to go through my software, find the features that customers are finding difficult to use, and see how I might reimplement them from the perspective of guidance rather than click here, click here.
Does that mean that we should all use orange that allows our users post to our blogs and QWEQWEREWRTVFDGTRBTRBTRBTRBTR when we dont really need comments?
tongue in cheek!
Because orange doesn't rhyme with anything, duh. Actually it is his CAPTCHA to stop spammers.
You also have to be very careful in _how_ you make something difficult, or you'll train your users to ignore warnings that they are about to wipe out their data.
Users already simply click through dialog boxes without reading them because earlier developers, including MS in Windows, put too many confirmation steps in things that should have been simple.
A friend of mine aliased the rm filename Unix command (remove a file) to always execute as rm -i filename to inquire if he really wanted to remove the file, thinking it would be safer; more difficult to accidentally delete a file. He got so used to just hitting 'y' that -- you can guess the rest.
(and click here are the two most evil words on the www, but that's another rant)
Same trick works for procedures, policies, etc. Make it as easy as possible to have things done the way you want them, and as difficult as possible to do it differently or wrong. The path of least resistance is your friend.
You can take this concept too far by imposing your own view of your website on your users. For instance if you think users SHOULD browse from the higher-level entities like forum categories down to the lower-level entities like posts, you may be turning off users who just want to search every post for some kind of data.
I've worked with folks that design websites so that the user follows a strict path, but for no reason other than to expose the user to all the ads on the site. I have to think that giving the user the freedom to do what they want would create a stronger base of happy users, and result in more profit over time, than trying to forcing them to monetize by limiting their actions.
Thanks for the thought-provoking post :)
Great posts past two days Jeff. So applicable to what I'm doing.
We've got an application (that I'll be blogging about soon) that has had so many hurdles to deal with. One of them is this exact thing: training users and guiding them down the path we want them to go down.
This problem is exacerbated (and thus even more relevant) when you're dealing with non-technical users who are stubborn in their behavior...
Going further, things that are likely to be very harmful and extremely unlikely to be correct should be fairly difficult.
For example, I once uninstalled glibc on a linux system (debian, I think). Yes, this is very unwise (it makes the system pretty much unusable), but it's still possible. In order to completely the uninstallation I didn't just have to press enter or type 'y' at a prompt, I had to type in the entire sentence yes, I realize this is a very bad idea or something to that effect.
I have seen it many a times employed in software that we ourselves have developed; albeit not intentionally.
It is kind of like become the 3NF from databases, that we have started to think like this... but yeah, it is very interesting as I have seen many a times software that would allow you to do very destructive actions without proper precaution.
I would love to employ this technique judiciously in my next interface design.
Good to see how you view your users. Seriously, I agree with your main point, but the metaphor is terrible.
For one thing the ìpit of successî is not about training users, itís about leading users in the right direction. You donít need to reward users to get them to do the right thing, rather you make doing the right thing the natural choice.
You also seem confused as to what ignoring behavior you donít like means. Making wrong behavior more difficult is not ignoring it. In fact itís the very thing the article on husband training is saying you shouldnít do ñ nagging at them. Moreover, your example of introducing registration to hinder spammers doesnít work in the context of the metaphor, as youíre also punishing good behavior.
Apart from that, a good post and I agree with the general point, just not the metaphor.
hmm. well I've not used KDE for a while, but use that as root and it looks horrible, and you can't (easily) change it. to discourage using it as root unless you have to.
if MS are serious about user control access levels they need only do a few things:
different version of the common controls library used by 'admin' users, broadly same function but different looks.
make a few of thier programs that don't *need* admin access refuse to run under and admin account.
e.g. if an admin user can't get word to run, or even MSIE (forcing software downloads as a regular user, then a switch to install) they could remove a lot of the issues with security.
the simplest thing though, which would cost MS *nothing* is to make it a requirement of displaying the windows logo for the software to run as a limited user, except in a few very limited cases (system tools) - which should get a different logo.
on the point of training users, I read something on this halfway through developing an analysis package for an ex employer, it benefited. the next one has this from the ground up.
Make it idiot-proof, and someone will make a better idiot.
I like UAC. Look at the last pwn2own. The hackers had no problem with Mac, with Linux. UAP and DEP make their life much more complicated (not impossible, but the normal script kiddie will have a big barrier for the next two years.)
Another example could be the UI design for developer IDEs.
If an IDE really must be all things to all men (people), then the use of perspectives/views can at least push forward functionality that is most likely 'right' in a specific context.
As my own tool has recently been nominated for 'worst ever' UI on Stack Overflow (not too many votes thankfully), I'm not exactly in a strong position to comment, but at least I know where I went wrong.
Unfortunately, aliasing rm to rm -i has become standard in most (all?) linux distributions in recent years.
Similarly, making your kid wear a helmet to play in the yard just means he won't understand that it hurts to fall down and he won't learn to respect gravity. It does nothing to help him *avoid* falling down.
The purpose of the helmet is obviously not to prevent falling down, but to prevent injury upon falling down. Similarly, a complete undo facility doesn't prevent you from doing something stupid with your data -- it would be very expensive to define and detect stupid -- but it prevents permanent data loss when the user realizes a certain action was a mistake.
If the child and user are lucid, then the prevention of injury serves as a painless lesson. If they aren't lucid, there are plenty of education options before risking permanent injury to prove a point.
On the surface it sounds like a good idea
there is a catch, who is the user ?
if you only have a single user type this is all good but there are many examples where this is just not the case and making the UI *HARDER* to use will indeed help a certain user group but will most definitively infuriate another user group. If you do not want a user to do something, well, simply remove it from the UI altogether for this user or user profile. Though that too may not always be doable.
Here is an example of where this make it harder thing crumbles in to the ashes of my fury...
Say you write a big software, say EHR or CRM or whatever, with many users of different ability. Obviously there are operations in such systems that are dangerous to fiddle around with. So... we follow the advice and make them harder. Well, the administrator of said system, whose daily job is to fiddle around these settings will certainly enjoy quite a bit you made his day harder.
so in essense, yes, it sounds like a good idea, and when done properly it actually is, so long as you know *who* your user is and in doing so ensure you encompass ALL the users of the system.
Cause making one`s day easier is only good so long as you do not make another`s day miserable in the process.
Please do not let others suffer as I am presently :-(
I think that need to do is always easy. But it must be remembered about the protection against the irreversible action.
EVE Online used to be almost impossible to quit out of unless you knew the key shortcut for it (ctrl-q... alt-f4 did NOT work). It's an example of making things you don't want users to do difficult, but it was very, very, bad UI design.
You wouldn't believe how many times on Rookie Chat people would ask how to quit.
I happen to like metaphors. In this writing, a metaphor users are caged animals, to be trained was used.
The problem with this metaphor is, that
1) Animals that are not training well can be let go. In some cases, users can also be let go, to other services. In some situations, especially intranets and such, also the users that do not learn the new tricks need to be tended for.
2) Some animals are pretty clever. Some users are also pretty clever. Clever animals get more treats, and are happier. The clever users tend to get frustrated with oversimple design, and go away. Again, sometimes it is just good to get rid of them, but sometimes the knowledgeable and clever bunch is what you want.
3) Thinking users as caged animals is a way to alienate users from the knowledgeable folk. I find this the most problematic part in the whole idea. Sometimes users can think of new features to the website or application. I guess that happens not-so-often in animal training world, but I don't know.
And that is the problem with the metaphors, they tend to assume common knowledge of something, while they forget the implicit part. The idea of path of least resistance to the right functions is good, but the metaphor is wrong. And if I could come up with better metaphor, I would.
There might be more, but i hear a bell ringing, and must go get a biscuit.
I strongly agree with the principle of falling into the pit of success. This isn't to be confused with dumbing down the interface, which I sometimes see in Microsoft products. The difference that I see between these two is that the dumbed down interface usually includes helper functionality that, when it's inappropriate or doesn't work properly, cannot be disabled an leads to confusion, frustration, and lost time. I want the tool to help me, and if it can't do that, then get the f' out of the way!
IMO this article is pointless, or only applies to applications that are already flawed.
A good application will only allow a user to do good things eg. ls, grep, or dd.
Mistakenly overwriting your usb memory stick or an important file with dd will teach the user not to do it again with no extra features or thought added.
There is no design in the world that will make joe average (who doesn't read manuals) avoid this mistake the first time, but assuming he's joe average and not joe moron, he will read the manual next time.
A friend of mine aliased the rm filename Unix command
(remove a file) to always execute as rm -i
filename to inquire if he really wanted to remove the
file, thinking it would be safer; more difficult to
accidentally delete a file. He got so used to just
hitting 'y' that -- you can guess the rest.
Right. A few rules I use:
- the right thing should be easy.
- the hard thing should be less easy. This is not accomplished by making things intentionally difficult, but by making right things easier and wrong (or dangerous) thinks require the investment of user time to specify what they want to do.*
- destructive things should be made undoable. I know a lot of people who alias rm to rm -i; never seen it work. I wrote a simple ruby script that just moves the file to the .Trash folder, and appends a numeric suffix in case of a name collision. Provides a simple undo.
- consistency is good. Don't make the same delete command remove a file from one volume immediately, without undo, and on another volume just move to .Trash. Are you sure? doesn't make this behavior better; it makes it worse.
(and click here are the two most evil words on the www,
but that's another rant)
On a similar note, when has the response to an OK message box ever been OK? It's usually Hell, no, it's not OK, but that's never an option.
* The specification part does not mean, ask for confirmation. It means require the user to say what they mean. You want to perform a file op on a file in a folder, recursively, rather than just one file? Make the user -specify- -R for recursion. You want to delete immediately instead of moving to .Trash? Make the user specify immediate deletion.
Which brings up admin accounts: The whole make-it-easier/
make-it-difficult might fall down for the idea of administration.
Admins do the path you don't want done. Wipe a disk, remove
folders, change accounts - do you really want to make their
lives difficult? Should everything the administrator do be
Nope, just safer and more explicit. As an example, it used to be trivial in many *nix systems to specify overlapping start and end values when partitioning a system, resulting in corrupt disks. Now, most systems don't permit you to use an overlapping value.
Similar logic can be applied elsewhere. I often run into issues where after Joe leaves the company and his account is removed, there's one file on his local drive that someone forgot to get, and now it's gone. Maybe removing a user account and folder should include a backup files to... required default, that requires the admin to specify nope, remove without making the backup.
Not more difficult, so much as more explicit. And not ask are you sure. That's one of the biggest things wrong with UAC; it's a giant are you sure message box, acting as a last chance workaround for busted code.