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.)

These are the questions that have been bugging me for ages. I spent much of this year thinking about training: how do we indoctrinate young designers at my company into our way of thinking about design. But I got stuck when I realized that it’s not just young designers–it’s everyone. What’s the consistent face of design if your design department isn’t structured around a single vision, with no creative director or VP of design? How am I assured that all of the design work that leaves my company is consistently great?

When I first moved into the product design group at my company, there were no tools in place to measure whether the design work we were doing was “right” by any definition. Industrial design has a history of being governed by peer-review-of-coolness: if other designers think it’s cool, it’s good. Many design firms operate that way, and many designers think that way. And sometimes it’s fine. If you’re selling some piece of consumer electronics that will be on the shelf for a couple of months before being replaced by the next model, maybe a design brief that includes words like “cool,” “different,” “iconic” is the right thing. Even if the product isn’t a hit with consumers, it’ll get some press and you’ll have a new product out soon enough.

But for many kinds of products, that’s not a good way to operate. And even though designers these days pride themselves on their research savvy and ability to understand what the consumer likes, wants, and needs, tools that close the loop are scarce. Just shipping the product and seeing what happens is a poor way to test whether your design is any good. So we adopted some tools that were being used at a more strategic level in our consultancy and applied them to products. And although there was some pain in getting the tools adopted by designers (one colleague told me research would “crimp his creativity”), we were ultimately able to show that by evaluating design earlier in the process, we could deliver better work to the client – better defined as “more likely to result in business success.” And, better defined as “supporting our design portfolio” and maybe even “pushing the boundaries of what good product design can be.”

As the design staff gets bigger and more distributed, though, the tools are getting diluted. People are using them in ways never intended, sometimes for the better (that’s how we got them in the first place) but sometimes for worse. Just saying “sure, we applied some design evaluation tools” isn’t good enough. Did you apply the right tools in the right way? I don’t think a “design review” is the right answer, and certainly the “crit” isn’t going to work. The projects we work on are large and complex, and it takes so long to get up to speed that simply commenting on a design is usually useless–the comments have no basis.

I don’t have an answer, but I’m thinking about it. What I envision now is simply a meta-review. Regardless of what you’re designing, is the process you’re using believable? If so, I’m pretty sure the design will be “good” in terms of business, portfolio, and design-as-a-craft. My company already does this on the business side, looking at project budgets and giving project managers a safety net. Developing a similar safety net for the design side is on my list for 2009.

How does your company insure design “quality”? How does your company define design “quality”?

On the other hand, I also like Trader Joe’s sushi. But TJ’s sushi isn’t made to order, the ingredients all mush together into a weird gummy texture, and it’s “fresh” in that it is less than a week old. All in all, it’s pretty weird. It tastes good, and it’s cheap, and I like it – but is it sushi if it lacks everything I think of when I think of sushi?

My wife likes “yogurt cheese,” which looks a lot like cheese but has a strange taste and texture. She says that she’s just learned to think of it as something else – not cheese. If she does that, she can appreciate it for what it is, not hate it for what it isn’t.

I think that Trader Joe’s sushi is to “real” sushi in the same way that camera-phone photography is to “real” photography, and heavily compressed MP3 recordings are to “real” high-fidelity recordings. The basic idea is there, and the name has changed, but the technical details have changed. And with that change you lose something, and gain something else. And over time, the new details define the experience. You could never take a photograph like this one with a camera-phone. But Ansel Adams could never take a picture like this one, with its weird digital grain and right-place-right-time immediacy. And vinyl is “superior” to MP3 just like live music is “superior” to vinyl – but only for a certain set of priorities. I can’t carry a record player with me.

It’s rare that technology changes the core of an idea – it just changes the details.

[photo by drp]

While wandering around, I snapped this picture, and wondered who at Brooks Brothers thought it was a good idea to open a branch in the waiting area of an airport. How does it enhance their old-school, classic, tailored image to hang around the likes of Hudson News? Is the sheep in that classic logo meant to be hanging over a trash can? Do they sell many bespoke suits to the annoyed, harried people waiting for planes?

It reminds me of Krispy Kreme’s big expansion northward into New England, when they placed donut displays in every rest stop in Connecticut. So much for the special nature of the premium donut: when seen among the awful food of the parkway gas station, all of the beauty is lost. I haven’t eaten a KK since I first saw them among the Slim Jims and air fresheners.

Honestly, it is always surprising that companies think these kinds of placements are a good idea. It’s disappointing to see a classic spoiled.

