Product Behavior

My son and I have a secret handshake. He taught it to me the other day, a complicated combination of palm-slides and fist-bumps that, when executed correctly, confirm to each other that we are who we say we are.

While he was teaching me the proper motions, I had problems keeping the order straight. Slide-then-bump? Four slides between bumps? He told me to wait a minute, and came back with a few sheets of paper on which he’d drawn, of all things, icons representing the motions, with a number to tell me how many times to do each. Here’s what the fist-bump looks like:

That’s a “4″ at the bottom–it’s backwards, but he’s only 5, so cut him some slack. In contrast to what I see on most screens (computer and product-interface), this image tells me exactly what I need. No more and no less.

Often, designers are managed at the pixel level, with no regard to the high-level issues that really impact the user experience. Sure, the fists in the fist-bump could look more like fists. But why? The image is not for impressing me with drawing ability – it’s for telling me what to do next. As I’ve written before, icons and instructional graphics are a language. Without knowing enough about the grammar of that language to communicate properly, the message won’t get across.

Here are three things to know that describe the rules of grammar for on-screen (and off-screen) graphics:

1. Know what the graphic is for. Is it teaching me how to use the product? Is it jogging my memory? Is it decorative, not meant to convey anything other than the fact that someone put some professional-grade thought into the look of the system? In the case of the fist-bump graphic, this is a memory-jogger, not instructional. If I don’t already know what a fist-bump is, this image isn’t going to teach me. Perfectly fine for this application.
2. Know what we want the user of the system to do when they see the graphic. Is he clicking on it to tell the device to do something? Is it representing a step in a process that takes place outside the device (e.g. “unwrap and apply a bandage now”)? Obviously, the handshake is happening outside the piece of paper. But if I were also required to manipulate the paper, the image would have to tell me two things: to fist-bump four times, and how to deal with the paper itself. On-screen highlights and roll-overs are about the graphic – not the subject of the graphic. A “print” button needs to communicate both “print” and “I’m a button”–that’s another level of complexity.
3. Know what will happen next. Will the display change based on whatever I do in response to this image? Or is further action required, like to tell the device that the bandage has been applied? A successful handshake included (many) more steps than that illustrated here, so there were more sheets, which were set out in order. I could both see the whole scope at once and focus on each step in turn. If a user only sees one element of a process at a time, everything is out of context.

For any individual icon or graphic on the screen, these things are easy to know. The hard part, and the important part, is to know them for all the elements at once. Part of the goal of the designer is to reduce the number of types of interactions the user must learn. To do this, the designer looks across the complete set of interactions in order to develop a small set that can handle all of them. It’s a key skill in an interaction designer. That, and the satisfactory performance of the secret interaction design handshake. (If you need it: Four palm-slide/fist-bump combos, followed by four palm-slides and another fist-bump.)