Designing for Connection

What we've just been discussing under the guise of multitasking is adaptation: changes in the form, content, and functionality of devices and applications based on how and where they are used. With adaptation, users feel more emotional attachmenta connectionto their tools.

People use three primary ways to make devices and applications their own: customization and personalization, adaptation, and hacking. Collectively, these approaches facilitate a tighter bond between users and their tools.

Customization and Personalization

Customization and personalization are commonly used interchangeably, but in interaction design, they have specific, different meanings. Customization occurs when users alter the appearance of an object or application, either through the application of appearance-changing products (from sequins to spray paint to stickers) on physical objects (Figure 7.5) or, on digital products, through the use of controls (this is sometimes called skinning). There are whole industries, especially in the automotive field, built around customization. Although customization can make something look very different, it changes an object in a very limited way. It modifies only the surface of an object.

Figure 7.5. A customized mobile phone, encrusted with rhinestones. It's common in Asia to customize devices in this way, often with real jewels.

courtesy of Jan Chipchase

Personalization is a step beyond customization. Personalization alters the functionality of an entity to better reflect individual choices. It changes not only the surface. Personalizing changes how something works. Changing a shortcut keystrokefor instance, replacing Command-X, the Cut command on a Mac, with CommandKis an example of personalization.

Personalization requires the object, if it isn't wholly digital, to have some sort of digital component that the user can use to indicate preferences and settings. Personalization requires users to explicitly set preferences (Figure 7.6) for the variables that can be personalized (how often to check e-mail, default sound volume, speed-dial numbers, and so on).

Figure 7.6. The Preferences window in Microsoft Word. To set preferences, you have to stop what you're doing, find the preference you want, and set it. If you had to do this frequently, the process would be disruptive.

Adaptation

The alternative to deliberate manipulation and maintenance is adaptation. Adaptive tools change their form, content, and features based on how and where they are used.

The present world is full of static objects that force people to adapt to them, either by customizing or personalizing (or by hacking, discussed later in the chapter) or simply making do. But by harnessing the increased power of digital devices, interaction designers can create objects that learn, react, respond, understand context, and perform tasks that have personal meaning. These smart, clever devices and applications respond to people by changing shapetheir form and contentdepending on the context of use.

Adaptation is an ongoing process that unfolds over long time periods. Thus, it takes into account life changes that traditional products are not equipped to respond to or understand. Suppose, for example, I go on safari and can't check e-mail for several weeks. With my current e-mail client, if I don't specifically give it instructions (for instance, by setting the Out of Office option), my e-mail will simply pile up. An adaptive e-mail client, however, would notice my sudden drop-off in checking and clearing out mail by comparing my usage to my usual activity. The application would conclude (rightly) that something was different and adjust accordingly. It might, for instance, eventually contact e-mail senders in my address book and let them know that I haven't yet read their e-mail.

Adaptation can, of course, get really annoying if it isn't done well. Changes made too swiftly or too radically can be disruptive. Maybe you are doing something on a whim, like buying a Jessica Simpson single. You don't necessarily want your iTunes account to suddenly start purchasing all of Ms. Simpson's oeuvre for you.

Ideally, changes made by adaptive products should be small and should build over time. And if the system guesses wrong about a user's behavior, there needs to be a means of letting the system know that it guessed wrong.

Several years ago, The New York Times reported that many TiVo users who watched any TV show with a homosexual theme or character suddenly found that every show TiVo suggested to them had homosexual themes and characters. If this wasn't what a user wanted, the only way to make a change was to reset the whole TiVo device. Users need to be able to make corrections to a system's assumptions. And, as with multitasking, adaptation needs to be subtle and appropriate.

Achieving Flow

Another important concept to keep in mind when designing adaptation is that it isn't only the application or device that's adapting. There is a back and forth between the product and the user; they adapt and respond to each other.

Suppose, for example, that a user is learning an adaptive drawing application. At first, the user is crude and the system is simple. But as the user grows in skill and becomes more comfortable with the program, the program slowly becomes more sophisticated, allowing more complex methods. As the program becomes more challenging, the user has to learn more sophisticated techniques. If the user is struggling, the application may become easier to prevent frustration. The two entities react and respond to each other.

The purpose of this back and forth is to achieve what psychology professor Mihaly Csikszentmihalyi described as flow (Figure 7.7). Flow, as described by Csikszentmihalyi, is "being completely involved in an activity for its own sake. The ego falls away. Time flies. Every action, movement, and thought follows inevitably from the previous one, like playing jazz. Your whole being is involved, and you're using your skills to the utmost."

Figure 7.7. Flow diagram, based on the work of Mihaly Csikszentmihalyi. If a task is too challenging for a person's skill level, it causes anxiety. If it is too easy, it causes boredom. When skill matches challenge at a high level, this condition is called flow.

Flow, and ideally, adaptation, involve finding the correct balance between the challenge of the task and the skills of the user. Too much challenge produces anxiety; too little produces boredom. Adaptive devices and applications, if well designed, help users achieve this balance, this flow.

