Stefana Broadbent, Francesco Cara
New Constraints on HCI
E-business and Internet consultancies such as Icon Medialab work under increasing pressure to meet clients’ demand for utmost speed in producing quality digital solutions for their online services. The same clients, however, hire Internet consultants for their talent in providing a creative solution and an effective user experience that will repeatedly bring users back to the site. The challenge faced by the project team is therefore to ensure not only features such as solid architecture, speed of interaction, sound security, and great financial returns, but also an excellent user interface supported by reliable user researchall within ridiculously short periods of time. These constraints are not new and HCI practitioners involved in software design have for decades fought with difficult deadlines. In Web design, however, the situation has reached new peaks of complexity because of the variety of users targeted by Web services and the number of different competencies that must be involved in creating a website (management consultants, information architects, brand strategists, art directors, copywriters, HTML integrators, technical developers, project managers). This means that in a project committed to user-centered design, up to five different process strands (business, strategic, branding, technical, creative) will concurrently have to understand and integrate the results of our user interviews, usability studies, or ethnographic analyses. Moreover, the user research that is required to get a first grasp of the wide-ranging population that is being targeted needs to be increasingly sophisticated to compensate the inevitably small user sample that can be studied.
In the following paragraphs we will describe a new requirements format called Life Stories that we have developed to satisfy these new constraints. Although no new technique is introduced, the format consists of an original combination of approaches and captures three main aspects of user understandingprofile, current practices, and expectations and reactionsand yields its results as a narrative.
Using Life Stories to Design Life Tools
At Icon Medialab we have developed a vision of our mission in designing digital solutions: we design life tools.1 Life tools are the tools used in our everyday life at work or at home. When we design and build a banking or a travel website we consider that we are creating a new social environment where people carry out their daily activities. We are therefore responsible for arriving at a solution that is best adapted to the practices and lives of the target user community.
Behind the notion of tools is user empowerment: the possibility we give users to gain autonomy through traditional channels (administrations, institutions, services), self-development (learning, skill acquisition, and impact on self-perception), enjoyment and pleasure from visualizing and operating in virtual spaces, and participation in new communities.
With this mission in mind you must thoroughly understand not only users’ expectations but their social environments and practices. To create new mediators or environments in which users can coordinate and negotiate successfully their intentions and activities, you must have a level of description of users’ current successful interactions that can drive our design process. This is what we capture in Life Stories.
From Explicit to Implicit Requirements
In traditional software engineering processes, collecting user requirements consists of gathering explicit demands and expectations from the potential users of the solution. This presupposes the ability of users to make their needs explicit and to predict the implications of the solution being designed on their activities. With a few exceptions (e.g. Isaac Asimov, Jules Verne), humans’ ability to envision the future is limited, especially when the context is poor, and as a result future users have conservative expectations. In a recent interview the CEO of a major car manufacturing company mentioned the potential drawbacks of market research on innovative products. He gave as an example the eight-year delay between car manufacturers in the van market segment. The first car maker conducted focus groups and interviews to assess customers’ needs and reactions to a third low, sliding door on the side of the van. The customer sample expressed homogeneously distributed opinions: one-third saw the interest of this feature, one-third had no opinion, and one-third saw no point to it; the manufacturer decided that sliding doors were of no real interest to their market. The second car maker took the opposite path, and its van was the best-selling model in its category for more than 10 years.
During the last 40 years the human factors and HCI disciplines have defined methods for constructing an in-depth understanding of users’ needs by focusing observations and interviews on implicit knowledge and behavior . Ethnographic techniques [6, 7, 9], contextual inquiry , and usability testing all focus on capturing users’ activity rather than their explicit visions. Users’ requirements are thus derived and inferred from current practices and usages. If the first car maker had analyzed how families use their vans, what they transport, and how they park it, rather than simply asking them to evaluate a feature, their findings would have led them to understand the need and opportunity offered by the sliding door.
Combining Field Observations, Interviews, and Usability Tests to Understand Life Practices
Our approach to user requirements combines three techniques for capturing various levels of user behaviors and intentions. Contextual inquiry and field observations allow us to see in detail how users structure and carry out an activity, what kinds of issues they encounter, and what sources of information they rely on to accomplish their tasks. Participatory design techniques, using props and mock-ups, help provide a context for envisioning exercises. Finally, rapid usability tests on existing sites of both competitors and our clients give us data about how users will approach the online domain environment. These tests are not diagnostic and are aimed not at improving the design but at observing how users negotiate their intentions and routines in some representative environment. This approach therefore combines a number of techniques to elicit both observable behaviors and implicit and explicit knowledge.
Combining the techniques results in an interview that generally lasts 2 hours. Interviewing people in their daily context can give a critical insight into their physical and social environment and makes it easier to see how daily activities are carried out.
The interview structure we use is individual and consists of four steps:
- Who is the interviewee (personal history)
In this phase we want to capture the profile of the user, particularly the elements of his background that are significant to the solution we are creating (Internet experience, professional background, education, interests). This profile complements the preliminary data on the user groups (for whom the solution has been designed) generally based on sociodemographic and marketing data by which the users are recruited.
- What are the interviewee’s current practices in the relevant
domain (e.g., banking or planning a vacation)
We want to understand how this user accomplishes the activity we are trying to transfer or improve online. This can be done in a variety of ways, for instance, by observing the person in context, by eliciting storytelling about real events (personal or third party), or by asking the interviewees to describe and demonstrate their activity and their sources of information.
- What does the interviewee expect from new solutions (e.g.,
planning a vacation online)
This envisioning exercise is closer to traditional gathering of requirements. However, we always attempt to create a context, stimulate imagination, or establish analogies in order to elicit visions that are anchored to the person’s life. Participatory design, in which the interviewee and interviewer together build screens and artifacts, is also a way of extracting needs and expectations.
How does the interviewee react to a possible or existing solution (e.g., a prototype or an existing site)
This part is a short usability test, in which users are asked first to discover and then to carry out a task scenario that covers the main activities of the domain (opening an account, checking the balance, creating a standing order).
Any record of current practices (video sequences, photos), tools used (instruments, screen shots, papers, procedures, manuals), reactions to solutions, and recommendations constitutetogether with everything that has been saidthe basic data collected.
Selecting the Sample
A recurring issue in user requirements for the Web is the huge disproportion between the number of future users and the user sample studied during the requirements phases. Our approach is based on the ethnographic concept of the informant. An informant is someone from a culture, group, or community that can explain the practices of the group to an external observer. It is important to underline the difference between the notion of informant and of representative of a community. An informant is knowledgeable of the customs and practices of a group and can explain his or her own actions relative to the practices, institutions, rules, and environment of the group or community. A representative is someone from a community who is there as a token of that community. A representative’s behavior is interpreted as typical of that community and observations on one member are generalized to all members of the group. Informants are chosen for their expertise in the target domain and their strong affiliation to the group, which makes them knowledgeable of the artifacts, conventions, and constraints that regulate a specific domain activity in their environment.
An informant always belongs to a group or community (we all actually belong to many groups) that has been identified as one of the targets of the online service. For each target group we generally interview three to five informants, so we can be more confident that the data collected are general and shared. One of our projects, for instance, was to create a sports portal for active, amateur sportspeople. There were three identified targets: amateur sportspeople who belong to clubs and sports federations, administrators of sports clubs, and coaches of different types of sports. For each group we interviewed four people; for the coaches we interviewed a squash instructor, a karate instructor, and a volleyball and a basketball coach. The squash instructor recounted his teaching practices in three different squash clubs, but far from being a uniquely personal description, all of his explanations constantly included how clubs are organized, the tournament schedules, and how his pedagogical objectives were negotiated with the squash federation.
Developing Life Stories
This combination of techniques produces rich but heterogeneous information that we organize and convey as narratives. In this format, the narratives are much easier to share with the stakeholders of the project than lists of requirements. By organizing events in temporal sequences with strong causal relationships, and a unique viewpoint, narrative structures are powerful means to organize and convey complex individual information. Each interview produces a life story consisting of four chapters: individual profile; environment and practices; dreams and visions; and actions and reactions. Narrative is useful both in collecting data and in rendering it. Interviewees spontaneously use a form of temporal sequential narration, and we encourage them to recount their domain activities as a story. We often ask the interviewee to recount her day, or her week, or how a particular project is carried out. As has been pointed out in cognitive psychology [2, 3, 8], people are good at explaining routines as sequences of events in time and it is natural to unravel habitual behaviors after succeeding events and show tight causal links between them (...when I opened my first account I had just moved from Canada, but in Italy to open an account you have to show your identity card, which I didn’t have, and my passport was at the Canadian embassy in Rome so I had to call someone from the consulate to confirm it ...). When we synthesize the data, narratives allow us to see relationships between existing practices, current limitations, wishes and desires, and evaluations of possible solutions. The event sequences are enriched with the information about the person and her background; observations during the usability test are explained by what has been revealed about the interviewee’s habits and expectations. From the readers’ points of view the narration provides a high level of detail and a strong sense of reality. As a member of a certain community or group the user’s behaviors become understandable and a source of inspiration for design.
From Individual Life Stories to Modeling
When we run 10 or 12 interviews we find ourselves with 10 or 12 separate life stories. It must be clear that our objective is not to design a system that is a collection of functions satisfying every demand and expectation of our interviewees; rather, our objective is to create a unique solution capable of adding value to the experience of all of our profiles. Interface design is truly user centered not when it creates systems that multiply functions to match every individual requirement, but when it creates solutions that are relevant for their users.
Within groups the practices and activities recorded often coincide or have common threads; however, across groups the differences can be much greater. For instance, all the informants belonging to a sports club share a certain number of practices regardless of the sports they perform. Conversely, expectations and practices of club members vary significantly from those of club administrators although both groups belong to the same institutions. A first result of the life stories is therefore to validate whether the grouping of users in categories that seemed significant at the beginning of a project is confirmed by users’ behaviors in their daily practices.
Second, we try to obtain from the narratives the necessary understanding of the objects of information that the various groups manipulate, in order to propose a set of digital objects that are relevant for the users.
Third, we identify the opportunities for new services that will provide the added value to their online usage. The episodes in the life stories reflect opportunities and problems of a given community of practice. This can contribute to validate the list of functions that are being defined for the digital project.
Finally, life stories support the definition of use cases for the system.2 Relative to other scenario based approaches , life stories aim not at serving as functional specifications but at providing an effective framework for reliable user requirements gathering and reporting. Life stories integrate a set of methods for collecting user data and propose a format for unifying their presentation. Specification occurs during the design phase and typically involves other modeling techniques such as use cases that exploit the findings of the requirements phase.
Stefana Broadbent and Francesco Cara
36 Rue de Chateaudun
Paris 75009, France
+ 33 1 55 07 58 26
Business Column Editor
Dray & Associates, Inc.
2007 Kenwood Parkway
Minneapolis, MN 55405, USA
©2000 ACM 1072-5220/00/1100 $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.