Swim's distinction among design firms is that its sole focus is interaction design. Our field is young, and we feel there is much to explore in creating methods and tools for addressing interaction issues. When projects call for additional areas of expertise, we collaborate with consultancies that offer services such as product design, software engineering, marketing, or branding.
Our small, multidisciplinary team consists of people with various backgrounds relevant to interaction design, including graphic design, computer science, and psychology. We feel that different points of view are required to effectively address interaction design problems and advance our design process. Our working environment is informal and conducive to impromptu brainstorming. Approaching projects with a tight-knit, cohesive team suits us, and our clients, well.
At Swim, we perceive interaction design as a broad design discipline that includes human interface design. We have developed the following definition of interaction design to describe what we do:
Interaction design is the design of products that reveal their functionality over time. These products possess a microprocessor and, typically, a dynamic visual display.
Note that our definition uses the word functionality and not content. Swim's focus is on tool-like productsproducts in which communicating functionality is paramountrather than content-like products that primarily deliver information.
Our definition includes the design of Web or desktop software applications. But it also includes interactive hard productsproducts such as cell phones, information appliances, and medical devices. Working on products with different capabilities and constraints leads us to a better understanding of the nature of interaction. That understanding is our ultimate goal.
We believe the interaction design discipline must address two distinct issuesbehavior and representation, in that order. By behavior we mean the structure of the functionalitywhat the product does, and when. Representationwhich includes graphics, audio, and terminologyaddresses the way in which the behavior is communicated. We initially focus on behavior because we believe the structure of functionality sets the requirements for the look and feel. The boundary between defining behavior and crafting representation is not neat and tidy; some overlap invariably occurs. For example, specific visual requirementsranging from large, full-color, bitmapped displays to black-and-white segmented LCDs [liquid crystal displays] with limited line lengthinherently affect the way behavior can be organized.
Swim joins projects at widely varying points in the development process, but we prefer to be involved earlyduring product definitionwhere we can have the greatest impact. Before being hired by a client, we obtain a project overview, assess the situation, and suggest a course of action appropriate to the specific client's goals, schedule, and budget.
We typically propose a user-centered design program that includes up-front user observations and user testing of iterative prototypes. As mentioned earlier, we tend to divide the work into phases addressing behavior first and representation second. However, each design project is unique, and we adapt our process to create a custom program that meets the specific needs at hand. The following steps describe an idealized design program.
Step 1: We gather information
In this initial phase, we elicit background information from our clients about the project, which we expand by conducting our own user observations and interviews. We meet with potential or current end users to understand the context of use and the nature of their tasks. These informal observations may involve as few as two or three subjects, but even this small sample provides us with invaluable contextual information. Information gathering often continues implicitly throughout the project; we are continually learning about the specific domain of use as well as additional constraints on or conditions of implementation.
Step 2: We design the behavior
We begin design ideation after the initial round of information gathering. There is no one path we use to arrive at ideas; we explore, we sketch, we brainstorm. We often start by designing the product's behavior and constructing schematicsblueprints of the functional flowwhich consider delivery platform constraints and implementation strategy but do not incorporate a specific visual style. We refer to this as the interaction architecture.
We may build hardwired prototypes based on these schematics, using Macromedia Director®, Macromedia Flash®, or HTML, for use in informal user testing. Test results drive refinement of the schematics. Our refined schematics sometimes serve as an initial implementation specification, which allows the development team to begin coding early in the design program.
Step 3: We design the representation
Using the schematics developed in the previous step, we derive an inventory of required representation elements that will make up the interaction design language. Swim typically explores several visual styles for this language, incorporating the client's brand identity if appropriate. We also address terminology, occasionally developing all text messaging. At times we may revise our earlier prototypes to incorporate visual designs and proceed with additional informal user testing. Ultimately, we provide the implementation team with final representation specifications in a form that best suits its needs. For example, design deliverables for a Web application might consist of a layout grid and all required GIFs. Deliverables for a device might consist of the specification of a font, icons (both on screen and in product graphics), and a layout for cutting a custom LCD mask.
Step 4: We provide ongoing support
During development, unanticipated issues may arise with the design we specified. We work closely with development teams, providing new or alternative solutions to ensure consistency is maintained.
Swim, working with Life Fitness Inc., applied a user-centered process to design two software products that provide workout information and tools.
We entered into the project after consultant Colby Marketing identified issues with the kiosk-based system currently installed in gyms. That system failed to attract gym members and did not support personal trainers who required significant data entry and manipulation. The marketing analysis recognized the need for two distinct products: a Microsoft Windows® PC application for the trainer (the Trainer's Workbench) and a touch screen kiosk offering less functionality (the Workout Kiosk) for members to use on the gym floor.
Swim's role was to translate the marketing requirements into specific functionality and devise viable interfaces for both products. One constraint Swim faced was the development team's decision to build the Trainer's Workbench in Microsoft Access®.
We conducted two interviews with personal trainers who have greatly differing practices to quickly learn about the personal training domain. We met with one trainer working at a high-end club in San Francisco, where each new gym member automatically receives some personal training. The other trainer worked with a small number of clients in his home gym. We observed how each trainer kept client records, noting how workout routines were communicated and actual workout sessions were recorded. We also collected additional workout artifacts from other clubs.
Swim then assembled an initial schematic incorporating findings and visualizing ideas that previously had only been discussed informally. We used the schematic in a working meeting, to solicit feedback and critique from the entire Life Fitness team and move us all toward a common product vision.
Subsequently, we built two rounds of prototypes of the Trainer's Workbench using Director. The prototypes simulated realistic interactions and included realistic data (see Figure 1), verified by content experts. Each prototype was informally tested with three to five personal trainers. Each trainer was asked to complete a few tasks (e.g., "determine the workout John Smith should be doing this week"), interpret the information shown, and voice general impressions. Although the testing sample was small, we visited different styles of gyms (e.g., a high-end club and a YMCA) and met with different types of trainers (e.g., a retired man who was now doing personal training and trainers following a rigorous procedure devised by their gym). We incorporated into the more functional second version feedback from testing the first prototype. We also presented an initial Workout Kiosk prototype when testing the second Trainer's Workbench. We used this strategy to obtain feedback on the Kiosk design, because the project's schedule could not permit testing with typical Workout Kiosk users.
We prepared a final specification package according to the results of the second prototype test. The package included documentation describing primary functionality and behavior for both applications, as well as a final revision to the Trainer's Workbench prototype. It also included three distinct visual design directions for the Workout Kiosk, emphasizing one of our insightsthat different clubs with different corporate identities might want to deliver core functionality with a customized lookand feel (see Figure 2).
Gitta Salomon, Principal
Jason Ward, Interaction Designer
Tzufen Liao, Studio
Swim Interaction Design Studio
449 Powell Street, Suite 201
San Francisco, CA 94102
Phone: +1 (415) 477-8624
Gitta, principal and founder of Swim, has been practicing interaction design for more than 15 years. Before founding Swim, she was a member of Apple's Advanced Technology Human Interface Group and director of interaction design at IDEO Product Development. Gitta received her bachelor's in mathematics from the University of California at Los Angeles and a master of visual studies from the Media Lab at the Massachusetts Institute of Technology.
Jason joined Swim in 1999. Prior to Swim, Jason worked in cultural resources management at Parsons, a global engineering organization. Jason brings problem solving, ethnographic and visual designexpertise to the design of interfaces for both enterprise and consumer products. Jason earned a Bachelor's degree in anthropology at Oregon State University and also holds an Associate Degree in graphic design.
Tzufen originally studied Communication at the University of Pennsylvania and obtained her MFA in Sculpture from the Cranbrook Academy of Art. Prior to joining Swim in 2000, she studied 3-D computer animation at New York University and created commissioned pieces to accompany sculptural installations in the U.S. and Europe.
Education or professional experience in graphic design, information design, human factors, product design, or computer science, with an emphasis on interface or interaction design
Strong problem solving and analytic skills
Excellent written and oral communication skills
Knowledge of software methods and constraints resulting in the ability to specify implementable solutions
Number of individuals employed in design and usability
All of Swim's employees are interaction designers. The staff has fluctuated in size from two to six people since Swim's inception.
- Apple Computer, Inc. Macintosh Human Interface Guidelines. Addison-Wesley, 1992.
- Sun Microsystems, Inc. Java Look and Feel Design Guidelines. Addison-Wesley, 1999.
- Tufte, E. Envisioning Information, Graphics Press, 1990.
- Tufte, E. Visual Explanations, Graphics Press, 1997.
- Tufte, E.The Visual Display of Quantitative Information. Graphics Press, 2001.
- The Wall Street Journal, Print, I.D. magazine
Adobe Illustrator®, Macromedia Freehand®, Adobe Photoshop®, Adobe InDesign®, Macromedia Director®, Macromedia Flash®, Macromedia Dreamweaver®, Adobe GoLive®, digital still and video cameras
Sources of inspiration
Cook's Illustrated, San Francisco
©2002 ACM 1072-5220/02/0300 $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 © 2002 ACM, Inc.