Designing for Adaptation

In designing for adaptation, interaction designers need to understand the deep structure of their products, but allow the surface structure to be adaptable and responsive. Designers have to determine what pieces of functionality and form are so central to the product that they never adapt. Designers also have to determine what are the "moving parts," and how those parts can change. Will the changes be digital, such as wearing a path through a Web site as with BBCi, or also physical, as with the Adidas_1, Adidas' athletic shoe that changes its physical form to conform to the way that the wearer runs? One thing designers have to wrestle with in designing adaptive products is their loss of control over the final product. (Such control is probably an illusion anyway.) Adaptive products change and grow, sometimesprobably oftenin ways that the designer never expected. They have no final product, no finished form. The users co-create these products, because the products adapt to them, not to the designer's will.

Designers Shelley Evenson (see the interview in Chapter 8) and John Rhein-frank came up with a set of guidelines for creating adaptive products:

• Let users do. Make sure the activity that the user is performing is of real value. Let the user's actions and the subsequent changes in the application or device feel as though they have been designed for the user personally.

• Orient. Give users a journey they can take. Don't steer; just provide a map to help users visualize what they want to accomplish and plan where they want to go.

• Let users win. Reward users when they accomplish something.

• Push. Help users learn. Help them reveal their potential, but don't let them just get by. Combine doing with understanding. Give users a skill they can use.

• Sense and respond. Personalize the application or device for each user. Let users feel that the artifact is alive. Make its operation transparent.

• Connect. Help users make connections with the subject matter or across destinations with other people.

• Immerse. Plunge users into the experience, so that users can't tell the difference between themselves and the device, it is so much a part of them.

With a successful adaptive design, the product fits the user's life and environment as though it were custom made.

Hacking

The traditional approaches to interaction design (see Chapter 2) don't provide for unknown needs. They are, for the most part, good for designing products that will be used in particular ways. But interaction designers need to realize that once a product is launched, users will use it in unexpected ways and for unexpected purposes. This is what hacking is all about.

Hacking is the repurposing of a product for a task that it was never intended to perform (Figure 7.8). It can be as simple as using a screwdriver to open a bottle cap, or as complicated as rigging a telephone system to provide free calls. Hacking can be benign as well as destructive. Sometimes hacking involves adding functionalityfor instance, adding a self-created phone book to a mobile phone. Sometimes hacking simply makes a political or social pointfor instance, several years ago, in a guerilla art project, the voice chips in Barbie and G.I. Joe dolls were swapped, leaving G.I. Joe saying things like "I love shopping!" and Barbie issuing commands like "Move out, soldier!"

Figure 7.8. A hack of an iPod by Collin Allen to connect it to an external hard drive.

courtesy of Collin Allen

Hacking can be thought of as a deep expression of personalization, of forcefully adapting a product and shaping it to a person's will, whether the person "owns" the product or not. It is a way of controlling systems that otherwise the user would have no control over, such as an operating system or a government bureaucracy or even children's dolls.

Since all products (and, indeed, services) can be hacked, should interaction designers encourage hacking? And if so, how? These are unanswered questions.

One reason to encourage hacking, even unofficially, is that hacking can bring to light new uses for a productuses that can then be officially designed for and marketed. That new feature a hacker added to your spreadsheet program may be useful to all users of the application. Those torn tennis balls that grandpa put on the feet of his walker could suggest ways in which walkers can be improvedor even whole new products (Figure 7.9).

Figure 7.9. Mobility Balls used a hack (tennis balls on the feet of walkers) to make an actual product.

Obviously, no company wants destructive hacking. At the least, it can raise privacy and public relations issues. You can be certain that Mattel was unhappy about the hacking of Barbie and G.I. Joe. Some companies, particularly car companies, turn a deliberately blind eye to it, for while hacking of cars does bad things to warranties, say, it also creates demand for certain types of cars that are known to be easily hackable, such as the Honda Civic of the 1990s.

Layers

One way to design for hackability is to use layersa concept first discussed by architectural theorist Stewart Brand but taken up by IBM engineer Tom Moran (Figure 7.10). The upper, or "fast," layers are where frequent changes take place. Lower, or "slow," layers are more stable and foundational. If products are designed so that the upper layers are more exposed (if the seams show, in other words), hackers can play with those, leaving the bottom layers to provide continuity and possibly to eventually integrate changes made in the upper levels.

Figure 7.10. A diagram based on the work of Stewart Brand and Tom Moran. The top, or "fast," layers can change more rapidly, while the bottom, or "slow," layers provide stability. Changes made to the top layers can make their way down to the bottom layers over time.

For example, in a typical, non-Flash or Flex Web application, the top layer (typically called the presentation layer or, really, the interface) is usually composed of HTML, XML, and CSS. The next layer down is a logic layer, which contains much of the functionality, often in what is called middleware. Lower still are the layers that hold the databases, data sources, and server software. Even lower are the layers that contain the physical servers.