Clearly, the “requirements” are required; those are easy. But even interpreting the requirements is difficult. For example, if your product emits certain classes of laser light, regulatory requirements say you must either make a sound while the light is on, or have a warning light someplace. Those are pretty fuzzy. What kind of sound? A warning klaxon, or a soothing new-age melody? A flashing, spinning red light, or a little green LED? Requirements – especially regulatory requirements–are scary because some group, somewhere, is going to decide whether the device passes or not. I hope my interpretation matches theirs.

But it’s the goals that are harder to rationalize. As a designer, I know how I want the product to feel, but I’m not always sure how that stacks up against cost or time-to-market. If we’re making a medical product for use in underdeveloped countries, by a user with only a basic education, must using it be a one-button-push operation? After all, having a fourth-grade education is not the same thing as being a fourth-grader. If the medical worker rode a motorcycle to get to the patient, he or she can certainly be trained to use a product with more than one button.

And what if the user isn’t the buyer? The end user of a product almost never deals directly with the manufacturer – there’s always a purchasing department at the hospital, or in the government, or at the big-box retailed who’s relying on his or her judgment to decide whether the product is or isn’t “good enough” for its application. And even within the manufacturer, the engineering team probably has a different filter than the marketing team, the design team, the CEO…

What tools exist to evaluate how good is Good Enough? There are lots of tools. At one end is the Pugh chart and its engineering-flavored pro/con siblings. At the other end is the focus group – get the answer right from the horse’s mouth. In between are price-sensitivity tests, resonance tests, concept tests of various flavors. And ultimately, there’s gut feel. None of these tools paints a complete picture.

In the end, I suppose the best tool I’ve found is simulation, of both the product and the use case. If the device is meant to be used up to 50 times in a day, build a fake version of the product and use it 50 times. See if it’s good enough. Compare it to the current solution, alternate products, and the product with more-or fewer-features. There’s no substitute for experience, and when it comes to Good Enough, there’s no substitute for Try It And See.

• The [company/product/service] must be _____, because _____. Otherwise, _____.
• The [c/p/s] should be _____, because _____.
• The [c/p/s] could be _____, which might _____.
• The [c/p/s] must not be _____. If it is, _____.

It’s similar to the “Story of the Product” tool, but even simpler. The Modal Verbs exercise is a quick alignment tool that draws out a few key attributes or communication points. The company must be “trustworthy” or it must be “professional.” The product must be “fun” or it must be “precise.” A given product or company could have more than one “must” or “could” or whatever, but shouldn’t have more than a few. These are the overall requirements and goals of the product. Trying to support too many leads to being all things to all people.

Question for you: do you know what your company, product, or service must be? Should be? Could be? Must not be? Are you clear why?

Consider: Here’s one way we talk about design to clients:

Companies (and designers) tend to be pretty good at the left side of the chart. Given a particular situation, they can find the problems and invent features to address them. So, if I go into someone’s house and watch him install a garbage disposer, I’ll pick up on some process inefficiencies, some communication issues, and some usability concerns. Then I can go back to my office and design a new process, new communications, and new product details that address the problems. Most products and services are designed that way.

The right half is often missing, though. Why does the consumer feel the way he feels about the disposer? What emotional triggers make the process of installation hard, or easy, or whatever? Much of my work as a design has more to do with this understanding on the right side than the technical aspects of the left side. Most of what the business press talks about (or used to, before they got bored) as “design thinking” is really the consideration of the right side of the chart.

Fine. But what about the company producting the product or service? The model above describes considerations for the design of the thing – but isn’t that just the equivalent of the company’s own “left side of the chart”? If left half is something like “practical” and right half is “emotional,” companies have their own version:

On the left is the practical stuff – is the product something we know how to solve, is interesting to the world, and we can produce in quantity? As with the design of the product itself, a “yes” answer is necessary, but may not be sufficient.

The right side of the company’s picture is well-understood as marketing, but rarely well incorporated into the design of the product itself. What does a product mean to the company? How are the product’s attributes expressing the brand? Setting aside the very general mission statements that litter the walls of most corporate lobbies, and (here’s the hard one) setting aside money, why does the company exist at all?

The “triple bottom line” stuff is, to me, the way to directly link higher level corporate emotion to product design. For my friend, thinking about it before the company is even a company is great: he can bake the values into the strategy into the brand. For established companies looking to take into account more than economic performance, though, there may be a lot of backfilling to do. And it’s about time!

I spent part of today reviewing projects at the International Design Development Summit at MIT. About 60 people from around the world get together for a month to develop 10 projects in global health, food production, technology distribution, and other big deals. Some of the participants are students, some professionals, some teachers. I saw three project presentations, and gave feedback along with other participants and guest reviewers. It’s a pretty interesting event.

