H. J. Moll-Carrillo, Gitta Salomon, Matthew Marsh, Jane Fulton Suri, Peter Spreenberg
IDEO Product Development
1527 Stockton Street San Francisco, CA
94133
415.397.1236 vox 415.397.0823 fax
hector@IDEO.com
gitta@IDEO.com
mMarsh@IDEO.com
jane@IDEO.com
spreenberg@IDEO.com
The design also needed to accommodate a wide range of users; it would be
bundled with all Compaq computers. The main target group, however, were novice
and intermediate users. Novices were defined as first-time computer users who
expected some "out-of-the-box" functionality. Intermediate users were those
already familiar with computers at home or the office but not proficient enough
to significantly customize or troubleshoot their setups.
Figure 1 shows the three main phases of our iterative design process for this
project. Each one is depicted as a cycle because iterations occurred within it.
In the Observation/Visualization Phase we applied previous experience, knowledge
of related materials and insights gained from informal observation of users'
tasks, environment and tools to generate and visualize ideas. During the Product
Definition Phase we worked with the XSoft team - using these preliminary ideas -
to further refine the feature set and the proposed interface. Features and
interface ideas were approved, rejected or found in need of further refinement
based on perceived value, implementation constraints and product release dates.
In the User Test Phase key product elements were evaluated with users. These
three phases were part of a larger iterative process that lead to the final
product implementation.
FIGURE
1. Caption: The Idealized Process. Development of the interface
followed an iterative process consisting of three phases.
The remainder of this briefing describes our design process and provides
examples from each of the three phases to illustrate how and why specific design
decisions were made and how we collaborated with XSoft.
Organization/access refers to making current and relevant documents easy to
find and retrieve in order to work with them. Obvious and accessible spatial
groupings, such as piles, were used most often as a strategy for containing
these items. Users also needed to move documents from one place to another or
transfer ownership to others. Folders and binders were often the mechanisms used
to complete these transportation tasks. Safekeeping involved the use of drawers
and file cabinets to archive or secure items.
The character, style, functionality and interchangeability of real-world
containers varied greatly. We observed that most users kept tools and documents
close at hand but in distinct groups and containers. For example, pencils and
rulers were stored separately from documents. Three-ring binders were one
notable exception; some had penholders, rulers, pockets and floppy-disk holders
built into them.
In addition, the observations helped us validate the applicability of a book
metaphor - specifically a binder metaphor - as a container to organize and
access applications and documents within a computer system. We found that
collecting diverse but related documents into ringed-binders was an experience
familiar to most users. It was common among the users we observed to have
assembled these collections themselves or to have used them.
Norton Desktop for Windows replaces Program Manager with a Macintosh-like
"desktop" metaphor that makes use of the entire screen. It does so at the
expense of requiring significant amounts of the system's resources. Dashboard
uses a more abstract solution. The "dashboard" is a control panel that reduces
the amount of screen space required to perform file and program management
functions by using buttons that parallel Program Manager Group icons. The
metaphor is not expressed much further than the product name and the inclusion
of a single gauge to show system resource use. Dashboard speeds up access to
File Manager Groups and other system resources. At Ease - developed for the
Macintosh Performa line of home computers - substitutes the Macintosh Finder
with a system of folders and single-click buttons, trying to hide everything
from users except their documents and productivity applications.
FIGURE
2: In an early design left and right page turning controls were
separate. The tab title and page number appeared at the top and bottom,
respectively. The "ButtonStrip" on the left included pull-out panels to access
disk icons and system controls, in addition to application launching
buttons.
FIGURE
3:In this early design, application launching and system information
buttons were both attached to the "ButtonStrip" on the left. Color paper clips
were explored as a mechanism to mark specific pages within tabs. In this image
the paper clips are shown in different locations to facilitate discussion about
how they might be used.
Using the mock-up helped us to determine which representations were the most
economical and advantageous. We quickly noticed that the representation of a
realistic binder would require extensive use of perspective and foreshortening,
which would be difficult given the small color palette ( the standard Windows 16
colors ), low resolution and the fact that we wanted to devote as much screen
space as possible to functional aspects. Instead, we decided to explore simpler
representations of the binder's elements, relying on small details ( e.g., the
depiction of rings, hints of the cover texture framing the inside of the book,
dog-eared page corners, etc.) and subtle modeling to suggest a more
three-dimensional look.
We knew that performance issues curtailed our use of animation in the
interface but we tried to identify elements that would be useful and
implementable, such as page or tab turning effects. Experience with the mock-up
( and later computer simulations ) suggested that some of the easy and
transparent interactions of the real-world object would translate into
repetitive, and potentially annoying, animations on-screen and would require
abstract and un- intuitive control mechanisms to manipulate a fully
three-dimensional book layout. Using animation also meant punishing users of
less capable machines - those with limited storage capacity and slower processor
speeds - by either substantially increasing the size of the installed
application to include pre-rendered sequences or accepting the inadequate
performance of real- time animation.
The mock-up also revealed alternatives for binder/tab behavior and layout.
When laid flat and opened, the left hand side of the binder seldom contained
useful information, aside from the ( possibly hidden ) text of previous tabs.
Furthermore, on the right hand side of the open binder, tabs were only visible
if they were in the topmost row; looking at additional tabs required rotating
the binder or peering along its side. In an on-screen interface, the tabs would
have to be spread in order to view them all simultaneously.
Some functionality did not seem to work well within the book metaphor. For
example, including extensive system information and controls ( as in Dashboard )
cluttered the book and reduced the amount of space available for documents and
applications. <,p> We also considered how the binder-metaphor shell
functionality could be integrated in upcoming versions of Windows. What
longevity and perceived value would a shell have? How should the product be
positioned in marketing and development terms? Instead of a shell, the product
could be positioned as a container/organizer.
The XSoft team built working prototypes of the book containing different
features that would be tested with users. We built additional design prototypes
to explore the evolving visual representations and behaviors of the features
being tested. Working prototypes were updated accordingly.
We initially proposed a two phase evaluation program. First, to perform semi-
structured user trials with representative users, and second to carry out field
trials where specially selected individuals would take the product away and use
it for a period of time. It was anticipated that the semi-structured user trial
would provide information which related directly to the product's functionality,
whereas the field trial would better explore how the product would fit into a
person's existing work pattern, especially with regard to the advantages offered
by a metaphor with multiple containers.
Unfortunately, due to time constraints, only the semi-structured user trials
could be performed. As a result, their scope was broadened to include a 'free
exploration' section where the user was encouraged to 'play' with the product.
In addition, another structured part was introduced so that navigation between
various containers could be better explored. We chose not to conduct the trials
in a usability lab where the moderator and participant are physically separated
from each other, and instead set up a dedicated space at IDEO's studio in San
Francisco. Being 'face to face' with the participant tended to facilitate
observation; especially with regard to being sensitive to gestures,
understanding context of behavior and seeing exactly what they were looking at.
XSoft's marketing group wanted to aim the product at wide range of users,
from prospective users to experts. We therefore recruited people representing
this range. In conjunction with XSoft's marketing group we identified five types
of users: prospectives, novices, intermediates, advanced and experts.
Prospectives were classified as people who had never used a PC but were about to
start. Novices were just learning to use a PC, whereas intermediates were people
who were able to do most of what they wanted. Advanced users considered
themselves competent using the computer and experts were those who were able to
do everything they wanted.
Finding participants was achieved by designing a screener which was then used
by a recruitment consultancy. Using a recruitment consultancy enabled IDEO to
retain control over participants while reducing cost and time. In addition to
the initial screener, a participant profile was developed which was administered
at the beginning of the trial. This further investigated their general computing
experience, explored how they managed their computer work, determined where they
used the computer and for what tasks they used it.
The test protocol was tested by performing a series of pilot trials. This
helped us rectify any ambiguity that may have existed in the questions, allowed
us to approximate how long the trial would last and provided an opportunity to
fine tune the instructions which were given to participants. Performing the
pilot trials enabled us to also include, and occasionally exclude, certain
questions which either needed further exploration or tended to confuse the data
being obtained. We also found that prospective and novice users required a
tutorial on some of the fundamental aspects of computing, how to use a graphical
user interface and how to operate a mouse. It was important to ensure that it
was the product participants were reacting to, rather than to computing.
Findings were presented to the combined IDEO and XSoft teams for discussion
in a succinct report. We generated new iterations of attributes which needed
improvement. In addition, the definition of how the product should be positioned
- shell vs. container - was once again discussed in light of the findings. It
was agreed that the container strategy would be adopted.
Specifically, improvements to the appearance and positioning of page turners,
table of contents, tabs and the book itself were made. Furthermore, changes to
the grouping and positioning of pull down menus were made, as well as to
interface terminology ( e.g., "placements" became "icons" became "items" ).
To our surprise, users' instincts often contradicted our common sense as
designers. In an early design, when a user clicked a tab, it moved to the front
and the others were rearranged accordingly ( see Figure 4a and Figure 4b ).
FIGURE
4a:An Early Design. The "Team" tab is selected. It is in the first
row and contiguous with its pages, therefore no tab row rearrangement is
necessary.
FIGURE
4b:Selecting the Letters tab requires tab row rearrangement to move
it from the second to the first row so that it will be contiguous with its
pages.
Tests showed users were confused by this behavior and found navigation
difficult. In subsequent designs ( see see Figure 5a and Figure 5b ) the
selected tab didn't change its position.
FIGURE
5a.The Final Design. The "Team" tab is selected. It is in the first
row and contiguous with its pages, therefore no tab row rearrangement is
necessary.
FIGURE
5b. In this case, when the Letters tab is selected it retains its
position within the tab cluster. A title bar of matching color reinforces the
fact that its pages are now shown.
Testing validated this implementation; a stable configuration of tabs made
navigation easier. To support this behavior we devised visual and interaction
cues to identify the selected tab ( using the color of the selected tab in a
page title bar and underlining the title on the tab ). We had thought the tabs
themselves would serve as both navigation devices and labels for the current
location in the binder. In the final implementation they became - as in our
physical mock- up - primarily navigation devices. The inclusion of a color tab
title bar on every page proved a more viable identification scheme.
Some elements that were initially functional remained only as visual cues in
the final design. For example, user tests indicated the binder rings and the
cover strongly reinforced the metaphor; they didn't need to be functional
mechanisms in order to serve a useful purpose.
FIGURE
6:The Open Book.
The final design for the TabWorks interface and some of its main features: [
A ] The Menu Bar shows TabWorks' tab-page-item structure. At one point we wanted
to use a "Book" instead of a "File" menu to reflect the container hierarchy (
Book / Tab / Page / Item ). Instead, we decided to follow standard Windows
usage. [ B ] The Tab Cluster includes Contents and Index Tabs - provided by
default - that allow the user to see and access the contents of the Book using
outline and alphabetical views. The user can create, name, arrange and delete
tabs. [ C ] The scrolling Button Strip provides single-click launch buttons for
applications and documents and is available no matter which tab or page is
displayed. The user adds items to it using drag-and-drop and can click-drag the
buttons to rearrange them. [ D ] The Rings Area allows the user to move the
pointer off the single-click buttons in the Button Strip without launching an
item. [ E ] Pages show the tab titles by default and page titles as an option.
The user can add, name and delete Pages. [ F ] The user moves from page to page
using the Page Turning Corners or through menu and keyboard commands. [ G ]
Items are added to Pages using drag-and-drop or from a dialog box. Long
filenames are available to the user as well as custom icons. [ H ] The Holding
Area can be used to store temporary item groupings. [ I ] The Status Bar
displays information about the item currently under the hand cursor.
FIGURE
7:The Book Cover appears while the book is loading, then opens
automatically to the display in Figure 6.
The initial working name for the product, PC Catalog, went through many
revisions. TabWorks was selected late in the development process and was
indicative of the main interaction mechanism in the product.
TabWorks shipped in November of 1993, giving users of Windows 3.1 new ways to
organize applications and documents. Based on product reviews to date, it met a
need in the marketplace. TabWorks was the result of applying an iterative,
user-centered methodology. Collaboration between the XSoft and IDEO teams
ensured design decisions were informed by both technological and human
interaction concerns. Involving users throughout the process allowed continuous
improvement that resulted in an easy to use and useful product.
Introduction
XSoft ( a division of Xerox Corporation specialized in
document management software) approached IDEO ( a product design consultancy )
in December of 1992 to assist in development of PC Catalog, a Windows
application based on a book metaphor. The design brief stated that the product
would use the standard Windows 16-color VGA palette and have a maximum size,
including window title, menu bar and borders, of 640 by 480 pixels. Our task was
to create a design that implemented this metaphor in an elegant, usable and
economical way within the constraints of the delivery platform. In other words:
the design had to be engaging, easy to use and useful, and require as little of
the computer's resources as possible.
A User-Centered Design Process
We approached the problem with a
user-centered, iterative method, similar to those discussed by Gould and Lewis
and by Moggridge [ 1, 4 ]. An interdisciplinary team of IDEO interaction and
human factors designers worked with XSoft's developers and marketers over a
period of nine months. Our goal was to understand the needs of potential end
users and, within the scope of our design brief, create interface mechanisms
that would best serve them.
OBSERVING AND UNDERSTANDING:
In
order to visualize the metaphor, we wanted a better understanding of what
functionality should be provided by the product. We began the process by
informally observing users and reviewing as many products that offered similar
capabilities as our schedule and budget constraints allowed.
GATHERING MATERIAL FOR VISUALIZATIONObserving Users
Our design brief was to "visualize and articulate a book
metaphor as a mechanism to store and organize documents and applications."
However, we prefer to approach design problems from the user's point of view,
which requires an understanding of the user's context. This often has the effect
of widening the problem's scope but helps us design for the environment in which
the final product will exist. Our first step was therefore to observe how users
"store and organize documents and applications," independently of the proposed
metaphor.
The Physical Environment
Informal observations were conducted to gain
insight into what methods and mechanisms were used by naive, intermediate and
advanced users to deal with documents and applications in their computer and
physical environments. Over 20 Macintosh and Windows users were observed at IDEO
and XSoft. Our findings were similar to those noted in other studies [ 2, 3];
people working with numerous documents always made some attempt at containment.
Drawers, piles, binders, folders, boxes, envelopes, rubber bands, clips and
other devices were used to keep groups of documents together. We noted three
main reasons for containment. These were: organization/access, transportation
and safekeeping.
The Computing Environment
In contrast, computer interfaces offered few
containers. We also observed that users often failed to discover or use their
full functionality. Windows 3.1 offers two container strategies: Program Groups
within Program Manager and folders within File Manager. Only advanced users
customized the containers in Program Manager extensively. They also used File
Manager and found little difficulty moving from one to the other, even though
the look and behavior of containers was quite different in each of these
applications. Intermediate users tended to make use of File Manager only,
creating directories and sub-directories represented by folder icons in an
outline-style hierarchy. Naive users did little customization, relying solely on
the Program Manager Groups provided. These users seldom created containers on
their computers, though they did so easily in the real world. All Macintosh
users observed created containers. They constructed flat hierarchies that
quickly filled their desktops with numerous folders and files, or a complex
hierarchy of nested folders requiring significant navigation. We observed that
some Windows and Macintosh users never moved beyond default conditions, relying
on specific applications ( e.g., a word processor ) to find their files wherever
they happened to reside in the system. These observations suggested that users
could benefit from additional container strategies.
Related Products
We also looked at a variety of Windows and Macintosh
products with similar or related functionality. Our goal was not simply to
compare product features but to understand how their intended markets were
related to their chosen metaphors and functionality. Products including Norton
Desktop for Windows, Hewlett Packard's Dashboard and Apple's At Ease and At Ease
for Workgroups were reviewed.
A 3-Ring Binder with Tabs
Insights gained from these comparisons were
useful in determining the extent of functionality for PC Catalog and how
realistic the representation of that functionality should be. We wanted a
distinctive product look that expressed all the available functionality while
leaving sufficient system resources for users to run their applications. Based
on our observations and because it was in keeping with the main goal of PC
Catalog - allow users to organize and access documents and applications - we
arrived at a book metaphor consisting of a three-ring binder with labeled tabs.
This container did appear well suited to the functionality goals stated in our
brief; at a glance, it would be likely to suggest a containment strategy and
what functionality to expect.
VISUALIZING THE METAPHOR
Inspired by the experiences described above we
set out to visualize how the binder metaphor might be expressed on-screen.
During the observations we noted common binder elements easily recognized by
users; these suggested possible implementation styles and functionality for the
computer interface. Figure 2 and Figure 3 depict some early iterations of the
design during these phase.
Using a Physical Mock-Up
We began by using a real binder to explore how
it worked and how we could represent its elements and functions on-screen. We
created different tab and page arrangements using a variety of tab and page
styles. Using this mock-up we were able to try out many possible layouts and
functions more realistically than with paper sketches and much more expediently
than computer simulations would have allowed. We played out functions such as
opening the book cover, selecting a tab to open the book to that section as well
as adding and removing tabs and pages and moving items from one place to
another, while asking ourselves how they could be best translated to the flat
medium of the computer screen - within the constraints stated in our design
brief.
Constructing Software Prototypes
These experiences with the mock-up
helped us to understand elements and behavior for the product's user interface.
We then built design prototypes using Macromedia Director to demonstrate how
these elements - covers, pages, tabs, bookmarks, paper clips, pockets, sticky
notes - would be expressed in a computer interface. Some prototypes were not
interactive, they explored alternative looks for these elements ( e.g., Two rows
of tabs or ten? Horizontal or vertical tabs? Color as a highlighting strategy?
More or less realistic representation of the binder rings? ). In other
prototypes we used animation to simulate specific interaction sequences, such as
clicking on tabs, moving from page to page, adding elements by dragging icons
from other windows into the book or launching applications from a button strip
feature.
DEFINING THE PRODUCT
We used the design prototypes in brainstorm
sessions and presentations with the XSoft development team to identify key
features thought essential to the metaphor and to eliminate un-implementable
functionality. We modified but retained some features. For example,
functionality associated with the binder rings ( clicking on them to add or
delete tabs and pages ) was dropped due to implementation issues. The rings
themselves, however, remained to be tested as identifying elements of the
metaphor.
CONDUCTING USER TRIALS
We performed user trials as early as possible to
identify usability problems, assess early implementations and obtain feedback
from potential users. More extensive user trials were carried out at a later
date by XSoft and Compaq using more advanced versions of the product. Their aim
was to quantitatively compare TabWorks to Program Manager in terms of
performance, preference and user satisfaction. In contrast, our aim was broadly
to find out what characteristics of our design were working well, which features
were easy and intuitive to use, what was difficult to use, what caused confusion
and how people reacted to the concept as whole. Our intent was to obtain
information which could be fed back directly into the design loop, whereas their
goal was to evaluate the product.
Pilot Trials
We developed the test protocol by performing an initial
'walk through' of product functionality. This led to the immediate
identification of potential usability problems. These were recorded and added to
a list of other usability issues provided by the rest of the team. As issues for
investigation arose, tasks were designed to explore them. Finally, questions
were formulated which introduced and then encouraged participants to try the
tasks. It was important to phrase the questions in such a way as to be
completely 'neutral', i.e., that they did not imply a correct methodology or
approach.
Test Protocol
First, participants completed a profile questionnaire and
read the test instructions. Every participant was given an overview of the
products' intended use, was reminded to talk aloud, and told that it was the
product that was being tested, not them. Participants were shown the product and
first impressions were elicited to its overall appearance and functional
elements. They were then encouraged to explore the system as they saw fit. As
they did this, the moderator asked questions about what they were thinking, what
they expected to happen next and what their impressions were. Once subjects
began to exhibit a level of comfort and familiarity with the system they were
encouraged to begin the structured tasks. The structured tasks explored
utilization of the table of contents; opening, using and saving files and
applications; making, moving and deleting new sections and pages in the book;
and navigating between TabWorks and Windows. Finally, everyday operation of the
product was explored in a semi-structured part of the trial where participants
were asked to use the product as they would in their typical work. These tasks
included: naming sections, moving them around, using multiple applications,
grouping related items together, installing new books, and using special
navigation tools and containers such as bookmarks and pockets.
Findings
The trials identified usability issues at three levels:
conceptual, general and detailed. Conceptually, some people tended to become
confused as to whether the product was a shell or a container. This was
especially true for the naive and inexperienced users who would suddenly find
themselves on the 'desktop', having 'lost' TabWorks behind another window that
had opened. On a general level, experienced users expressed concern that they
were working more slowly; they felt they were doing double work with both
TabWorks and File Manager. In addition, users expected more contextual help to
be available than was provided. A number of usability issues were found which
related to general operation, such as page turner size and location, and whether
tabs should move or not when selected. It was possible to identify functional
elements which were difficult to use and whose functionality was not intuitive.
Of particular interest was the functionality of the delete mechanism and the
potential to mistakenly remove a number of items at once.
THE LIMITS OF THE METAPHOR
User testing and rapid prototyping allowed us
to discover where and how to enforce, break and sometimes contradict the
metaphor in ways that enhanced its usefulness and usability. We knew, for
example, that double-clicking a folder icon on the Macintosh opens a window
bearing no resemblance, visually or functionally, to a folder. Users were not
bothered by this. Similarly, we wanted to explore the boundaries of the binder
metaphor representation.
ARTICULATING A METAPHOR
As a result of these design-test-redesign cycles
we chose and defined key elements of the metaphor. The book cover opened to
display three rings binding a set of divider tabs, each containing one or more
pages. Pages contained items - icons representing documents or applications.
Users could create multiple books. Users could name their books, divider tabs
and pages and add or delete tabs, pages and items which could be rearranged in
different ways. An area next to the rings, accessible at all times, kept
frequently used applications or documents handy. Figure 6 and Figure 7 show the
main features of the final user interface.
