We all fall back on cliche from time to time. Writers are taught to be on the lookout for cliches, and to eliminate them from their prose.

But designers, managers, analysts--anyone who is paid to think really--should all be aware of cliches and other easy answers. Easy answers get in the way of good answers.

There is a relationship between cliche and defacto standards. Designers who pay attention to cliches can often use this awareness to create better solutions. Here are the slides of a presentation I gave recently on this subject, called "Violate Standards!"

In recent months I've given a number of talks, and each time promised to post the slides for sharing, so here they are.

Recently, I presented a talk on techniques designers can use to increase the clarity, flow, and usability of their software-based products. The slides are here.

You'll find the slides refer to example movies, which you might want to download as well. (The movies are in a big zip file--32MB.)

Usability asks the question: how well does my product do what it does? Usefulness asks a different question: what should my product do? It's a higher-order question, and one that you need to answer before you turn your attention to usability. Answering this question should be part of your annual planning process, and the answer should set the agenda for the coming year of development. What's more, now is the right time to be thinking about this-as you prepare next year's budgets.

* * *

Let's say that your company makes electric power tie racks. Wait, stay with me for a second. Imagine that you are the product manager, and you're thinking about next year's product line. So what do you do with the tie rack?

You could hire a specialist who can make it the easiest to use power tie rack ever. You could hire another specialist to make it the most beautiful electric power tie rack in the world. You can hire specialists to cost-reduce it, advertise it, and reposition it.

And let's say you do all of these things, and yet a year later, your electric power tie rack still isn't selling. Perhaps at this point a suspicion grows within you. What if no one wants a power tie rack? What if power tie racks simply are not useful?

Sounds farfetched, I know, but those of us in the technology space wrestle with a subtler version of this problem all the time. We live in a world of new products and new product opportunities, all made possible by advances in information technology. And, amazing as this may sound, we often don't know if our products are useful to people. Think about those nebulous product categories our industry is famous for: business process automation, supply chain event management, product life-cycle management. These categories must hold some useful products, right? And perhaps some that could be made more useful.

Last year, I wrote a column about usefulness. At that time, I was calling the concept "suitability." And I promised to write more about how to figure out if your product is useful, and how to build usefulness into your products.

Let's start with figuring out if your products have it...

* * *

So how do you know what's useful? The answer derives from concept itself: usefulness is a context-dependent attribute. This means that a product can be useful only in the context of what a user is trying to do. I'm an amateur chef-I love to cook, and I value my chef's knife because it's one of the most useful tools in my kitchen. But when it comes time to fix my bicycle, my chef's knife is of little use. Obvious, right?

Thus, to understand the usefulness of a technology product, you must first define the context in which it will live: who will use it, where will they use it, and-most important-what will they be trying to do with it.

Try this: pick a product-Palm handhelds for example-and make a simple list.
* Who uses it?
* Where do they use it?
* What are they trying to do?

Imagine the difference between a high school student managing his class and social schedules, and a regional sales manager managing her meeting schedule. Both need small, lightweight tools that they can carry around with them, but only the sales manager lives in a world of shared digital calendars. The high school student, sophisticated as he may be, still doesn't have to deal with Microsoft Outlook whenever he wants to have pizza with his friends on Saturday afternoon. In his context, a digital device offers little advantage over paper. For the sales manager though, it's a critical advantage, and one worth paying real money for.

Of course, defining context is a messy business-part science, part art. That's why it helps to use good methods. One great way to define context is by using a tool called personas. Personas are basically models of the context in which a product is used. They provide context for purposes of product requirements definition, design, and evaluation.

Want to learn more? I'll be speaking this fall about how to create and use personas for product evaluations. Come hear my presentation at forUSE 2003. Can't make the conference? Give me a call. I'd love to talk to you about how these ideas could be applied in your organization.

When you think about your education, what comes to mind? I remember high school. I remember cutting school one snowy day and seeking shelter in the Museum of Broadcasting, endless afternoons in Central Park, all-night make-out parties, sneaking into clubs, and the Saturday night my band played at CBGB’s.

Classes? Yeah that too. Quadratic equations and mitochondria and etre and avoir. But that was the least of it. I rode the subway from Queens to Manhattan every day, arriving at my Upper East Side school with a few hundred other kids from around the five boroughs. Those kids, that place, and high expectations: those were the keys.

What does this have to do with web sites?

Well, the connection was made plain to me last week at GEL, the conference Mark Hurst, author of the Good Experience newsletter, hosted at the New York Historical Society.

