Increasingly, interactions are taking place on screens and devices outside the desktop/PC environment in products sometimes referred to as "convergent." Converging are the traditionally distinct worlds of screen-based interaction design and the industrial design of physical objects. As a result, interdisciplinary design teams must collaborate to choose physical controls that will delight people and lead to a pleasing aesthetic, while still supporting the functional needs of the product. This often involves balancing the desire for simplicity of appearance with the need for sufficient controls to serve the product's intended use, with minimum effort.
Finding this balance isn't easy. The recent success of the Nintendo Wii and the Apple iPhone illustrates how much attention has come to be focused on the way the products are controlled. A great deal of the delight delivered by both products comes from the intersection of physical controls and on-screen behavior. The "wow" factor of both of those products cannot be ignored, and each is as much about being different as they are about being useful. This seems to suggest that the choice of controls is not simply an evaluation of what is usable or learnable but also what will delight people, and in some cases, surprise them.
I work at a design consultancy called LUNAR, where we engage in a process that involves engineers, industrial designers, interaction designers, and clients, all collaborating to bring different perspectives and expertise to bear. In this article I'll describe some of the convergent work we've completed and indicate some best practices on developing physical interactions that offer both usability and delight.
Convergence is a chicken-or-egg question: Which comes firstthe controls or the behavior? Physical controls and on-screen interactions are inextricably linked, and designing one in isolation from the other is a certain path to an awkward product.
Let's look at a few examples of how physical controls inform the interaction design of the product. Consider the difference between a touch-screen in-flight entertainment system, an MP3 player, and the typical ATM. Virgin America's RED in-flight entertainment system uses "direct manipulation," wherein users interact with visible on-screen elements, yet this seemingly novel interaction paradigm forces a new size constraint on interface elements: Every interactive element on the screen must be finger-size. An additional unintended consequence of this design decision is that passengers press the screen controls harder than they need to and end up jabbing the seat of the person in front of them. Compare this product's convergent interaction approach with that of an iPod Nano. In order to fit several songs on a single screen, users move a cursor and make selections using a jog wheel. This helps keep the product small while still providing access to a fair amount of information on the screen.
ATMs present yet another model. "Soft keys" are used to execute the commands that appear on the screen next to them. This allows for the use of physical controls without having to either limit the number of commands available or having a dedicated button for every command. In many cases soft keys are used in public interfaces, due to concerns about the cost and durability of the screen component. It's worth noting that more touch screens are appearing in kiosk products like ATMs, as cost and durability are improving.
These examples illustrate the types of basic approach paradigms to consider when tackling a convergent product.
Product designers are often in the position of having to define the physical controls in advance of designing the on-screen interactions. Choices about physical controls affect the entirety of the product development cycle: They describe what parts the engineer must select, which directly affects the final cost for the consumer. Development schedules usually can't wait for the design team to consider each possible combination of controls and interactions, and so a designer approaching a convergent problem must find a way to better manage risk and reward than simple trial and error.
While this may feel daunting, there are some simple steps interaction designers can take that will facilitate collaboration with industrial designers and engineers and lay useful foundations for interaction design. Choosing the right controls means building a successful partnership between industrial design, mechanical, electrical and software engineering, and interaction design.
Many interaction designers focus on Internet and desktop applications, where they are supposedly freed from having to make these types of decisions. But it is worth noting that many of the same skills that serve designers when designing onscreen controls are required in the physical realm too.
Discussing aesthetics or non-functional aspects of product design in a multidisciplinary team setting can be challenging. It can be helpful to gather imagery of a variety of comparative products to understand what has already been produced and to discuss the relative merits of each item.
A convergent designer can help facilitate this conversation by asking people to evaluate controls in different ways. Which are unique? Daunting? Overplayed? Costly? Difficult to use? Difficult to develop for? This type of conversation, initiated at the beginning of a design problem, will help the team understand how different disciplines think about the problem.
This sort of exercise is easy to conduct with clients or other stakeholders too.
Before diving into choosing controls and making decisions, there are several constraint-based decisions that should be explicitly considered. Typically, these constraints fall into two buckets: those related to hard or concrete development issues, and those softer, more emotional factors related to the person who will eventually buy and love the product.
Constraints to consider:
- Cost: the actual cost of the UI component or license that directly affects the end cost. Cost is especially important when the product is highly commoditized or when the business model isn't a direct purchase by the consumer. Many medical products that rely on subsidies or reimbursement can be highly cost-constrained.
- Development Complexity: the effort needed to integrate a control. For example, capacitive controls require more electrical-engineering time to implement, and developing a touch screen can require additional software-development time.
- Size and Placement: especially on smaller devices, actual components can be prohibitively large. Designers will also need to think about the overall layout of controls. Is the product intended to be used one-handed? What controls can people comfortably reach?
- Functional Complexity: Everyone wants a "simple" set of controls, but it is important to include enough command vectors to support the required feature set. This is explained in more detail below, as it is a critical step for interaction designers.
Emotional factors to consider:
- Perception: how will the product look on a shelf or in an advertisement? Currently, fewer controls make for a more appealing product (though this hasn't always been the case). When a product looks simple, people focus more on aesthetic details. Customer perception is also crucial to adoption, and emphasizing a simple appearance increases the chance people will buy it. The designer then must balance the eventual usability of the product with that simple appearance.
- Differentiation: if the product is in a well-defined category, success might mean breaking away from the known paradigm.
- Iconic appearance: especially for products in a new or redefined category, controls will be like facial features that make the product instantly recognizable.
- Approachability: consider the audience and whether they will be comforted by familiar controls that they know from other devices, or whether that is distracting.
Reviewing this list will likelyand hopefullygenerate lots of questions. It is then useful to task different team members with conducting appropriate research to help evaluate different options against these various factors.
It's also worth discussing which considerations are more binding than others. Often the engineering team members will focus on hard constraints, where the design team will focus on the emotional and user needs. Involving the business decision makers in reviewing these considerations will help answer some key questions. How important is cost in relation to size? How important are the aesthetic elements to the brand?
For the interaction design team, a key step is identifying core product functionality that will demand the most from the control set. At this point, it is important to consider how much benefit a particular piece of functionality yields.
As an example, LUNAR recently designed the PASCO Spark. This product helps students in grades 612 learn scientific principles by using sensors to observe and visualize scientific phenomena. We knew that the user's need for simplicity, durability, and a large screen outweighed the needs for fine control or lots of data entry, which might not be immediately apparent when discussing a scientific tool.
In order to support our instincts for simplicity, we mapped out different characteristics of the product against what different users would need.
This led to an important design decision: While it might make some complex interactions challenging, a single button and a large touch screen would afford us the desired perception of simplicity that was so critical to product adoption. The single button would be used to start and stop collecting data in the field; this button, then, needed to be usable by either hand. The large screen implied that the device would become sizable enough that two hands could be used to hold it.
By deciding to restrict ourselves to only one button, we certainly faced challenging interaction design moments later in the process. Since every touchable element needed to be approximately a centimeter square, we had to scale back functionality in order to fit necessary controls onto the screen. Yet our single-button decision also helped us to manage feature creep, as it's difficult to add features arbitrarily when there is no physical room to afford this feature growth.
In many ways, physical controls on a product are like the facial features on a person. Just as it is important to consider the functional demands on the product, the industrial design team should look at the impact that different controls and layouts have on the overall product expression.
The handle features on the Spark turned out to be an important signifier of "durability and ruggedness" for the product. They also helped to distinguish the product from competitors and from more generic ultra-mobile PC products.
A large screen also meant that the on-screen UI would be a big part of the overall expression, so we quickly moved into explorations about how the visual design could support a message of simplicity and power.
These explorations were done before the user interface had been fully designed to help us understand how color and scale affected the overall product. These exercises gave us a sense of how many touchable targets could really be supported, and to provide a sense of how dense information could get.
Even more than on-screen affordances, physical controls provide clues to the user about what they are supposed to do in a given situation. It can be especially tempting for product managers to try to leverage recognizable controls, yet following existing paradigms without rhyme or reason can lead to problems.
The Sansa C100 MP3 player featured a circular "wheel" that strongly emulated the iPod, but the actual component doesn't turn or spin. Instead, it functions as a typical four-way navigation pad. When LUNAR worked on the C200, we advocated for a square component that both distinguished the product and more closely followed how the UI worked.
This might seem obvious to interaction designers who are conditioned to think about how form and function match, but these kinds of decisions can get lost in the larger design shuffle if interaction designers aren't working closely with the development team to review assumptions about controls.
Working on physical products is a lot like designing on-screen interactions, but it involves working with a different cast of team members who have different skills; additionally, this team frequently has a very different orientation to the design problem. To be effective, a convergent designer can focus their role in the process by helping to:
- Build interdisciplinary communicationbalance the desires and motivations of industrial designers, mechanical and electrical engineers, software developers, and interaction designers.
- Be a facilitator and bridge builderremind the team of user needs, market forces, competitive landscape, and technical constraints.
- Work smarter, not harderavoid the "try everything" approach. Guide the team to a shortlist of plausible and compelling alternatives that can be meaningfully explored.
- Be realisticdon't ignore real constraints like size or cost, but don't let them make a decision for you. Help the team manage the implications of the choice on the design.
Gretchen Anderson is the director of interaction design at LUNAR in San Francisco. She has worked for firms that do both industrial and interaction design on a wide variety of productsfrom medical products and consumer electronics, to enterprise software applications and consumer websites. Gretchen was educated at Harvard and has worked in the design industry for more than a decade with clients that include Starbucks, Virgin Records, HP, Microsoft, Intel, and Johnson & Johnson.
©2008 ACM 1072-5220/08/0900 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2008 ACM, Inc.