Divergent thinking can make better software

If your development team wants to build genuinely new features or services that are innovative or “outside the box”, how would you do it?

In broad strokes, often there’s an initial design discussion to map the project requirements to a sensible idea. Then there may be a proof of concept to test any risky parts. Finally the team develops the idea into a solution, and tests it. This overall approach uses convergent thinking to identify a solution.

Would it surprise you to know this approach is firmly inside the proverbial box, and less likely to lead to a genuinely new or innovative solution?

Continue reading “Divergent thinking can make better software”

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”

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”

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”

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”

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”

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”

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”