Pam Lewis of the All Stars Project was speaking, describing the failure of education in New York City. Twenty percent of our public schools are succeeding, she told us. The rest are failing. The standard prescription for the kids in these schools is remediation. Pam’s organization takes a different approach. They recruit kids for programs that teach through participation—in theatre projects, and in internships in corporate America. Pam said, "Our kids don't need remediation. Our kids need development. And the way to do that is through experience."

That’s quite a statement. For me, it really changed the scope of the discussion. It’s not only about web sites. And it got me thinking about my own kids, who are never too far from the front of my mind.

Think about the ways that you train your kids for success. I was already thinking about that as I walked from the subway to GEL last Friday. It was a gorgeous spring morning. The cherry trees and dogwoods were in bloom, and the cobbled sidewalks and elegant face of the Natural History Museum had me mumbling under my breath, “God I love New York!” I was smiling about the directions from my 8-year-old daughter. I told her that I was going to the New York Historical Society for a meeting. “It's across the street from the Museum of Natural History?” she asked. “That's easy. You just take the 2 to the 1 to the C.” And I was thinking about how glad I was to have moved back to New York to raise my kids.

Mark was clearly thinking about New York when he curated this conference. In fact, it was plain to see that he had carefully thought out all of the pieces of the experience. The conference, without explicitly stating a thesis, delivered a compelling definition of good experience. Place matters. History matters. People matter. Constraints matter. Material matters. Sequence matters. Commerce matters. Humor matters. Culture matters. Mindfulness matters.

Other bloggers have done a good job summarizing what was said. When you read the transcripts and accounts, see if you can trace the thread of Mark’s thesis. It’s there in the words, and it’s there in Mark’s choice of speakers. But it’s also in the setting, the tone, the way he handed out door prizes, and lots of other tiny details. I wonder how visible Mark’s thesis will be to those of you who weren’t there to experience it.

Have you ever felt that the product you are working on has some un-nameable problem? For some reason--some baffling, hair-pulling, teeth-gnashing reason--it's just not resonating with customers?

A number of our clients have come to us with this problem, thinking the problem is the usability of their user interface. And frequently, that's not the problem at all. Instead, the problem is what I call "suitability."

Here's an example:

Early in my career, I had the opportunity to work on an electric whiteboard project. The company that was producing it had licensed the hardware design from one vendor, and had licensed the software from another. But now the company--my client--was unhappy with how the product was emerging. Consumers who used the prototype were less than thrilled. The whiteboard was just plain hard to use. It came with a full featured image editing program so that people could capture their meeting notes and review them at a later point. But this software bogged down meetings--people were spending all their time fussing with the software, instead of having meetings.

My client attributed the problem to a lack of usability. Usability (as the term is commonly used) refers to the ease of use of a product's user interface. But a lack of usability was not the reason that the product was failing. Amazingly, the image editing software was fairly usable--yet in this context, it was perfectly useless, because it was not well suited to the task at hand.

On the surface, the application was a pretty good one. It had a long list of features. The software could capture what you drew on the whiteboard, and it let you edit it. You could choose color, line width, and pen type. You could annotate with a keyboard. You had 5 different kinds of erasers. You could play the drawing back in stroke-by-stroke mode: it was kind of cool to watch your drawing re-emerge line by line.

But none of these features matter to people in meetings: these folks just need to capture an electronic record of what happened in their meeting. They need meeting-capture software. And at the time, that didn't exist. So it's understandable how my client could have made this mistake. After all, from a technical perspective, image editing and meeting capture appear similar. You have to capture an image in electronic format, save it as a file, and allow people to do some editing on the image that results. Seen this way, it's understandable that my client reached out for an image editing application. In the end though, the right solution turned out to be inventing a new product: meeting capture software.

Don't misunderstand my point: usability is certainly important. Some companies, take OXO for example, have had great success with it. They've made a tidy sum by making vegetable peelers more usable. They started with a mature, popular product and refined it by improving it's usability. Long before OXO entered the picture however, the swivel-bladed peeler was invented as a paring knife replacement. Now, paring knives are great. They're simple, durable, and adaptable to a wide variety of kitchen jobs. But if you aren't skilled with a knife, it's hard to use them for paring. Without knife skills, paring knives become slow, clumsy, and dangerous. In other words, they're unsuitable for the task. For the home cook, the swivel-bladed peeler is a welcome development: it's much more suitable to the job.

But software is not kitchenware. Kitcheware is old. Software is young. Kitcheware is concrete. Software is ineffable--very nearly infinitely malleable. In our industry, we have relatively few mature, popular well-defined products. Instead, we are generally very early in the life-cycle. We should not be focusing on product refinement methods to lead us to the promised land. Instead, we need to be looking at product definition methods. Put another way: in this early phase of our industry life cycle, the question of suitability is much more important than the question of usability.