The project teams are made up of smart people with widely varying backgrounds. They’re capable of analyzing the situation in the field, coming up with solutions, building and testing prototypes. What they need help with, in the end, is making decisions: filtering the requirements; rating the criteria for a “good” solution; knowing when to stay within the paradigm of current solutions to a problem and when to develop completely new technology.

Those are the things “professional” designers really do. The technical skills are important, sure, but it’s decision-making that separates an OK solution to a problem from a great solution.

Many of the medical-technology companies I work for ask us to develop interfaces that use no text–icons only. It’s one of my least favorite conversation with a client. We sit in front of a very long list of product features; I envision a very simple menu system, organized to let the user easily find what he needs; the client says, “of course, we want to sell this in Europe and Asia, so everything has to be icon-driven. My heart sinks. I understand why companies want to make everything icon-driven. It’s about the cost of translation, and the associated cost of regulation. Changing a piece of text in the software that drives a device may mean going through regulatory hoops–and if you have to jump through those hoops in every country, that’s trouble. On the face of it, icons are much cheaper: find the global symbol for everything in your system, and there’s no translation, and if the icons are right there will never be a reason to change them.

The problem, of course, is that interaction with a product is a conversation. I inquire as to what the device can do; it tells me. I ask it to do something; it tells me how it did. But like conversation with another person, it only works if we’re speaking the same language. Don’t bother trying to speak to me in Dutch; I only know a couple of words (like “wentelteefje”).

Similarly, the chances that the user of a medical device will understand a 32×32 pixel picture to mean “there is an air leak around the seal of your mask” is slim. Mainly this is because there is no such picture–as the designer of the system, I had to invent it. Sure, to me, it says “air leak” clearly, but it’s not like there’s a universal symbol for the concept. Sometimes, we can claim plausible deniability by using a symbol from a library of standards–ISO publishes such a library. But, to be honest, with the exception of symbols for common things, like “power,” that we’ve all seen so many times that we can now associate symbol with concept, most of those symbols are mostly meaningless in and of themselves.

And that’s the point. Icons don’t have meaning. They are shortcuts that stand for something we already know. They’re cultural shorthand–assuming I know what a printer is and does, a little picture of a printer can probably be counted upon to communicate the concept of printing. But that’s a big assumption, and it works because it’s been reenforced for us for years.

But if we have to make up an icon for some new concept, we’re inventing new words in the language, and that’s not OK. In the end, no matter how hard I try and no matter how many usability tests we perform to gauge how well a user understands what an icon refers to, my confidence is low. Good design talks to me in my language. The answer is probably not to invent new words, but to simplify systems to the point that translation only need happen for those terms that we really need to understand.

A couple of years ago, a really large consumer electronics manufacturer hired my company to do an evaluation of their products relative to their consumers, both in terms of basic “design” (by which they meant aesthetics) and usability. I managed the usability effort, and we examined 40 or so products in 5 categories, including portable electronics and large appliances, over the course of a couple of marathon days in a London hotel function room.

It was a pretty fun, if exhausting, experience, and I learned something along the lines of what Seth Godin suggests. The major differences between the products of my client and its competitors were minor differences. At a gross level, the products were the same; it was the detailed that made most, if not all, of the difference. If product manufacturers would just bring in some broad-thinking designers at the last minute, the consumer’s experience would be better. Maybe much better.

Such a designer would be able to spot problems like, “that drawer grease gets on your hands when you install the fridge, so just warn me,” or “that TV remote has a button that the consumer will never use in practice, so you can get rid of it,” or “you don’t need all those twist-ties.” Those designers will spot problems in the installation guide, the on-product labels, and the packaging container. All the little things that make dealing with modern products more painful than they need to be.

Why don’t manufacturers just do this? Why is the last person a product sees before it enters mass production a manufacturing engineer, who thinks about manufacturing, instead of a designer, who thinks about consumer experience? For one thing, designers have a bad reputation for complaning about stuff. Fact is, after a design leaves the designers hands, it will be changed–a lot. And designers really hate that.

So here’s my plan: don’t let the original designers do the polishing. And don’t let the polishing designers complain about large-scale architectural issues. Wait until the molds are made, and the manual is in the next-to-last revision, and the packaging is designed but not yet manufactured. Wait until all that can change are the things that usually wait until the last minute, and let the designers have their way. Make whatever changes–small changes!–they believe will help the consumer install, learn, and use the product.

Reduce the path between the designer, who’s job is to think about the consumer, and the consumer.