User’s brain vs your UI design

In the context of UI design, I’ve come across numerous references to gestalt principles in the past few years, but not to 2D-design principles. When you design a user interface, you can apply both sets of principles to ensure users “intuitively” figure things out without any mental, or cognitive, effort.

Gestalt principles

There are plenty of websites that list and illustrate gestalt principles, and explain how the brain’s precognitive processing makes assumptions and fills in the blanks. Here are some examples:

Do you see a triangle?Are the 6 circles in one group or two?

Do you see six circles? Do you see any white triangles? There are no circles (just irregular shapes), and there are no triangles drawn on the screen. Your brain completes the triangle’s edges, and your brain closes or completes the circles. This gestalt principle is called the law of closure.

How many groups do you see? One?

Compare the three illustrations—the coloured and the grey ones—above and below. In each illustration, how many groups of circles do you see: one, two, or three? Isn’t it interesting that your brain is so prepared to see groups? This gestalt principle is called the law of similarity. Note how colour changes your perception:

How many groups do you see? Three?

You can see the law of similarity before and after a quick redesign of this web-application’s main screen:

A colour change improves user perception

Before the redesign, the viewer’s brain applies the law of similarity and intuitively sees the five boxes as related. In fact, this is incorrect because the right-most box has a different function from the others. After the low-cost design change—a colour change—to the fifth box, the grouping that users intuitively see matches the functional model.

2D-design principles

I haven’t yet come across a website that explicitly ties the principles of 2D design to UI design. But these principles, which I learned from Marlene Cox-Bishop and the classic Wucious Wong textbook on 2D design, do apply to UI design. Consider these examples:

Does your brain see distance?

When comparing two figures, the brain sees that (1) a raised figure is in the distance, (2) a smaller figure is in the distance, (3) a lighter figure is in the distance, (4) a greyer figure is in the distance, (5) an overlapped figure is in the distance. The last pair (6) combines all of these design principles. You’ve likely seen these principles applied in your operating system:

Perception of distance in a

When you apply the 2D-design principles incorrectly, just as with incorrectly applied gestalt principles, user perceptions will be incorrect.

Prioritising your web-design work

When you have limited resources, how do you prioritise what to provide on an e-commerce website? In the PEW Internet and America Life report, Generations on-line 2009, Jones and Fox present data in a format useful to help you prioritise.

To answer these sample questions, consider the colour coding in the data, below:

  • Should you do any search-engine optimisation (SEO) on your site? What kinds of things will users search for?
  • Should you provide video on your site? What kinds of users will watch video?
  • Should you help site visitors research your products? Should you deliver that information in a podcast?

An excerpt of the Generations On-Line 2009 data

Below are common online activities, by age group. The more people report doing an activity, the higher it appears in the list.

The boxes ( █ = 5% ) show the portion of the online population in each age group (total = 100% of online USA adults).‡

Ages 18-32 Ages 33-44 Ages 45-54 Ages 55-63 Ages 64-72 Ages 73+
█ █ █ █ █ █ █ █ █ █ ▀ █ █ █ █ ▀ █ █ ▀ █ ▀
E-mail.
Search.
Research a product.
Get news.
Watch video.
Buy something.
Get health info.
Visit SNS*.
Make travel reservation.
Get job info.
Create SNS* profile.
Instant messaging.
Download music.
Banking.
Visit gov’t site.
Research for job.
Play games.
E-mail.
Search.
Research a product.
Get health info.
Buy something.
Get news.
Make travel reservation.
Banking.
Visit gov’t site.
Research for job.
Watch video.
Get job info.
E-mail.
Search.
Research a product.
Get health info.
Get news.
Make travel reservation.
Buy something.
Visit gov’t site.
Research for job.
Banking.
E-mail.
Search.
Get health info.
Research a product.
Buy something.
Get news.
Make travel reservation.
Visit gov’t site.
E-mail.
Search.
Research a product.
Get health info.
Make travel reservation.
Visit gov’t site.
Buy something.
Get news.
E-mail.
Search.
Get health info.
Make travel reservation.
Research a product.
Activities above this line were done by more than half the group, below this line by less than half.
Read blog.
Download video.
Rate product.
Get religious info.
Auction.
Podcast.
Create blog.
Visit virtual world.
Download music.
Instant messaging.
Get religious info.
Play games.
Visit SNS*.
Rate product.
Read blog.
Download video.
Auction.
Create SNS* profile.
Podcast.
Create blog.
Visit virtual world.
Watch video.
Get job info.
Get religious info.
Rate product.
Instant messaging.
Auction.
Read blog.
Play games.
Download music.
Download video.
Visit SNS.*
Podcast.
Create SNS* profile.
Create blog.
Visit virtual world.
Banking.
Research for job.
Get job info.
Watch video.
Rate product.
Get religious info.
Play games.
Auction.
Read blog.
Instant messaging.
Download music.
Download video.
Podcast.
Visit SNS*.
Create SNS* profile.
Visit virtual world.
Banking.
Research for job.
Get religious info.
Rate product.
Play games.
Instant messaging.
Watch video.
Read blog.
Auction.
Download music.
Download video.
Get job info.
Visit SNS*.
Podcast.
Create blog.
Create SNS* profile.
Visit virtual world.
Buy something.
Get news.
Visit gov’t site.
Get religious info.
Banking.
Instant messaging.
Play games.
Rate product.
Read blog.
Watch video.
Get job info.
Podcast.
Research for job.
Auction.
Create blog.
Download music.
Visit SNS*.
Create SNS* profile.
Visit virtual world.

