No Section...

VII.2 March-April 2000
Page: 11
Digital Citation

Design briefs: Apple


Authors:
Elizabeth Dykstra-Erickson, Peter Hoddie

About Apple

Apple ignited the personal computer revolution in the 1970s with the Apple II, and reinvented the personal computer in the 1980s with the Macintosh. Apple is now recommitted to its original mission—to bring the best personal computing products and support to students, educators, designers, scientists, engineers, businesspersons, and consumers in over 140 countries around the world.

Philosophy of Design

Apple’s software development product process is document-driven. Key documents are prepared by individuals from marketing, engineering, and human interface design, and are reviewed by those and other company departments including representation from instructional products and developer support groups.

Documents relating to human interface design describe in depth the user experience requirements together with detailed specification of the visual appearance and interaction behaviors of the product. Careful and well-grounded consideration of the user experience is key to producing quality results. The Macintosh Human Interface Guidelines establishes our fundamental design principles, including the use of metaphors, input paradigms (direct manipulation, see-and-point, and WYSIWYG ("what you see is what you get")), consistency, user control, feedback and dialog, forgiveness, perceived stability, aesthetic integrity, and modelessness. The ability to use more than one method to achieve a particular goal—the flexibility of the interface—is an important aspect of the user interface design, as it leads to an interface that is accessible to novice users while still offering shortcuts for power users.

The QuickTime organization’s human interface design team applies these principles to the context of QuickTime media. Although the Human Interface Guidelines address document-based productivity applications, they are silent on many issues that arise when working with digital media. Part of the challenge to our team is to integrate digital media into the Macintosh user experience in a way that is consistent, or at least not at odds, with the established norms. Our design team creates interaction designs, visual designs, and prototypes to explore new directions. Human interface design is valued as an important part of the product cycle. This is reflected in our bug-reporting system, which often contains lengthy written exchanges concerning a certain visual or interaction aspect of a product under development.

The role of human interface design is distinctly different than the role of engineering. Programmers typically outnumber human interface designers by a ratio of 5 to 1. These programmers often have extensive experience in both designing and building the human interface for their products. Therefore, it is important for human interface designers to be both proactive and responsive, and to work well collaboratively with programmers and quality-assurance engineers. Apple has a long history of promoting and evolving good design; this is partly accomplished through encouraging debate, documenting design rationale, and knowing when to stop exploring design alternatives. To the degree that the population reviewing a design is large and diverse, the design can benefit from their range of experience. We have found that there is no shortage of opinions on design, especially on aesthetics. Nevertheless, the challenge is that people always look at the design from the perspective of how they would use it—a reasonable thing to do—but if they are not the kind of user for whom the product is being designed, their input may not be applicable.

Design Process

Our design approach is to first consider what we want to enable the user to do and how the user is likely to try to accomplish the task given the user’s experience and skill level. We then quickly develop several distinct designs from which a preferred approach is selected. Once the preferred solution is identified, we review the engineering and pragmatic constraints. We deliberately do not consider engineering constraints until after a preferred design has been selected. This approach frees the design team to explore a wide range of possibilities. Of course, sometimes the design may not be possible to implement because of limitations of the current technologies, the product’s schedule, or other constraints. In this case, the design and engineering teams collaborate to create a design that is both useable and implementable. Once a design direction has been established, team meetings are held regularly to review progress on documentation and implementation.

The design process usually involves a core team consisting of an interaction designer, a visual designer, programmers, and a project manager. An extended team including representatives from throughout the entire organization participates at different points in the process. The extended team includes quality engineers, documentation writers, marketing, and senior management.

Brainstorming is frequently used to elicit design ideas that are then refined by the design team and re-presented to the extended team. Design reviews are held with the extended team and may be held with other groups, particularly other design teams. The designer’s job satisfaction lies in delivering a well-grounded, thoroughly thought-out set of design specifications. Designs that are not used are revisited in other products on other timelines.

When we search for candidates for design positions in QuickTime, we look for design excellence in a portfolio or other method of displaying design work, experience with tools, and the ability to work collaboratively with talented and customarily opinionated colleagues. Academic preparation for this responsibility should include not only instruction in tools and methods, but practical problem-solving and think-ahead skills, especially valuable for complex interaction problems. We also look for people who are articulate in discussing their work and are open to input; a design is not implicitly "owned" by the designer, but rather by the entire core design team.

We consider the focus of visual designers and interaction designers to be quite different, and an interface design of any complexity requires the skills of both types. In our experience, when these two roles are performed by a single person, that individual is invariably much stronger in one area than the other, and the resulting design clearly shows the designer’s particular weakness.

Design Project Example

QuickTime is an extension of the user’s operating system; it is not a single application. QuickTime provides services that are used by many applications. The primary applications through which most users experience QuickTime are PictureViewer, which enables the viewing of still images, and MoviePlayer, which enables the viewing and manipulation of time-based media. In 1999, we added many new features to MoviePlayer, including a revamped user interface, and introduced it as QuickTime Player as part of QuickTime 4.

