Site BLOG PAGE🔎 SEARCH  Ξ INDEX  MAIN MENU  UP ONE LEVEL
 OJB's Web Site. Version 2.1. Blog Page.You are here: entry2272 blog owen2 
Blog

Add a Comment   Up to OJB's Blog List

Everyday (Bad) Design

Entry 2272, on 2023-05-02 at 18:45:40 (Rating 2, Comments)

I sometimes watch my clients, family, and friends using their computers and I find their inability to use them efficiently incredibly frustrating. But at the same time, I do have to admit that when I analyse what they are doing it often isn't their fault, because the software they are using is poorly designed, or has bugs, or is unintuitive.

So you could possibly say that it is never the user's fault; if they get something wrong it is because the person who designed the program just didn't make it simple enough to use, or made some design errors causing confusion and obscurity.

In fact, when I say it is *never* the user's fault that is probably going a bit too far, because I do occasionally see pople trying to do something which is totally irrational, or missing a message which is very clear, or just doing something where they really should know better. But in general, I tend to blame the program, not the user.

I am currently listening to an audio book called "The Design of Everyday Things" by Don Norman. Apparently, this is considered a classic in the genre, and is used as recommended reading for design students. This concentrates, as the title suggests, on physical items we see in everyday life more than software, but the principles are the same.

In fact, once you are aware of design flaws, and spend time looking for them, you see them everywhere, without even counting the massive numbers of design issues in the IT world.

Let me give an example. Recently I drove back from Nelson to my home in Dunedin, and stayed overnight in a motel in Amberley. My wife called me to the bathroom because she couldn't empty the hand basin, because she didn't understand how the plug worked. The plug was a metal device, permanently installed in the drain and with no symbols or wording on it.

She wanted to release the water which usually means pulling the plug upwards. She tried that, and she tried twisting, and some other actions, but nothing worked. I walked up to the basin and pushed the plug down, which released a catch and caused it to pop up and release the water. It literally took a second.

So I felt pretty smart about that, but what did my wife really do wrong? Plugs generally release the water when they're pulled upwards, and in fact, that was what was needed here, but who would think of pushing down in order to cause the plug to pop up? It's completely counter-intuitive.

So why did I get the correct action so quickly? I'm actually not sure, because I just did it without thinking, buy maybe it was because I knew it would be something non-obvious, or maybe I had used a similar plug before, or maybe I'm just a natural genius!

That same sink had a single tap to deliver hot and cold water. It was one of those taps where you lift it to increase the flow, push it down to turn off, or turn it left and right to get hotter and colder. There was even "H" and "C" printed on the tap, but I had no idea which way to turn it even with that. Should I turn it towards the "H" to make it hotter, or is it hotter when the "H" faces me? Both make sense, yet they are opposites. When I use taps like that, I just use trial and error, and I still couldn't tell you the correct answer for sure.

That is really bad design, and it goes beyond that too, because why not pull it up to make the water hotter, and push it down for colder (makes sense, yes?) then use the left and right action to control the flow (after all, in older style individual taps, we turn them to control flow). So there are many different possible combinations, and none are obvious to everyone.

Also in that bathroom, the toilet had a double flush system, with a small and bigger button. And the small button delivered a full flush, and the big one partial. Does that make sense to anyone?

And finally, there were the light switches. There was a main light in the middle of the ceiling, and another above the basin. There were two switches above and below each other. I have no idea which switch controlled which light, but trial and error was simple there, at least.

These design errors were all in one small room, and became apparent with no effort to actually look for them. The only reason I even remembered them is that I was aware of design issues of that type because of the book, and in the past I might not have taken any notice of them at all, except I am (informally) interested in design, especially from a software perspective, so I probably would have noticed!

I talked to my wife about this, and mentioned how design is often done so badly (she is used to my geeky rants by now) and now she sees design problems everywhere too! In some ways it is a frustrating curse having that knowledge and way of looking at things.

One thing the author of the book mentioned is that he doesn't like criticism of design unless the person making the criticism has alternatives which would be better, so let's see if I can some up with some options for the cases I mentioned above.

Note that proper design teams study the requirements of the target users of their new product, and go through an iterative modification and testing regime, before the final design is released, so even simple examples like mine can be complex.

So for the plug, the simplest solution is just to have the words "push to open" or even just "push" printed on the top. A symbol, word, or other design element (such as a bar to push a door open) are common "signifiers" of how to operate something. Of course, the word "push" only works for English speakers, so the product might need different versions for different countries, making words not always the best choice, which is why symbols are often used instead. But what symbol would I use in that case? Maybe a picture of a finger pushing down? Even something as simple as this can get complex.

So what about the tap? Well I would like to see symbols on the front with a picture of a thin flow of water next to an arrow pointing down at the bottom, and a larger flow with an upward arrow near the top. And on the top of the tap lever an arrow pointing right (or is it left) in red and an arrow pointing the other direction in blue. Red for hot and blue for cold are common (although probably not universal) representations for temperature. Of course, the weird thing is that blue flames are much hotter than red!

And the toilet flusher? Well the smaller button should deliver the smaller amount, surely, but a picture of a full and half full tank for the different amounts might also help.

Finally, the light switches. This is a subject the book covers quite extensively, and it seems to be a favourite example for the author.

I would say have the switches side by side instead, with each switch closest to the bulb it controls. It doesn't have to cost more to use a horizontally oriented fitting than a vertical one. A better choice might be to have two individual switches close to the lights they control, but that would probably increase the price of purchasing and installing them slightly.

Finally, there is the apparently more superficial element of design: how the product looks, feels, and sounds. If an item looks good, or is aesthetically pleasing in any other way, people tend to excuse it more if it is deficient in actual operation. So making something "pretty" is actually quite important. I like the single lever taps, because of their aesthetics, even though I realise that almost all of them have usability issues. But even understanding that, when I talk about design, I usually count ergonomics as being more important than aesthetics.

So even everyday, simple items like plugs and switches can have a lot of complexity in their design. Imagine how much harder it is to design a complex computer program which might have hundreds, or even thousands, of different ways for the user to interact with it.

So the next time you make a mistake using a computer, remember that it's probably not your fault. It is the person who designed the user interface (on big projects, that is not usually the programmer) to blame, at least, most of the time.


Comment 1 (7430) by Anonymous on 2023-05-03 at 12:36:02:

LOL now you have done it to me. I see bad design so many places now. Thanks.

Comment 2 (7431) by OJB on 2023-05-03 at 16:59:45:

I think it can be quite helpful in recognising why things often don't work as well as they should. It's nice to know that errors are often not really our fault, although we should be aware there are times when they really are. Remember though, that we shouldn't criticise design unless we have a better alternative.


You can leave comments about this entry using this form.

Enter your name (optional):
Enter your email address (optional):
Enter the number shown here:number
Enter the comment:

To add a comment: enter a name and email (optional), type the number shown, enter a comment, click Add.
Note that you can leave the name blank if you want to remain anonymous.
Enter your email address to receive notifications of replies and updates to this entry.
The comment should appear immediately because the authorisation system is currently inactive.

I do podcasts too!. You can listen to my latest podcast, here: OJB's Podcast 2024-08-22 Stirring Up Trouble: Let's just get every view out there and fairly debate them..
 Site ©2024 by OJBRSS FeedMicrosoft Free ZoneMade & Served on Mac 
Site Features: Blog RSS Feeds Podcasts Feedback Log04 Nov 2024. Hits: 40,917,285
Description: Blog PageKeywords: BlogLoad Timer: 11ms