Author: Five Sketches

Posted on

Modernist design: Beyond flat and simple

A decade ago, the big players in software adopted modernist design for their user interfaces. With this redesign, digital came of age, embracing a look and feel that’s no longer bound by last century’s conventions or bound by the inexperience of those new to computing.

Modernist user interfaces were intended to focus people on their current task, supports fast-paced use, and embraces the fact that the interfaces are digital.

At first glance, modernist interfaces were simple and flat when compared to older graphical user interfaces. But making designs that are simple and flat didn’t always work. Designers who didn’t understand the principles behind modernist interface design made uninformed choices that hurt their customers.

Continue reading “Modernist design: Beyond flat and simple”
Posted on

After you publish, test and review

As a consultant to business and government, I know my clients often see publishing as a project that has a start, middle, and end. Once they’ve published their app, their data, or their text and media, they often express relief that the job is finished and then want to forget about it.

The thing is, they’re not finished. If the app, data, or content is mission critical, they must not simply forget about it.

To illustrate what can happen when people publish and forget, here’s a simple story. It’s from the perspective of a customer or “user” of some material that was published by others. In this story, I am one of those customers.

Continue reading “After you publish, test and review”

Posted on

When a user interface is for using—not for understanding—a product

The purpose of a user interface is not to explain how a product works. Instead, the interface is to help people use the product. Here’s an idea: if someone can use your product without understanding how it works, that’s probably just fine.

What model does the user interface reflect?

Models are useful to help people make sense of ideas and things.

Continue reading “When a user interface is for using—not for understanding—a product”

Posted on

Chip-card usability: Remove the card to fail

Card readerI went to a shop near my home, made a purchase, and tried to pay by using a chip card. Tapping the card on the machine didn’t work, so I had to insert the card and enter a code.

My first attempt failed, because I pulled my card out of the card reader too soon, before the transaction was finished. I should add that I removed my card when the machine apparently told me so.

The machine said: “REMOVE CARD”

And just as I pulled my card out, I noticed the other words: “PLEASE DO NOT”

Have you done this, too…?

Continue reading “Chip-card usability: Remove the card to fail”

Posted on

Drivers on the phone: Misusing the original social network

Researchers have been tracking the use of phones by drivers for several decades. We know that phones reduce driver performance, and that one fifth of motor-vehicle accidents involve mobile phone use. Heavy traffic and stop-and-go traffic compound the risk, because driving in this type of traffic requires more attention.

The task itself is also relevant. In Japan, dialling and talking while driving was involved in about one sixth of accidents, whereas attempting to locate the phone when it chimes to announce an incoming text message or voicemail was involved in almost half of phone-involved accidents. In addition, laws restricting phone use do little—at this stage—to reduce actual cell-phone use. This research applies not only to you and me, but also to professional drivers.

Continue reading “Drivers on the phone: Misusing the original social network”

Posted on

Simpler software leads to greater changes

If a group of users is accustomed to a complex software system, and you’re designing its replacement, how simple can you design that replacement to be? Simplifying software

Simpler software—software that is discoverable, easy to learn, and easy explain to others—frees its users to focus on tasks that add value. It may also frustrate former expert users as they suddenly find themselves less-than-expert users of the new tool.

If the software you’re replacing is so complex that it requires a dedicated group to mop up the errors of other users, then the impact of a very simple replacement is potentially disruptive. The users’ jobs are going to change.

Continue reading “Simpler software leads to greater changes”

Posted on

Natural mapping of light switches

I recently moved into a home where the light switches are all wrong. I was able to fix one problem, and the rest is a daily reminder that usability doesn’t just happen—it takes planning.

Poorly mapped light switches.
The switch on the left operates a lamp on the right, and vice versa. This is not an example of natural mapping.

On one wall, a pair of light switches was poorly mapped. The left switch operated a lamp to the right, and the right switch operated a lamp to the left. The previous resident’s solution to this confusing mapping was to put a red dot on one of the switches, presumably as a reminder. I put up with that for about three days. Continue reading “Natural mapping of light switches”

Posted on

A banister has multiple user groups

We don’t always know what a design is intended to convey. We don’t always recognise or relate to a design’s intended user groups. But we don’t have to know everything that an object’s design is intended to do, in order to make effective use of the object.

Video showing metal inserts in a wooden bannister.

I imagine the metal inserts in the wooden banister (see the video, above) are detectable warnings for people who are visually impaired, but that’s only a guess. If you watch the video again, you’ll see that the metal inserts do not occur at every bend in the staircase.

Whatever the intent, the banister fully met my needs.