*  Social-networking service.
‡ Data from teens (ages 13-17) isn’t listed here because I had incomplete population data. However, teens do a smaller range of online activities than all adult age groups.

By examining the data, you can quickly see the size of your potential audience and the likelihood that they’ll engage in particular activity. For example, you’ll definitely want to optimise your site to help potential customers find product information on your site, both before they get there (from Google or Bing), and after they get there. This may seem like an obvious statement, but ask yourself: “What three things have I done to improve SEO, or search-engine optimisation, on my site?”

Month and year: date enough?

Once again, I’ve learned that I am typical. I tend to format dates the same way as many other people do.  This excerpt from William Hudson’s date study report shows the most common formats:

Click to view the source and much more detail

The report has all sorts of tidbits for interaction designers about date formats, error trapping, leading zeros, and more.

One thing the study doesn’t discuss is when not to use dates.

I recently recommended, in an online customer-registration form, dropping the request for the customer’s complete birthday. On the site, the date will be used to compare the customer’s data to a comparable sample of the same age. The site will tell the user whether they’re below or above average.

Month and year

The point behind my recommendation is this: you can accomplish that with reasonable accuracy with only the month and year, or perhaps with only the year.

Unless your business or the application really needs to know a user’s exact date of birth, collecting that information online means you’re setting up your company, needlessly, by making its data a juicier target for hackers and identity thieves.

The future is haptic, right?

I’ve been waiting for a full-screen touch UI with haptic response. That is, if the application displays a button on the screen, when I push it with my finger, I want to feel it clicking. Similarly, when I nudge an object, I want to feel its edge on screen.

Imagine the challenges in designing for the kind of hardware depicted in the video, above! It doesn’t exist, yet, but I’m ready. I can also imagine haptic icons on mobile-phone handsets, because I heard researchers present their research at the University of British Columbia, a few years ago. I can imagine the responsibility and the pressure of being the first to market with haptic icons. The market leader will get to define what OK feels like and what Cancel feels like, for years to come. Click to read about piezo-based skin-stretch display The idea is that mobile phones should touch you back, with haptic icons, at the place where your thumb typically touches the handset. Phones could signal—through touch—that you have a call waiting. Similarly, a camera could recommend—through touch—that it’s focused and ready to shoot. Outside the world of portable electronics, a doorknob could signal—through touch—that there are already three people in the room, and a steering wheel could alert you—through touch—that your car needs refuelling.

Most of us will only get to decide which kind of haptic cue we want a screen to convey during a particular physical interaction between the user’s fingers and a screen. But I’m eagerly awaiting that technology. There are bound to be many common computing tasks where a finger can outperform a mouse.

Design requires courage and trust, not just user involvement

Designing is usually a rewarding activity, but the path from start to finish can be filled with frustration and even panic. I’ve seen design processes work—and come to the realisation that “My own designs benefited from rapid iteration!”

The benefit of designThese humbling experiences helped me learn to trust the process, even in the face of frustration or panic. It’s these experiences that give me the courage to follow the design process, even when it isn’t clear how to resolve the tension between conflicting design constraints.

In the face of an unknown, individuals and especially teams tend to turn to knowns. If needed, they’ll manufacture the known data, by deferring the choice to users. Here’s part of what Larry Constantin wrote about courage in software design, in a paper that advocates for user involvement at the right time:

Most damning and least recognized among the limitations of user-centered design is the way it subtly discourages courage. Courage is one of the central tenets of extreme programming and agile development methods. […] User-centered design makes it too easy for designers to abdicate responsibility in deference to user preference, user opinion, and user bias. In truth, it is hard to stick with something you know works when users are screwing up their faces at it. What if you are wrong? What if you are not as good a designer as you thought you were? It takes real courage and conviction to stand up for an innovative design in the face of users who complain that it is not what they expected or who want it to work just like some other software or who object to certain sorts of features as a matter of course. It takes responsible judgment to know when to listen to users and when to ignore them.

In the many design sessions I have facilitated, three times I’ve seen that lack of courage expressed by a participant. Each time, it sounded like a mix of panic and frustration:

The solution has been on the wall since the first round!

The design sessions I facilitate ask participants to saturate the design space with lots of ideas. They each bring five sketches—five substantially different ideas—and then, after sharing their ideas with the other participants, they rapidly iterate the first 15 or 20 sketches to develop even more. All this takes place before any analysis.

