Fast forward

XII.1 January + February 2005
Page: 18
Digital Citation

User-centered design in the enterprise

Aaron Marcus

back to top 

For the past two years major corporations have been seeking to establish user-interface design centers of excellence. What seems new is that the concern for establishing such centers is stronger and more central to user-centered design (UCD) competencies than ever before, as corporations discover they must be more customer-centered. This awareness is particularly keen among consumer-oriented product and service development. Alas, at the other end of the spectrum (e.g., with specialized, professional or industrial systems development), there are still many companies or organizations for which UCD seems a relatively unknown, untried, or very new approach that still needs careful nurturing.

We are all aware of basic user-centered design processes and best practices. And we are aware of the wide variety of UCD techniques (many of which are discussed in this magazine). Initially, we think the factors that affect which techniques are used vary among the following:

  • Availability of testing labs and equipment
  • Availability of usability professionals
  • Availability of users
  • Budget
  • Calendar schedule
  • And so on....

Likewise, we believe the effects of user-centered design can be evaluated by criteria such as:

  • Customer satisfaction
  • Improvements over benchmarks
  • Increase of usability awareness in the development team
  • New understanding of users, their tasks, or contexts of user
  • Return on investment (ROI), as measured by metrics established at the beginning
  • Usability of the developed system
  • And so on...

back to top  So Far, So Good—in Theory. Now for Reality.

There are some practical steps to better ensure success of initiatives. Below are some recent examples without naming names.

Major corporations are seeking to establish or improve their own user-centered, user-interface design centers of excellence. UCUIDCE is a mouthful, so let's call them UIDCs or User-Interface Development Centers, and use a more general term, "development," to cover the activities of planning, research, analysis, design, implementation, evaluation, documentation, training, maintenance, and, yes, marketing—that is, marketing new UI technology or development solutions to corporate customers and/or outside business partners.

One major corporation started off well, trying to organize an internal group to be the UIDC, sponsoring kick-off tutorials on the subject, and building up an archive of best-practice documents. Some leaders emerged in this group to lead the internal evangelists across department lines and attempted to bring best practices to as many disparate groups as possible. The internal Web site, used as basis for communication, took many months to get designed and go live. The Web site was a good, small start, but the site itself needed more attention to content, usability, and aesthetics. They are very important, especially for a center of excellence claiming others should come to the UCD for advice or collaboration.

One important factor was the attempt to align UIDC best practices with comprehensive, integrated software-engineering methods, like the Rational Unified Process (RUP) or its competitor processes. While things started off well with great enthusiasm and a Web site to represent the group, activities quieted down seemingly almost to a standstill after several months. Why? Because, in part, individuals had to donate their time to these UIDC endeavors. There was no official, sanctioned budget to which they could ascribe their UIDC tasks. The management seeking to develop these efforts assumed that it could survive as an informal, un-budgeted, volunteer effort of dedicated individuals.

That philosophy, if it did ever flourish in corporate groups, withered away decades ago. Now, in a realm of overworked, understaffed teams, it becomes less and less likely that volunteer, grassroots efforts can take hold and make the desired impact—certainly not without significant seed capital to encourage start-up tasks. So, what is needed? Alas, there must be at least one brave high-level manager willing and able to fund these activities to make sure that some staff are officially assigned to UIDC activities and that there are budgets for meetings, supplies, intranet development and maintenance, etc. This attitude is no different than any other official corporate activity. Eager proponents may find such budgets in training or human resources, which might be re-oriented creatively to UIDC activities. But the funds must be there for group leaders to be able to concentrate enough time and energy to get fundamental activities started until there is momentum enough for independent entities to continue. The seedlings of UCD cannot grow in dry soil.

Within most medium to large corporations there are likely to be sizable numbers of people (15 to 150 or more) working in isolation. While they share similar aspirations, they suffer from lack of officially sanctioned time, information resources, sharing of skill sets, trading expertise, cross-department communication, etc. A UIDC can help encourage the development and publication of best practices; it can also encourage that these best practices be followed. The UIDC also can make better known the local leaders, experts, or help resources. The UIDC also can make available skills and tools of which people are not aware. A simple example of the benefits of sharing experience is when one group does not know but quickly learns at regular, sponsored UIDC group meetings that another group has already researched and procured favorable site licenses for software tools, which can save sizable portions of operating budgets for other teams.

Another major corporation is using the existing human factors group to improve the corporation's overall approach to user-centered design in what will be an effort over a year or two. This is an interesting variant on UCD as the CHI community understands it; allying UCD with another professional group—Human Factors and Ergonomics Society members instead of SIGCHI members.

Actually, there are many such groups within the corporate walls whose members relate to many lines of business and staff-support areas. Technical documentation (whose staff are often members of the Society for Technical Communication) or usability professionals (Usability Professionals Association) are other candidates. Each kind of association has benefits and risks. You will need to explore the right partners for your own corporate culture.

Allying with the software engineering group is a very strong route, because their contributions are deemed essential. The challenge is offering competing processes, definitions, and established leadership to groups that may not wish to have CHI-like entities mixed into the "purer" software engineering cultures, even though CHI professionals could point out where there are certain missing components in user-oriented development processes and documents. A recent CHI 2004 Workshop called "Identifying Gaps between HCI, Software Engineering and Design, and Boundary Objects to Bridge Them" brought CHI and software engineering professionals together to seek better mutual understanding and use of sharable, communal documents at the shared boundaries of the two professions.

