Ten ways to improve the usability of products that Agile teams build

Software development that uses a waterfall method is likely to deliver the wrong thing, too late. The intent of the Agile method is to deliver working software sooner, so the intended users—our clients and their customers—can provide feedback that steers us to deliver the right thing.

There’s a tension between delivering on time and delivering the right thing. In fact, the rush for on-time delivery can result in the wrong thing—an unusable product. There are ways to prevent this. User research is part of the solution.

Continue reading “Ten ways to improve the usability of products that Agile teams build”

Poor usability is a form of tech debt

If you’ve worked in software development for a while, you may have noticed that work to address poor usability gets postponed more often than work on new features and functions. But this need not be an either/or proposition.

Postponed usability work – whether it’s identified by your customers or your user researcher – can be seen as a form of tech debt. It typically accumulates with every release.

Bike-tire pumpWhat contributes to this accumulation?

  • Poor timing or process. Some usability issues aren’t identified until after the product is released.
  • Pressure to get to market. There’s often pressure to leap ahead or catch up with competitors by adding new features and functions immediately.
  • Perceived relative value. If multiple teams compete for a share of development resources, a new feature may attract more funding than tech debt.

There is a path to a more usable product, at a low-to-moderate cost and with low-to-moderate risk. With every release, take some of the following actions.

Continue reading “Poor usability is a form of tech debt”

A complicated interface is fixable

According to usability industry leader Jakob Nielsen, usability failures in software and apps are usually because the software:

  • solves the wrong problem.
  • has the wrong functions for the right problem.
  • makes the right functions too complicated to understand.

Nielsen’s last point reminds me of what a product manager once told me: many users of highly specialised software think of themselves as experts, but only few of them actually are. He believed elaborate sets of functions are too numerous or complex to learn fully. As user researchers and interface designers we can help solve that.
Continue reading “A complicated interface is fixable”

Reduce spam without hindering usability

If your website lets visitors sign up, join in, or add comments and reviews, then—in addition to the legitimate details you want people to contribute—you’re getting some garbage. Some of this garbage is sent by spam bots.

Spam bots post content that detracts from your website. Spam lowers your site’s perceived quality. Spam posts may include links that pull traffic to competing sites or trick your visitors into a scam. The cost of spam is hard to quantify.

Plenty of experts recommend methods to avoid spam. But in a series of user research studies, I observed that anti-spam measures impose a cost of their own. They can add friction that causes visitor abandonment and attrition. The cost of this is easier to quantify.

Some anti-spam measures impose more pain than others. I decided to assess and compare them.

Continue reading “Reduce spam without hindering usability”

The ease of user research goes in cycles

The tools of user research have evolved substantially over the past three decades, and need to evolve more.

Here’s a history from last century through today, based on my experience.

To observe and record how people use devices, user researchers have had to learn to test

  • computer software, by using expensive usability labs,
  • desktop software, by using other desktop computers,
  • smartphone apps, by using apps,
  • household appliances and outdoor digital experiences, by using portable usability labs,
  • self-powered and motorised vehicles, by using GPS and streaming apps.
Continue reading “The ease of user research goes in cycles”

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”