When the goal is to saturate the design space—to identify as many solutions as possible in a short time—there’s more to influence the design once the analysis begins. Inevitably, the design that the team decides on was not already on the wall. Motivated design participants quickly learn this, and—in most cases—become advocates of the process.

For most development teams, the Five Sketches™ process I introduce is a departure from the status quo, so it takes courage for their team members to take a stand, to say “I will use this process” for design problems that need it.

Starting over on the right problem

If you’re designing a bedpan washer, do you design one that nurses don’t have to wait for?

According to a newspaper report, BC’s Centre for Disease Control, or CDC, found that a British Columbia hospital had

bedpan-cleaning machines that take 13 minutes for each cycle.

If they wanted to ensure each bedpan got returned to the right patient, nurses had to stand by for the duration. […]

The BC CDC found the [bedpan washing machines] to be inconvenient and too time consuming.

As additional disincentive for nurses to wait out the 13 minutes, the newspaper says: “If you don’t load the machine exactly right, they not only don’t work, they sometimes spray aerosolized feces on you when the door is opened.”

Oh dear.
                 Cleaning bedpans by machine

It’s easy to ask pointed questions after the fact, but here goes. Since nurses are too rushed to wait 13 minutes, would ethnographic study of hospitals have identified time pressure as a factor? Did researchers ask how long a nurse could or would wait for a bedpan washer? If the answer is “they won’t wait at all; they’ll go do something else,” then that reframes the design problem:

Can the machine track which bedpan gets returned to whom without relying on a nurse’s memory?

Can the machine clean bedpans so that it doesn’t matter to which patient they are returned?

These are very different design problems to solve. Other possible design questions to have asked:

Can the machine’s design prevent improper loading?

Can the machine not spray fecal matter at the person who opens it? Or, if this problem wasn’t predictable at the outset, Is the machine pleasant to use?

Can the machine be operated correctly by untrained users?

…and so on.

I’ve worked on projects where we thought we had the problem space clearly defined, and then—after exploring the design space and attempting to converge on a solution—realised that we had to redefine the problem and start over. I’d say that happens in about 20% of the projects I work on. I’ve also worked on a health product where we couldn’t change the hardware component, so we had to design a software and website solution to mitigate the hardware’s intermittent connectivity problem.

I don’t know anything about the design of the bedpan washer, above, but I understand that BC CDC implicated bedpans in the hospital’s outbreak of Clostridium difficile, and that the hospital switched to another cleaning method. The costs to the manufacturer are potentially horrendous. If the design team did everything right—including an iterative design process and early, user-involved testing—and still missed the mark, then they have my sympathy.

But now that they have a better understanding of the problem space—now that they know the “right” problem—they can design and build a better product.

The delight of insight

One of the things I really like about usability research is that moment of insight, when I see a problem. In the comic book of my life, those moments look like this:

Oh!

This experience—this feeling of surprise and delight—is not about finding an error. It’s about learning how the product performs in the hands of users, so it can be improved. In a sense, GUI design is like a puzzle that must be assembled well in order for the user’s brain to see the intended picture. It’s rare that a team gets it exactly right on the first try. That’s why a good development process expects and plans for rapid iteration—and expects formative testing of either prototypes or early working versions to inform the next iteration.

Rapid iteration

Fling that thing! If it won’t fly, bend the wing!
Formative testing of Iteration 1 informs the design of Iteration 2.

For me, realising there’s a problem means we can iterate the product to address the problem. That’s exciting. But realising there’s a problem can also be disappointing or humbling. From time to time, I’ve said to myself:

“I thought this design was really good.”

“Why didn’t I see that problem coming? It’s SO obvious, in hindsight.”

This experience points to the problem with heuristic reviews done by an individual expert. (In contrast, experts who work in pairs come closer to finding all the problems in the set.) But either way, experts cannot predict all the usability and interaction problems in a software product. That’s why testing and a process that includes rapid iteration are necessary.

The insight and the subsequent exploration of the problem lead to the best parts of the experience: deciding how to present the test results most effectively (as a critique of the prototype, not as a criticism of the effort to date), and facilitating the process of designing the next iteration.

Researching usability research

I’m conducting ethnographic research into how usability analysts regard usability research.

How will I conduct this research?

How will I conduct this research? I’m conducting a form of community-based participatory research, so members of the community—the research subjects—will help me set the questions or lines of inquiry and will influence the research methods. This is appropriate since I’m researching people who research—people who likely have a greater awareness of research epistemology and the range of methods that can be used.

Want to participate?

If you have conducted any usability research at all, and you want to participate, please contact me by commenting. (Look for theimmediately below.) These comments are private. I’ll be at the 2009 UPA conference in Portland this week, June 8-12, if you want to meet in person.

Replies so far: 3. I have slots for only 8 more.