The human factors professionals are also established within centralized or distributed groups. They, too, offer personnel, budgets, practices, tools, and a culture to which CHI's UCD philosophy could be attached. However, here, also, there may be differences of opinon about the value of cognitive, psychological, emotional, aesthetic, and other analysis and design priorities. Each group presents challenges to cooperation and collaboration.

An interesting set of further challenges emerged at a third major corporation. UIDC professionals are both analysts and designers. There are significant differences in the use of terms like "design" and "research" among professionals who come from the academic, analytical disciplines who value quantitative results (like cognitive psychology and behavioral studies) and the practical design disciplines who favor more quantitative results (like visual design, interaction design, industrial/product design). How are the practices, tools, budgets, personnel, etc., of a UIDC to be apportioned? There are already strong "cultural" differences within the UCD disciplines that can lead to misunderstandings, hurt feelings, and squabbles over resources and assignments of time. These conflicts, in turn, hurt the effectiveness of the UIDC to be a beacon of light, a helpful resource, and a source of expertise for internal and even external customers seeking its services. Recall that SIGCHI itself in its conferences and publications has gone through this same kind of culture-merging in an effort to be inclusive of all forms of design disciplines that shape the user's computer-based communication and interaction experience.

The third corporation has been able to build a dictionary of canonical terms, to begin refining the concepts and processes, to determine the skills required for each step, to begin to audit the documents that exist, and to build the new documents required for a best-practices archive. Such efforts typically require almost a year of effort to implement.

back to top  UCD and the CHI Community

There are many encouraging signs that make life easier for those seeking to develop improved UIDCs. The European Design Centre has produced a CD-ROM that promotes UCD and includes case studies. It distributes the CD-ROM, showing what it takes to promote UCD within the corporation and to its partners. Further, IBM has made available an outstanding and extensive online document outlining the full UCD process from its perspective. Unfortunately, we have found that this Web site is almost too deep and broad to be used as a practical on-the-job document; it is more like an archival reference document of best practices. All together, many fine resources are available that were not so easily found in the past.

Many UIDCs will require something "short and snappy" to remind their own teams of the basics, to educate prospects and clients, and to serve as a checklist and symbol of their process. The simplified process diagrams and the cyclic emblems of iterative design usually have not even 7±2 steps, but more often 5±2 steps, like the three that are featured in IBM's Software Development Platform that shows the typical circle of Discover, Develop, and Deploy. We have used Discover, Define, Design, and Deliver. Others have similar slogans that help to focus attention of all stakeholders on the key steps in the cycles of refinement.

Bear in mind that all UIDC teams will have to market their approach; not all UIDC groups realize this fact or put the amount of time into marketing that they should. Nevertheless, storyselling efforts pay off in better materials at hand: presentation slides, intranet descriptions, case studies, and paper publications (e.g., an introductory leaflet for face-to-face meetings). Making the case for UCD within the corporation and among key business partners is a never-ending activity. In part of this effort, the Usability Professionals Association (UPA) is undertaking a return-on-investment survey in order to build up information of value to usability and design professionals to back up the claims of benefits of UCD.

In the end, with UCD, things will get better. The obverse is chilling to contemplate. In a recent review of the user interface for a complex mobile communication and emergency-response system purchased by a municipal government for police officers, we learned that user-centered design was not carried out on behalf of these users. After spending several millions of dollars, many users were dissatisfied and some were not using the new system. Those who did found the new system impeded their productivity significantly and might even lead to dangerous, possibly life-threatening situations. A heuristic analysis cited over 30 significant issues, including erroneous map data, hard-to-read important text, and clumsy data input techniques. Here is a dramatic instance of how the lack of UCD in user-interface (and software) development has a significant effect on the success of system development.

Fortunately, this kind of system development is decreasing. CHI professionals involved with establishing or improving UIDCs can breathe a little easier that many new tools, publications, and processes are now becoming more widely known and available to help them in their quest for humane user interfaces.

back to top  References

bullet.gif Publications

Cockton, Gilbert (2004). "Value-Centred HCI" In Hyrskykari, Aulikki, Ed., Proceedings, NordiCHI 2004, 23-27 October 2004, Tampere Finland, pp. 149-160.

European Design Centre (2004). User-Centred Design Works (CD-ROM). Publisher: IOP Human Machine Interaction,

No Author (2004). "Software Development: Best or Bust" (Test of best practices). Software Development Magazine, November 2004, special insert, unpaged.

Schaeffer, Eric (2004). Institutionalization of Usability. Reading: Addison-Wesley.

Vredenburg, Karl, Scott Insensee, and Carol Righi (2002). User-Centered Design: An Integrated Approach, Software Quality Institute Series. Upper Saddle River, NJ: Prentice Hall.

bullet.gif URLs

The following URLs are relevant to this topic:

back to top  Author

Aaron Marcus
Aaron Marcus and Associates, Inc.
1196 Euclid Avenue, Suite 1F
Berkeley, California 94708, USA
Fax: 510-527-1994

back to top 

©2005 ACM  1072-5220/05/0100  $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 © 2005 ACM, Inc.

Post Comment

No Comments Found