Training Your Users

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


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.

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

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

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