While reading the design briefs in this issue, I was struck by both the differences and the commonalities of design approaches. Given the limited space, the articles only hint at why the differences exist are they due to differences in markets or customer profiles? Corporate culture? The designer's background? The designer's personality? We can learn a lot about how design is and can be done by exploring the choices various groups made.
Some briefs focus on how and how much user information is gathered; others suggest they learn about users more indirectly (e.g., from marketing reports, team introspection). In some cases user research precedes the actual design stage, in others design and user research are parallel activities, and still other groups get most of their user data from usability tests at the end of the development process. Are these differences due to the maturity of the various UI organizations, to differences in the product space each group is in, or something else?
I found one variation particularly interesting: Some designers consider themselves and their team members as stand-ins for users; others don't. Nanci Martin explicitly states "I am not my user" (who is a 13 year old girl), while the Microsoft team has the goal of experiencing the product as users ("dogfooding"). There's a real danger in believing you are your user when your user is significantly different from the team members. Finding the right balance is the challenge. Perhaps PlanetGirl.com should include teen-age girls on their design team (I'm sure Allison Druin would concur). Perhaps Microsoft should take care to distinguish the usability input of team members from the input of "real" users.
Some of the design processes appear to be are focusing on getting the design right the first time or at least before implementation. Others emphasize iteration, both in the design stage and between design and implementation. A third subgroup relies on usability testing as a critical way of getting design feedback and going from a rough design to one with details that match users' skills and expectations.
In my experience, human beings are too complex for us to expect our designs to work without substantial user feedback, particularly from users doing real tasks. I'm sure that in practice all these groups gather some form of user feedback; what differs is that some of them consider user feedback to be an explicit part of their design process, while others do not. The design process will be significantly different if iteration and user feedback are seen as fundamental parts of design, rather than steps that come later.
I was struck by WebTV's ability to do a usability test every week. That has the potential to provide a really tight iteration loop. I've worked on products that would certainly have benefited from both the quantity and immediacy of user feedback that such a usability schedule provides. WebTV's commitment to this approach suggests a team that really values user feedback and that is willing to invest the considerable effort needed by the usability team and by the design and implementation team to make it work.
Groups also varied in the value they placed on consistency, especially as provided by guidelines and standards. Some groups referred to the guidelines that structure and constrain their design decisions; others discussed the value of consistency, but didn't explicitly mention guidelines. And a few briefs talked about the constraining nature of guidelines, and how they stifle innovation. Yet even Steve Hartford of Play, who took the latter position most strongly, mentions that they extended their novel interface concepts to other parts of the product (e.g., the packaging), providing consistency within the product, if not with other products. The value of consistency to users is well established; but as a few contributors remind us, misplaced consistency can be as bad as no consistency. The debate over what "good consistency" is and how best to achieve it will be with us for some time.
Prototyping is used as part of the design process by almost all the groups included here, but the timing, type, and goals of prototyping varied. Everyone seems to use sketches as their first manifestation of a candidate design, and many go on to use more elaborate prototyping tools. (The prototyping tools mentioned were primarily static no one described using tools like Visual Basic, that can implement behavior as well as appearance.) Some groups appear to use prototyping primarily to communicate design ideas and details to the implementers; others use it as a vehicle for getting early feedback from users (and some do both).
User interface specifications were mentioned by a number of groups, while others appear not to use formal documents to communicate user interface decisions. (The Xerox UER group goes further than most and documents design rationale as well as decisions.) This appears to be influenced by the size of the organization and the length of time projects last. If the number of people needing information about the UI is small and the amount of time between decision-making and implementation is short, then specification documents may not be cost effective, or at least will be perceived as being more cumbersome than just walking into the relevant person's office. However, as the organization grows, the need for a more lasting repository of information about the design emerges. How organizations change from small informal teams to larger groups with more structure is always an interesting issue. Can it emerge naturally as a consequence of growth, or are these lessons invariably learned with a lot of pain?
An ongoing tension exists between having all the UI people together, where they can benefit from contact with each other, and having individuals tightly integrated with the engineering teams they are currently working with. Many groups use a hybrid approach: Individuals are organizationally in a common UI group, but are physically located with the current project team. Groups that serve more of a consulting role tend to exist solely as a group, because their work with individual projects is too short to make it worth "bonding" with each new team; groups with project involvement spanning months or years find that co-location with the team is crucial to being perceived as a fully-valued contributor.
Most of the briefs describe a design process that is distinct from the implementation process, but in a few groups the designers are also the implementers. The Liberate team discusses the advantages of this approach it minimizes the opportunities for design ideas to be miscommunicated. However, design and implementation are quite different skills and to some extent require different temperaments; hence, it's hard to find individuals who do both well. Alan Cooper, in The Inmates are Running the Asylum, talks about the dangers of trying to do design with the mindset of an implementer the demands of programming interfere with the ability to keep the user in the forefront at all times. Do similar dangers exist in trying to do implementation with the mindset of a designer?
One thing missing from almost all the briefs was an explanation of how user experience fits into their business how UI work contributes to the bottom line. The Corel brief mentions that product teams know from experience that products developed without input from the UI group don't do well in the marketplace, and Steve Hartford of Play has a wonderfully relevant quote "Great artists ship" but I didn't find other mentions of the place of user experience in companies' core businesses.
Nanci Martin's interview is the best example of a discussion that tightly blends design and business concerns she talks about business implications in almost every paragraph, as one would expect from someone at her level. If we as designers are to be as fundamental to our companies' success as marketing and engineering currently are, we have to be so knowledgeable and impassioned about our impact on the business that it creeps in to everything we say and write, as it does for Martin.
The diversity in how organizations do design is evidence of both the health of our field and the range of products covered by the companies included in this issue. If you take only one thing from this issue, it should be the opportunity to compare where your group sits on these and other dimensions. Ask whether your organization's choice is conscious, based on its unique characteristics, or whether it might be time to consider alternative approaches.
Sun Microsystems User Experience Office
©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.