Asking the user

Software apps often ask their users to confirm (potentially destructive) actions. The method most often used are dialog boxes with a message and yes/no buttons.

Unfortunately this is often bad design because it:

• slows the user down and
• doesn’t guarantee safety (there are so many dialog boxes popping-up all the time that many users develop a kind of dialog blindness and sometimes mechanically click “yes” without reading the details).

The worst kind of dialog is that with a long message worded so that it’s not immediately obvious which answer does what (see leftmost dialog in figure).

We can improve upon that by simplifying the message as much as possible and putting meaningful labels on the buttons (save/discard instead of yes/no, middle dialog).

An even better solution would be to have a really short message and big, meaningful buttons (dialog on the right).

That way we can minimize both confusion and delay and have happier, safer users.

But if the overall design (and budget) allows we can go even further: why waste the user’s time at all? Instead provide a robust undo feature and do away with the dialog altogether ;-)

Note: the picture was created with Balsamiq Mockups, a great little app for sketching UIs.

Update january 2012: I’ve recreated the example dialog boxes as they were missing after I moved this post from udreka.pl to this site. I’m not sure what the exact wording was on the originals and I feel as though the current version is somewhat less convincing, but I can’t seem to come up with a better one right now so this is going to be it for the time being.

The old WHAT vs. HOW debate

When explaining to laymen what a requirement is (or more importantly when telling a junior analyst what job is required of them) some people say:

“Requirements specify the WHAT without going into the details of the HOW.”

I’ve always found this explenation more confusing then helpfull. I mean is a statement like “The customer enters a credit card number.” a what or a how?

Depending on where you stand it can be either!

For example:

1. making money is the what * charging customers is the how
2. charging customers is the what * accepting his credit card is the how
3. accepting a credit card is the what * getting it’s number is the how
4. getting the number is the what * a text box on a web page is the how

This can go deeper still:

5. the textbox is the what * the HTML <form> tag is the how

The whole picture is made up of a hierarchy of levels each of which is a what for the level bellow and a how for the level above.

Saying “You should write more about the what then about the how.” is really meaningless. What you should say is something like: “Concentrate on user’s goals without going into the specifics of how those goals are achieved in the actual user interface but instead looking into how they help achieve his overall objectives.“

So please: be specific! And don’t confuse newbies: we tend to have a hard time as it is ;-)