When UI designers Don't Get It

[rowyn]

I'm sitting through the release training for the newest version of the banks' core software. And in this particular presentation, the presenter listed under "Upgrade Considerations":

"When a warning pops up, you should READ IT."

Ah-hahaha!

Very funny.

Seriously, their warning messages are (a) too long and (b) too undifferentiated. Good warning messages should be a few words, and failing that, they should have a few key words in bold or red.

And even then, users won't read them. This is human nature. Saying "READ IT" will not change human nature.

Comments

[shockwave77598.livejournal.com]

I personally make my warnings in three parts.

Bold large type on top says in 8 words or less what the fault is.

Second line is longer, explaining what the results of the different buttons will be.

Third in much finer type is some debugging data about what generated the fault. Users having trouble can read this over the phone and I know what the problem is.

Granted, my stuff isn't for general consumption. But I'd do the same if I did because my model works well.

[minor-architect.livejournal.com]

Tell me about it! Library patrons don't read signs when posted right at their eye-level on front doors, either. Even when the sign says something as simple as: "The library will be open from 8am until 5pm." :-P

[terrycloth.livejournal.com]

How many warning messages did you click through when you deleted your free realms character by accident? >:)

[level-head.livejournal.com]

I have always followed a practice similar to ShockWave's above.

Also, the warning is logged -- so that a tech can read it later (along with the context of it popping up) even if the user does not.

But warnings in running programs should be rare indeed. Just fix the problem if at all possible -- again, keeping a log.

===|==============/ Level Head

[bikerwalla.livejournal.com]

We can't make it *less words*! We're not paying the legal department to make it LESS WORDY! Hah!