Our overall design problem was to produce a convincingly consumer-oriented interface that is extremely easy to use and encourages exploration. We decided to take a gadget approach to the media player consistent with Apple’s past history of media players with user interfaces that employ a device metaphor. Our design team consisted of the authors, a graphic artist, Tim Wasko, and a small but influential set of managers from marketing and software engineering including our iCEO, Steve Jobs. We discussed the aesthetics we wanted the player to assume. Simultaneously, we distributed the features (and consequently, their controls) into first order, second order, and "soup" (everything else). With these basic guidelines in place, we then got to work developing visual "comps" on a weekly basis.

Initially, we worked with pictures instead of interactive applications because it let us more rapidly create multiple designs. We brought dozens of high-quality color printouts to each design meeting, often comprised of scores of iterations on quite small design elements. This let us literally lay many options out on the table so that we could point to them, rearrange them, and discuss them much more quickly than would be possible had we been looking at them on the computer screen. We maintained a visual portfolio of designs that was brought to each meeting so that we could easily view the sequence of design ideas and the evolution of the player overall. We checked our designs on screen as well, because things do not look quite the same on paper, and one of our design goals was for the software to look and act the same on both Windows and Macintosh computers, whether displayed on LCD screens or CRTs. Finally, we created a wire-frame model of the player as a physical device. This helped us understand surfaces, elevations, and the intersection of planes so that our rendering of an on-screen device would be convincingly realistic.

Having already determined which features and controls would be used most frequently and which would require easy access, we distributed first-order controls on the face of the player, and we placed second-order controls into a series of trays and drawers with one-button access from the surface. Controls that fall into the "soup" category are accessed through a series of panels in a separate dialog. The tray and drawer metaphor lets users easily bring up and put away audio and video transport controls that were formerly hidden in dialogs and/or accessed by multiple key combinations. To determine an appropriate visual appearance for all of the player’s elements—window definition, buttons and labels, feedback areas, and partitioning of the controls—we designed a consumer electronics look and feel derived from many hours of research in industrial design and illustration publications, product catalogs, and even consumer electronics warehouses.

One design problem we faced was the lack of state visibility of toggles that switch their glyphs when activated to represent the alternate state. The MoviePlayer application used a single button to express both play and pause. However, in the play state, the glyph on the button reads "pause." In the paused state, the glyph on the button reads "play." We determined that state representation on a toggle is a known problem through research and usability tests conducted by other organizations and reported in the proceedings of CHI conferences and other venues.

We decided to improve the visual feedback for play and pause used in the original MoviePlayer control bar by reserving a button for each state in the new design. This had the happy coincidence of working synergistically with our physical gadget device look and feel. User feedback has been as expected: Novice users report no difficulties using the controls, and experienced users who were accustomed to the behavior questioned the necessity of the additional button but had no difficulty using the new design. Overall, the design change supports our design philosophy for this application: It increases the predictability of the application by leveraging positive transference from consumer electronics.

This example is one among many new conventions that we introduced in our user interface. As of this writing, we have 22,000,000 users, most of whom are consumers who use the application simply to play movies. Some content developers and software authors who use the pro version of the application for editing media report that they prefer the previous interface. Aesthetic sensibilities aside, one thing that we learned in this project is that changing a well-known interface polarizes users. And the ones who felt most strongly that they either loved it or hated it took the time to let us know.

Authors

Elizabeth Dykstra-Erickson
Apple
eade@apple.com

Peter Hoddie
Apple
hoddie@apple.com

Figures

F1Figure 1. With the QuickTime 3 interface, movie is paused.

F2Figure 2. With the QuickTime 4 interface, movie is playing.

UF1Figure. Elizabeth Dykstra-Erickson and Peter Hoddie of Apple —Photo by Sam Bushnell and Steven O. Lemay

Sidebar: Company Snapshot

Job Titles for Design and Usability Positions
Human interface designer and graphic artist.

Job Qualifications
Three to five years of industrial experience and a relevant university degree(s) are required.

Number Employed in Design and Usability
Five people are employed in the QuickTime organization.

Breadth of Project Teams
Normally 6 to 10 individuals.

Sidebar: Practitioner’s Workbench

Favorite Publications
Dix, Finlay, Abowd, & Beale. Human-Computer Interaction (2nd ed). Prentice Hall, Europe, 1998.
Fowler. GUI Design Handbook. McGraw-Hill.
Fowler & Stanwick. The GUI Style Guide. AP Professional, 1995.
Mac OS 8 User Interface Guidelines (http://developer.apple.com/techpubs/mac/HIGOS8Guide/thig-2.html)
The Windows Interface Guidelines for Software Design. Microsoft Press, 1995.
Norman, D. Things that Make Us Smart: Defending Human Attributes in the Age of the Machine. The Voyager Company, 1994.
CHI conference videotapes
ID Magazine, SIGCHI Bulletin, International Journal of Human-Computer Interaction, ACM Transactions on Computer-Human Interaction, DesignIssues, IdN (International Designers Network), Artbyte, Communication Arts, interactions, Leonardo: Journal of the International Society for the Arts, Sciences, and Technology.

Tools
Adobe Photoshop, QuickTime Player, Studio 32, Macromedia Director, Ray Dream Studio, SnapzPro, SoundEdit, and Inspiration

Favorite Quotes
"Consistency is a great goal when it makes sense." —Don Norman
"Form follows meaning." —Klaus Krippendorff

Sources of Inspiration
Our customers!

©2000 ACM  1072-5220/00/0200  $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 © 2000 ACM, Inc.

 

Post Comment


No Comments Found