If an application is designed so that those in the know (or those so inclined) can find the seams between some of these layers (for instance, from instructions hidden in the visible source code), then hackers can hack those locations to their heart's content. They can hack the upper layers (the CSS in particular) with the least amount of disruptionthey can make the application look like anything they want. But it's unlikely that any company will want hackers tinkering with its databases and servers, so those are placed in the lower levels.

Some companies expose layers out of necessity, and some to afford hacking. Microsoft and Apple both have application program interfaces (APIs) that expose middle layers so that third-party developers can write applications on top of their operating systems. Google, in its Google Maps API, encourages the use of middle layers for the creation of maps, making it, in effect, a platform for developers, designers, and, yes, hackers to create new applications on.

Note

An API is a set of commands, functions, and protocols that allows programmers to use predefined functions to interact with a system.

Dan Hill on Hackability and Adaptation

courtesy of Celia Romaniuk

Dan Hill is the head of interactive technology and design for BBC Radio and Music Interactive. He's charged with designing and building the BBC's radio and music-based interactive offerings across Web, digital TV, and mobile platforms.

Can products be made hackable, or are all products hackable?

Effectively, all products are hackable. If we define a hackable product as "a product capable of being modified by its user," then we've seen pretty much everything hacked.

But if this definition appears too wide to be useful, it's worth noting the range of products that have been hacked, apparently irrespective of size, solidity, complexity. Cars have been hackedwitness the ever-vibrant custom-car movement; buildings are endlessly modified and customized from day one; clothes often are; musical instruments often are; even apparently perfectly "finished" modernist products like Dieter Rams's Braun hi-fis have been heavily modified. Likewise the iPod, despite its hermetically sealed appearance.

What can be designed into products to make them more hackable?

For me, this indicates a reversal of some traditional design thinking. The maxim that "when design is working properly, you don't notice it" (this last from Germaine Greer, no less) is less useful with hackability in mind. If we are to invite the user in, we need to leave some of the seams and traces open for others to explore, some sense of what the process of design, or un-design, might entail. Naoto Fukasawa's idea that "good design means not leaving traces of the designer" makes sense in terms of reinforcing humility in the designer, but leaving traces of the design itself may be very useful to users.

Matthew Chalmers suggests we indicate a product's "seams" so that it might convey how it can be appropriated or adapted. This is beyond affordances (which concern predefined usage). This sense that the fabric of the product should communicate its constituent parts and how they are assembled runs counter to "invisible computing" thinking and much user-centered design, which argues that interfaces should get out of the way. Yet Chalmers' notion of "seamful systems (with beautiful seams)" is powerful when seen in the context of enabling hackability.

Creation of hackable products could include the following techniques:

• Make sure affordances and seams are clear and malleable.

• Enable interrogation, cloning, and manipulation on particular layers.

• Learn from the malleability, object-oriented nature, and social behavior of code.

• Build products that are self-aware in terms of behavior/usage, which then present those findings back to users.

• Enable products to emerge from this behavior, as well as from design research.

• Enable social interaction around products.

What are the qualities of adaptive designs?

The language around hackability is often littered with "hooks", "sockets", "plugs", "handles", and so on. With adaptive design, drawing from the language of architecture more than code, we have a more graceful, refined vocabulary of "enabling change in fast layers," "building on stability in slow layers," "designing space to evolve," "time being the best designer," and so on. This suggests that there could be a distinction, that adaptive design is perhaps the process designed to enable careful articulation and evolution, as opposed to hackability's more open-ended nature.

However, they still draw from the same basic concepts: of design being an ongoing social process between designer and user; of products evolving over time; of enabling the system to learn across an architecture of loosely coupled layers; of not overdesigning.

In adaptive design, designers must enable the experience/object to "learn," and users to be able to "teach" the experience/object. So it's a two-way interaction, in which the user wants to adapt the product, to make it useful to him or her. Therefore, the designers must concentrate on enabling this adaptation in order to achieve a useful experience, rather than attempting to direct the experience toward usefulness themselves. Designers shouldn't aim to control, but to enable.

You've spoken on putting "creative power in the hands of non-designers." How do interaction designers go about doing that?

First, in order to create these more adaptable products, interaction designers will need to work within multidisciplinary environments, communicating coherently with software developers and other disciplines. This means really understanding code; it doesn't necessarily mean coding, although that can be a useful communications medium.

Second, interaction designers will need to work with these nondesigners, often directly. The notion of design being an ongoing, social process means that designers have a responsibility to work with products and experiences after they've launched. This doesn't necessarily fit many of the development methodologies, and indeed business models, that interaction designers traditionally work in. But putting designers into direct contact with nondesigners will enable them to truly adapt products to their own needs, creating genuinely engaging experiences. This is a form of design literacy, perhaps, but also product literacy. It should mean being transparent in one's practice rather than obscuring the process of design.