First :)

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,
Catto

> 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!).

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.

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:
http://vgable.com/blog/2009/03/25/lemur-catta-and-the-authors-burden/

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 ;)

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."

Thanks!

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!

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 :)

LoL!

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.

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.

I seen a picture that basically is your blog post look at it here. http://russellcountyjaycees.com/images/images/crap.html

I have a picture that is your post: http://russellcountyjaycees.com/images/images/crap.html

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!

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.

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?

@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.

great idea!

By the way Jeff, why do I have to enter the word "orange" before I post?

Because orange doesn't rhyme with anything, duh. Actually it is his CAPTCHA to stop spammers.

You should make a post about RIAs - all the javascript, AJAX, Flash, Silverlight stuff coming out - is it really improving user experience? That's propably one of the most exciting questions to answer. When is this sort of stuff too much, and why can a plain site be so popular? So does 'RIA':s matter?
Jeff you propably don't like javascript (or JQuery) and certainly not Flash and the Silverything. You like more coding with vb and sql - am I right? Sql coders don't like UI programming, that's a fact.

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.

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.

> 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
> made difficult?

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.

UAC...

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.

@Lucas @matt

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.)

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.

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 think that need to do is always easy. But it must be remembered about the protection against the irreversible action.

@stephen

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.

@Martin

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

...but...

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 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.