Tag Archives: Usability

Bad UX and Stockholm Syndrome

When we’re thinking about the impact of good and bad UX on the experience of using software there are a large group of people who are often overlooked. They’re not the discretionary consumers, who may be put off completing a purchase by requiring an extra click or form field, but a those who are forced to use in-house developed software required to complete their day-to-day work.

These apps are often clunky, with awkward UX, interaction foibles and bugs. They’ve quite possibly been “”designed”” by programmers, rather than UX specialists. But people have no choice but to use them day-in and day-out. So how is this likely to affect their attitude to the application?

An interaction can be so bad, so awkward to execute, that it feels almost painful. Maybe not when performed in isolation, but when repeated over and over it can become mentally (and even physically) wearing.

The application has them captive, and sets about bending them to its will.

But then a strange thing happens. The users start to think it’s OK.

Maybe it doesn’t feel quite as bad as it used to. It’s not really so awkward that it works that way. In fact, it feels right to do it this way.

Actually, why would it be done any other way!?

Wait a second, what just happened?

Despite the terrible treatment meted out, and partly due to the captor showing some small kindness – giving the ability to do their job, however awkwardly – the hostages have fallen in love with the application, their cruel, heartless captor.
Continue reading Bad UX and Stockholm Syndrome

A short (and round) history of the button

Early MacOS OK and Cancel buttons
Early MacOS OK and Cancel buttons
The push button. It’s truly the blunt instrument of UI design. While most other controls provide some indication of the type of operation they’re performing – sliders are adjusting a value, a switch is moving between two states – buttons just mean “do something”. What? The only way to tell is to press it and see. But this shouldn’t be the case.
Continue reading A short (and round) history of the button

London Underground UI Fail

I mentioned this on Twitter the other day, but I was so incensed I just had to scribble out a blog post too. It’s a classic case of replacing a traditional (in this case paper-based) “interface” with an electronic one, and in the process failing to translate the fundamental functionality that made the original system useful.

How can you screw-up creating an electronic version of an existing sign?
Continue reading London Underground UI Fail

iPad – The rise of the naturalistic user interface

It was fascinating to see Apple unveiling its new iPad hardware recently, and one of the things that caught my eye were the interfaces of the various apps that were demonstrated. They look different from apps on other platforms, and even from the equivalent apps on the iPhone. It seems to me as if there’s been a change to a more naturalistic style of user interfaces. Why is this, and what is it about the iPad that makes it suited to this kind of UI?
Continue reading iPad – The rise of the naturalistic user interface

The 7 signs your UI was created by a programmer

Do you suspect a programmer may have put together the terrible user interface on that “enterprise” software you’re forced to use every day? There are some give-away indicators. Look out for them in your software, hunt down the developer and force them to read a book about user interface design. If you’re suitably senior, force them to a) improve it, or even better b) get someone with real UI experience to fix it.

1. Exclamation marks in dialog box messages
Look, it’s probably the 50th time I’ve seen this message today. The fact that this application “Cannot connect to database!” is no longer a surprise. You may have noticed that most professional software uses a neutral tone for its communication with the user. Try that. Also:
1a. Double negatives in confirmation dialogs
“Are you sure you don’t want to lose your changes?” Err… what? No. I mean YES. Oh sh*t. Any dialog that requires you to stop and try to parse the question in order to work out if you’re about to destroy several hours of work is not doing its job. It’s getting in the way of you doing your job. In fact, convoluted messages are such a serious issue that Microsoft even tried to help developers to help their users by introducing a whole new kind of dialog box in Vista: the question/task dialog. Good luck with that.

2. No tab ordering defined\mouse only navigation
Because no-one’s ever going to use the keyboard to navigate the zillion controls in your data entry app, are they? This one actually surprises me, because I’d have thought that developers would’ve needed to navigate quickly through the application while they’re writing it. Well, that doesn’t seem to be the case. Pretty much all commercial apps are good counter examples. I don’t mean to hold up Microsoft Office as a paragon of UI virtue, but they definitely do the “alternate way of navigating everything” thing well. Everything you need can be reached by both keyboard and mouse. Unplug your mouse and try that with your favourite piece of in-house software and see how you get on.

groups3. Group boxes around everything
This is a bit of a WinForms specific one. The clue is in the name: group boxes are for grouping logically related controls, not for providing a kewl recessed border around every single one of the controls in your dialog. Don’t kid yourself that this is doing anything other than using up some valuable screen real estate. (See if you can spot another pet peeve in the example dialog, too).

icon_editor4. Icons created in the IDE
Look, Visual Studio’s a really good integrated development environment, but it ain’t no Photoshop. Don’t try and use it to create icons. And while you’re at it, please don’t make icons consisting solely of the name of your application (inevitably an acronym) in pixel font and primary colours. Oh, and don’t just steal various icons from another application, unless you’re going to steal the whole lot; one of the key visual aspects of a good UI is consistency. Mixing your hand-drawn 4-bit icons with the glorious 32-bit shiny ones you borrowed is going to be jarring. In fact, why not go the whole way and get someone who can actually draw to create your icons for you? After all, you wouldn’t have someone who wasn’t a programmer writing the code, would you…?

5. Data grids
Otherwise known as the “Excel is the pinnacle of user interface design” disease. Break the habit. Generally, the more types of controls that are embedded in your grid, the less likely that it’s the right kind of interface paradigm. Yeah, I’m looking at you, person embedding a calendar control, drop down box, graph, slider and checkbox in each row of a data grid. And whatever your 3rd-party grid provider of choice says, it’s not going to do screen redraw performance any good, either.

6. Not implemented message boxes
Ahh, the GUI equivalent of source code TODO comments. Of course, it’s an in-house software give-away; no commercial (desktop) software would be brazen enough to ship with bits of functionality dangling from the stumps of buttons and menu items. Would it? Feel free to provide counter-examples if you have them.

dialog_dialog7. Excessive use of dialog boxes
Warning: dialog boxes are considered harmful (to usability). They’re the equivalent of restraining your user by force and preventing her from moving until she answers your question. That might be OK for matters of life or death (i.e. data loss), but not otherwise. Every time you find yourself about to add a new message box, stop, take a deep breath and consider whether it’s really necessary.

So, if you’re a victim or one, many, or all of these user interface faux pas, all I can say is: sorry. I’ve been responsible for doing at least one of these things myself over the years. Consider this post repentance for my user interface sins.