Xerox PARC is a research lab located in the foothills of Palo Alto, Silicon Valley, CA. During the past 20 years, PARC has been involved in many of the seminal ideas now commonplace in the CHI vocabulary. These include the popularization of the WIMP style interface (windows, icons, mouse, pointing) and more recent work on 3-D visualization.
UER is a small team of six researchers who have worked in product development, technology transfer, idea exploration, and research settings. Each team member has a substantially different background and perspective. We have worked on a wide range of projects than span ranges of technology and levels of product-ness. In 1998 the UER team worked on the e-Case initial product design (discussed in Eliot Tarlin's Uppercase article in this issue), helping to understand the marketplace, as well as doing infrastructure design and initial UI concepts and testing. We helped in the transition to Tarlin's team and then returned to PARC to begin a round of very fast prototyping of Madcap, an advanced multistream/multigenre media browser.
Xerox is a very large company with many HCI practitioners. PARC is also a good-sized group, with different HCI practices. Here I discuss the working style of UER and what we've learned in the course of our practice over the past five years.
The UER team is multidisciplinary, with people who do field studies, systems builders, visual designers, and interaction designers as important parts of the mix. To us, design is the crucial component of user experienceit is the expression of interactions between conceptual model, technology, and user intent. Our focus has been on the design of experience, rather than on "user interfaces" per se. Consequently, all aspects of a product or research prototype are considered fair game for careful design. We have learned that the best technology in the world is utterly useless if you cannot get it out of the box. Each system has a thousand ways to fail and a tiny number of ways to succeed.
Thus, our design philosophy can be best described as user/task/hope-centered: If the user has a task, or even a hope of using our system, then we need to create the entire system from beginning to end. The boundaries of design are not discipline limited but are defined by what you need to do to let the user succeed. If that means dealing with packaging design, then do that; if it means ensuring that the system supports real-time fast-cycle-time response, then do that.
The UER design process has evolved over the past several years from rough-and-ready to a more organized practice. In its current form, the design process has several components. These are not all gates or documents to create but have become fairly standard parts of the design cycle:
1. Understand the problem. In a research setting, this usually means identifying the goals and initial problems to be addressed. This is the usual early project phase kind of work: brainstorming, identifying trade-offs, etc. This work phase leads directly to the writing of...the design brief.
2. The design brief. For UER, writing the design brief is a coordination act; it is a way of being very clear about what it is we are trying to accomplish. The brief specifies what problem is being solved, what approaches we are considering, what resources we will need, what competition there is, what advantage/good ideas we think we have, and what the final delivery (discussed later here) will be. Of course, the design brief is an object to focus on while you are thinking through the early parts of a project. After it is written, time and events always change. To track these kinds of shifts in plan and goals, the brief is kept more or less up-to-date, and is coordinated with the...schedule.
3. Schedule. Less of a PERTchart than a road map, the schedule is a timeline of major events and dependencies that helps orient the team with current status and future plans. It is usually an appendix to the brief and is always kept in a public place for ongoing access, consultations, and as a focus for discussions about the course of the project. (For postmortem's sake, we keep around the major revisions of the schedule. It is always enlightening to go over them after the fact.)
4. Field studies. Throughout the entire project, field studies crucially inform the team about what ground truth reality is/should be/could be. As we work on the design brief, early pilot studies validate the area of interest: Does the project address real concerns or issues? (Or are the great ideas mostly fiction?) Later, as the work is being designed and built, field studies inform the process by identifying potential users and markets and learning what design ideas will work when actually deployed.
5. Critiques (Crits). We have adopted the tradition of design crits from the art school and industrial design worlds. As the schedule is developed, crits are important milestones designating essential points along the way. In a crit, a field study is proposed, a user interface design is reviewed, or system architecture is reviewed, with team members commenting on the design presented and pointing out problems and good ideas along the way. The crit is also a time to evaluate the larger project goals, checking if everything is still on track.
6. Reviews. For UER, a review is a more formal process that involves stakeholders in the design/research process. While crits are fairly frequent (one per week) and lightweight, a review looks for validation and course correction from people outside the immediate team.
7. Iterate. Our working style relies on a fairly tight group focus on a single project. (In earlier versions of our group, having several larger projects mostly just defocused the work, to ill effect.) Within that focus, cycling between field studies, design sketches, implementations, and crits is essential. That is part of the function of weekly crits: Such meetings focus and propel the work and ensure rapid iteration.
8. Weekly meetings. The first UER meeting of the week is as early as possible on Monday morning. Why? To set the agenda and begin the work of the week as quickly as possible. Crits and reviews tend to be held on Thursdays and Fridays, leaving the first part of the week for the inevitable rush and work toward presentation.
9. Delivery. From the beginning of the design brief, we plan for delivery: What is the goal and how will we recognize it? (A CHI 2000 paper? A working prototype? A design specification?)
10. Postmortem. Of first class importance is the UER postmortem. It is a chance to step back out of the fray and take a look at what has happened. We review the project from the schedule, from our individual perspectives, pausing to derive tangible, articulate lessons about what worked, what didn't, and what we'll change the next time around. Although considered unbearably Californian by some, we have found postmortems to be immensely useful in becoming clear and conscious about aspects of doing a project that are often left unsaid and hidden. Postmortems frequently set us up for the next project, giving new incentive and spark to doing things better next time out.
And now, the reality is that in an ideal world each of the 10 parts of the process would be completed according to schedule. As you quickly discover, the realities of production schedules and political circumstances make the ideal unlikely. Nevertheless, these are the steps UER follows, although some may be abbreviated or run in parallel as constraints require. Field studies, for example, almost always seem to be at the behest of forces outside of scheduled control. Locating field sites and scheduling subjects always takes more time and effort than it should. And from the prototyping perspective, it is sometimes hard to know when to switch between building and testing to rewriting the project definition.
UER is fortunate to have had an intact identity for more than five years. A core team of people has survived together, evolving a working style that relies on close cooperation and communication across traditional disciplinary boundaries. It's a style that is somewhat difficult to create but has been rewarding in giving UER a richer, more robust way of dealing with research topics.
Madcap is an advanced multistream/multigenre media browser that UER had to invent, prototype, and test on a very aggressive three-month schedule to meet a hard deadline. Madcap is intended to allow simple, effective browsing of talks that are captured through multiple streams of media (such as two synchronized video + audio streams, time synched text, slide images, and feature points during the video). The biggest issues were to (a) create a novel, usable approach for browsing multiple synchronized media streams and to (b) create the tools and methods that could quickly turn raw data (the videos, etc.) into finished materials for the browser. The design problem was not just devising the browser, but also creating the production methods that could transform collected data into a single, browsable dataset in a very short time. (Our initial design goal was that a Madcap mediaset would be browsable within 4 hours after the live presentation.)
We conducted the project following the pattern outlined previously. We wrote the design brief and spent a great deal of time brainstorming ideas and approaches while conducting the pilot fieldwork. The majority of time was spent in design and testing a variety of technical issues to make sure the approaches we brainstormed would actually work with really large amounts of data (e.g., several gigabytes per captured presentation).
Madcap was a project of UER, so all six members of the team worked actively on the project. To solve several hard technical problems in video analysis, we worked closely with a research team of four people, headed by Lynn Wilcox, at the Fuji Xerox Palo Alto labs, just down the road from PARC.
Madcap was somewhat unusual in its short time periodthree months is an unusually short project in our research career, but not wildly out-of-bounds in our production career. It was somewhat atypical in its early sharp goal definitionit is far more common for UER to spend more time on project definition, trying to understand what is really needed by the intended user population.
As we work together over the years, we have tended to accumulate favorite design approaches to common problems. For instance, Madcap makes use of an object rollover pop-up mechanism (that is, as the mouse rolls over an object in the browser, such as a slide image, and an elegant pop-up gives more information about that object). That was an invention we created for our work on the eCase product (again, see Eliot Tarlin's article in this issue) and that we reused in this situation. Every group tends to create a legacy of prior solutions that work well. The trick to innovative design is often knowing when to reapply or recast earlier solutions and knowing when to drop them from your repertory.
There was a good bit of brainstorming and exploration of possible solutions on this project. The tradeoffs were both in user interface space (e.g., what stream browsers should the user see, how to portray them visually, what the interactions would be between them) and in technical space (e.g., how to actually sync four or five different media streams with slightly varying time bases). So our sense was that we had a limited amount of time (two months) to explore before having to resolve many technical problems that were prerequisite to any solution.
UER is pretty conscientious about articulating why design decisions are made. (This may be because two of us have extensive backgrounds in capturing design rationales! Or it may be a consequence of our being a multi-disciplined group, with members who demand explanations from each other.) Even so, many decisions are driven by time constraints, and we simply had to make a design decision in order to progress. In UER, two of us also take fairly extensive notes, so we were able (at the end of the project) to reconstruct what happened along the way and why particular choices were made. Madcap was documented using the standard methodswriting JavaDoc pages, writing up project summary reports, and creating a talk about Madcap that we presented to our research community.
Daniel M. Russell
Manager, User Experience Research
Xerox Palo Alto Research Center
The members of UER are "Members of the Research Staff" (MRS) at PARC, in the User Experience Research group.
Typically, a PARC MRS has a Ph.D. or master's degree in computer science. However, PARC hires on the basis of real skill sets, and while an advanced degree is not a prerequisite, advanced skills usually are.
Number Employed in Design and Usability
Although UER has had as many as 12 people at once, a more typical size is between 5 and 7. We have enjoyed a mix of very skilled individuals, with visual and interaction designers, system builders, and field study specialists.
Bearing in mind that we work in a research environment, not a production setting (usually), salaries range from $75K to $120K, depending on skill sets, experience, and role on the team.
In our daily work, UER uses several different kinds of tools for different purposes.
Video equipment is critical for fieldwork (e.g., in situ interviews or capturing the layout of a workspace). We have been using Hi8, but would like to move to DV as soon as possible, as the limiting factors have been portability and ease of video analysis.
Transcribers were of particular value in the Madcap project, but are frequently of enormous help in field studies. (Tip: find a transcriber who does really good work, and then cultivate the relationship. Court reporters, for example, can create 0.5-second accurate real-time transcriptions of video and give it to you in an electronic form useful for immediate analysis.)
Adobe Illustrator, Adobe Premiere, Adobe Photoshop are used constantly. Once you get the basic skills down, sketching ideas in these tools becomes almost second nature. (Tip: you have to keep practicing these skills: Don't think you can do it once and then pick the skills back up in a year.)
Java has been a boon for prototyping, especially now with Java 2D and the entire general improvement in UI components. It's not really write-once run anywhere, but we find it is a much faster prototyping environment for us. (We happen to use Metrowerk's CodeWarrior for its very nice cross-platform, cross-language capabilities.)
Xerox DocuShare is a lightweight Web-based document-sharing repository. It's like having a common file space with reasonable search tools, modifiable user interface and structuring facilities. DocuShare is reasonably low cost and very handy for sharing intermediate results or workpieces in progress with other people in the organization.
©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.