The cardinal error of design is to survey your users, observe what they do, gather your use cases, understand the use cases in detail, and then design your artifact to embody each of those use cases as directly and faithfully as possible. It’s to design your artifact explicitly according to the way it’s supposed to be used.
Wait, what? Isn’t this how you are supposed to do design?
It’s not. People will not use your system the way you designed it to be used. It’s a mistake to assume it will be used one way, or five different ways, or as many ways as you’ve explicitly enumerated. However many distinct use cases or paths you identify, people will use it in more ways. They’ll use it their way. They’ll combine different ways and jump between one use case and another. Or they’ll interpose a different product in the middle of using yours. A well-designed product accepts that actual use patterns are emergent. You cannot list them, but you can hope to facilitate as many patterns as possible beyond the ones you’ve envisaged.
It’s a schoolboy error in design to put intentionality over emergent behaviour, vision over humility, and design products that force people down strictly defined paths. You see it in architecture that herds people through it, tedious and constraining digital interfaces, infuriating commerce sites, games that are too linear and monotonous, and appliances that don’t let people do what they want they way they want. These designs fail.
Suppose your use case research identifies three ways people approach problems. Some like to go through steps linearly in an organized way. Others like to dart between sub-problems; while others like to confront the whole big question at once. Here is absolutely the wrong way to design your system:
The design above is lazy, if not outright conceited. All we’ve done is embody each of the use cases directly in the design. We present the public with a choice of where to enter, which at best is hard to understand, and then trap them into one path. What’s missing in the step of synthesis. you need to think not how to embody the use case, but how to enable it. The thing that you design is not the same shape as the use case. It’s a shape that allows all the use cases to happen through it simultaneously.
Here’s a superior design to achieve the same thing. It’s not the only way, but it is one way to enable the use cases you’ve identified and allow many others to emerge:
As a concrete example of good design consider the Android phone interface for making calls. A novice designer might think that designing the outbound calling interface is fairly straightforward: People dial the number or select it from the contacts. They ring, speak, and hang up. Right? No.
Some people will indeed dial the number. Others will select it from the phone’s contact list. But others will pick the number from their Skype contacts or may initiate the call itself from Skype. Some will speak the number to the phone, while others will want to dial a number that they hear in-call, for example someone’s number provided in a voicemail (Google, how about a function to do this?). Some people will cut and paste the number from emails or web pages. Yet others, perhaps couriers or door-to-door sellers, will initiate all their calls by picking the numbers of businesses in Google maps. And these are just some ways of initiating the call. During the call people may do all kinds of things like take notes, look at maps or their web mail, try to add people, or play music into the call.
Android is successful in large part because the designers did not design just one, or two, or some ways to perform its functions. They’ve done the design synthesis and identified different intents, such as making calls, playing a sound, or looking at a web page, and then gave the system junctures at all those intents. Different apps such as the built in dialler, Skype, or maps can pick the number. Different apps can run the call. And during the call intents like referring to a web page can jump to yet another app. That’s what allows the use patterns with an Android device to be emergent and makes it one of the most successful interaction designs to date.
So, respect your public and don’t ever design things to be used a particular way. Anticipate some ways they might be used and with humility allow these, and other, uses to happen.