Interactions

Authors:

---

  Philosophy of Design

My design approach is to develop systems that are as user-centered as they can be, within the constraints of each project. Ideally this involves:

• Clearly defining user communities and personas
• Interviewing and observing potential users
• Iterating through scenario and use case models
• User conceptual modeling
• Generating and evaluating paper prototypes
• Detailed prototype evaluation with prospective users
• Usability testing of early releases

Unfortunately, in practice, I rarely have the opportunity to conduct each stage as I would like. Lack of resources, scheduling limitations and company cultures all impinge on the "ideal" user-centered approach, resulting in a relatively continuous stream of compromise solutions. To some, this might sound like a betrayal of principles, but in commercial development I do not see many realistic alternatives. I view my role as ensuring that development customers make fully informed decisions in making resources available for user-centered design (UCD). If their expectations are realistic, I am confident I can improve the usability of their product by being involved in the development rather than walking away in protest.

I was surprised to discover a few years ago that my views on improving the usability of software were somewhat controversial in some parts of the HCI community. I believe users would be better served by training software developers in the essentials of user-centered design rather than insisting that UCD be employed only by fully trained experts. This is a purely pragmatic stance. Most software is developed in small teams with little specialization. Many companies will simply not entertain the additional expense of external specialists when they perceive that they are not essential to the process. (That is to say that software can be developed without them.) When companies are persuaded of the need for UCD specialists, the most effective approach is to fit UCD into the existing informal process, rather than imposing a completely new approach with associated learning curves and costs. This is one of the motivations for the informal "user-centered Unified Modeling Language (UML)" process shown in Figure 2.

Another reason for trying to draw developers into UCD is that our current methods of teaching software engineering are deeply flawed when it comes to interactive systems. Software engineering courses focus almost exclusively on the internal aspects of design, with perhaps a token module on HCI. Students start their first real development projects believing that coupling, cohesion, and object-oriented principles are the most important design issues. They are usually somewhat taken aback to discover a completely different system of values is needed for interactive systems. This sense of shock, and the need to convert developers to the new religion of UCD, would be largely obviated if user-centered design were taught as an integral part of software engineering.

  Design Process

The design process I use is shown in Figure 2. The process uses a work flow notation similar to that found in the Rational Unified Process. Activities are shown within the body of the workflow, and their resulting artifacts are shown outside, on the right. In this particular work flow, activities and artifacts additional to those used by most object-oriented developers are shown in bold italic. (Refer to Chapter 9 of Object Modeling and User Interfaced Design [Mark van Harmelen (ed.), Addison-Wesley, 2001] for a detailed development and description of this method.)

Although I believe that developers should be involved in UCD, some activities are best performed by UCD specialists. This is partly because it is easy for developers to delude themselves that they are conducting UCD, when all they are producing is designer-centered design. The other issue is that activities involving direct interaction with users require skills that do not come easily to many who have chosen software development as a career path. Also, because of severe confusion over use cases, they should be developed in conjunction with a specialist in the early stages.

What Figure 2 fails to show is what I think of as the holistic nature of user interface design. One of the greatest failings of object-oriented design methods is that although they take a holistic approach to the architecture of components (that is, that the big architectural picture is developed at an early stage), they generally encourage piecemeal development of the UI. This is particularly true of methods like eXtreme Programming (XP) with its "embrace change" subtext. While I have no argument with minimizing the impact of change, this should not be taken as a free license to make wave upon wave of ad hoc changes to a user interface, especially if the original designs were based on sound user-centered principles. Instead, where UI changes are required, they must be accommodated within the established framework or the design of the framework must be revisited.

  Sample Design Project

Boujou (pronounced "boojoo") is the motion picture industry's first commercial automatic camera tracker. It calculates the position of a camera from image sequences alone and under most circumstances with no additional user intervention. This allows computer-generated images to be integrated with live motion footage much more quickly and accurately than before. The product is the result of a collaboration between the Oxford Metrics Group (OMG), which is well known for its Vicon Motion Capture systems, and Oxford University's Visual Geometry Group. 2d3 was established specifically to undertake the development of the product, which started in 1999. Version 1 was released in 2001 and version 2 is due in the first half of 2002. (Further information is available at www.boujou.com.)

A design goal for boujou was that it should require little user intervention. However, if problems occur, guidance needs to be available, without users having to refer to documentation or a separate help system.

During the initial development of the product, only two of us were on the team. I was responsible for the conceptual and user interface design of boujou. The other team member was a computer vision scientist experienced with the relevant aspects of visual geometry. We started with a design brief provided by the OMG's chief technical officer and were joined by 2d3's chief executive officer, who had extensive experience in product development for the film industry. We started with a competitive analysis of a few related products. I also had the chance to observe and interview a prospective user who had experience with manual camera-tracking products. (Unfortunately, for reasons of confidentiality the rest of the design team was not enthusiastic about involving more users.)

A tree-style hierarchical grouping of artifacts (see Figure 3) was already used in at least one competing product. However, in the approach usually taken at that time, tree controls did not assist users in performing actions. Instead, once an action had been performed, any resulting artifact could be found under the appropriate branch of the tree. The design I proposed for boujou made several changes to the conventional use of the tree control without interfering with its usual operation:

A Michelin Guide metaphor was used to direct users to tasks that need to be performed (refer to the screen shot). A single diamond means "optional," two diamonds mean "typical," and three, "required." In addition, the tasks that should be considered now (as a consequence of the current state of the process) are highlighted with solid red diamonds, whereas diamonds for other tasks are hollow grey.

Tasks can be performed directly by either double-clicking or right-clicking on each heading. Double-clicking can be thought of as the long and scenic route, launching an explanatory dialog that explains the tasks and relevant choices. Right-clicking is the direct route, displaying a simple popup menu.

Artifacts resulting from a task are shown under the appropriate task heading. They have a set of consistent operations that can be performed on them and an associated set of dialogs based on a common design.

The task view design has been a fundamental part of boujou since its early beta releases. Although it has not been formally tested for usability, all user comments have been very positive.

  Author

William Hudson

Principal Consultant
Syntagm Ltd
whudson@syntagm.co.uk
Phone: +44 (1235) 522859

William grew up in western Pennsylvania and became obsessed with computers while still a high school student in the early 1970s. In 1974 he went to the United Kingdom to study for a year and has now lived there for the past 28 years. He has spent much of that time developing not only interactive software, but also real-time systems, embedded firmware, typesetting, optical scanning, communications, smart card, and multimedia applications for a wide variety of employers and customers. During the 1990s he studied human-computer interaction (HCI) at the postgraduate level and received a master of science in computing in 1998. He practices, writes, and teaches software and user interface design with a special focus on user-centered design.

He is a contributor to Addison-Wesley's Object Modeling and User Interface Design and has also provided guidance on user-centered design as part of the Rational Unified Process. In addition, he has a regular column in the SIGCHI Bulletin on the Web and HCI.

  Figures

Figure. William Hudson

Figure 1. User-centered design and related activities.

Figure 2. Informal user-centered UML process

Figure 3. Screen shot of boujou.

  Sidebar: Company Snapshot

Syntagm is essentially two separate consultancies. I have been providing software design and development services through Syntagm since 1985. In the early 1990s my wife moved from being an educational publisher to start a new career as a training consultant, also through Syntagm. This means that we have one set of accounts to maintain and can share many resources. In most other respects, the two sides of the company have little to do with each other. (Ironically, even though we both have our offices at home, we have little contact during the day.)

Because my background is software engineering, I still spend the majority of my time designing and writing user interface software in C++. My other activities include a number of office duties such as accounting, systems management, sales, and marketing. This spread of activities is not ideal—I would like to spend much more time observing users—but my time is largely determined by what skills are in demand. The balance also changes substantially when I am not involved in a major project. (A major project in my terms lasts between two and three years.) Between projects I expect to spend at least a third of my time making sales calls and trying to sell the concepts of user-centered design and usability. It is surprisingly hard work, which probably explains why I would rather be writing software than "cold calling."

How I describe myself can vary according to audience. I find that the term "user-centered design" usually requires further explanation, so I often combine it with "usability specialist."

Most of my work is in close collaboration with customers, but occasionally a project also requires the involvement of other usability professionals. So for example, I might subcontract a large amount of user testing to a third party. Equally, I may be brought into a project by another consultant, especially where user-centered or object-oriented software design is also needed.

  Sidebar: Practitioner's Workbench

Resources

1. Norman, D.A. The Psychology of Everyday Things, Basic Books, 1988.
2. Krug, S. Don't Make Me Think! Que, 2000.
3. Edward Tufte's books

Tools

Scenarios, abstract use cases, pencil and paper prototypes, conceptual models, Microsoft Visual Studio®, Rational Rose® and Adobe Photoshop®.

Favorite quotations

"Concern for man and his fate must always form the chief interest of all technical endeavors." (Einstein)

"Le mieux est l'ennemi du bien." [Perfect is the enemy of good.] (Voltaire)

Sources of inspiration

Those who can communicate complex concepts or events in a clear and engaging style, such as Richard Feynman, the well-known physicist. Dava Sobel's Longitude is an inspiring source of clear writing.

HCI joke

A joke that illustrates the problems that HCI practitioners face in an engineering environment: To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be.

 

©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.