Issue
Article
Vol.28 No.4, October 1996
Article
Issue
Issue |
Article |
Vol.28 No.4, October 1996 |
Article |
Issue |
The initial workshop idea was motivated by apparent lack of published sources that describe in some detail the step or stage of computer application design that produces a design prototype from the results of user works/task analysis. There are ample sources of information that describe user work and task analysis, the role and development of user work scenarios, guidelines for use of windowing system components and widgets in design, interface prototyping methods, and the testing of designs with users. What seems to be lacking in published sources are detailed accounts of how experienced designers use the results of user work/task analysis and other tools and resources to produce prototype GUI designs (i.e., to bridge the gap between analysis and interface design).
In addition to the two organizers, there were twelve participants, among whom there was a wide variety of design experience. Including the organizers, there were three from academia, ten from large software development companies, and one who operates her own consulting firm. The invited participants included the following individuals:
The twelve invited workshop participants each submitted a short paper describing their design activities and techniques, including such items as:
The descriptions were circulated among the participants and each was asked to generate questions and comments for the others to be addressed during the first part of the workshop. Participants were also informed that the organizers planned to publish an edited volume, based on the outcome of the workshop.
As indicated above the first part of the workshop was spent in participants responding to questions put to them by the others. During this process, a list of issues/concerns pertaining to the "bridging" step referred to earlier was generated. As might be expected, a much longer list was generated than could be addressed in the allotted time, so the list was prioritized. On the second day two smaller groups were formed and each was given half the issues to address as thoroughly as possible, given the time constraints. The two groups then reported the results of their deliberations to the entire group. A goal that evolved during the course of the workshop was to provide a set of design heuristics that would apply specifically to the "bridging" step.
Work/task analysis is likely the most central issue for design, because it is the basis for developing a truly user-centered design. Because the focus of the workshop was on how the results of work/task analysis are used in producing an interface design, we discouraged detailed discussion of the analysis methods and asked participants to focus on the ways they use the results in "bridging the gap" during design. As might be expected, the representations of work/task analysis takes different forms for various participants, including such things as a decomposition of work objects and desired states of the world and cards stuck on the walls of an "interface design war room."
Discussion of this issue indicated that some participants think of the work/task analysis and design as reasonably separable processes where an attempt is made to do a relatively complete analysis prior to giving much thought to the organization of the interface and the interaction design. Even a designer might iterate through the analysis and design steps with users, the iteration isn't nearly as "tight" (temporally speaking) as with designers who tend to operate more in a co-design mode with users, working very closely with them, sometimes blurring the distinction between analysis and design. One implication of the relative "tightness" of the iteration loop is the need for a relatively completeness of the work/task analysis prior to beginning the design of the interface.
An important point that came out of the discussion of work/tasks analysis is the need to distinguish between the modeling the way users' work is currently done (either without a support system or with one that is in need of an upgrade, as the case may be) and a model that reflects the way the work will be changed by the introduction of a new support system. Some participants advocated ignoring the former and concentrating completely on the latter because of it's ultimate importance to the design.
Scenarios are examples of actual user tasks or an abstract summary based on actual user information. Their purpose is to verify the fidelity of the interface and system support. In essence, they function as links across the design "gap" to help maintain integrity between user "data" and the design. They are used to verify the goals and the rationale for supporting user tasks. More specifically, they are used to validate each step of design transformation, to help users understand proposals based on new technologies, and to serve as sources of terminology and interface metaphors. A potential limitation on scenarios is that they can be "single-threaded", and so do not point out many alternatives or identify many error situations. Thus, a designer needs to careful to specify those.
While there were some differences among the participants about the definition of a metaphor and the distinction between metaphors and conceptual models, there was agreement that their function is to provide organization and structure to the use of a support system in accomplishing the work it is intended to support. Therefore, a metaphor is needed (1) to the degree that users are relatively naive to the use of computers, (2) where users are naive to the domain being supported, (3) when a new technology is being introduced, (4) when the sequence in performing tasks in the system is not highly constrained, or (5) when there is direct manipulation in the interface. A metaphor can also provide a structure for the interface, thereby supporting consistent design.
There appears to be a continuum on which interfaces differ in how explicit a metaphor is represented or invoked. The most explicit use of metaphor is where work objects are concretely represented in the interface with icons or other graphical objects. Less explicit representation is by the use of labels on buttons or menus and even less explicit representation is when a metaphor might be discussed in a tutorial or other documentation, but not actually represented in the interface.
Sources of metaphors are the work domain of the potential users and brainstorming sessions among users, designers, and developers. Criteria for metaphor selection include: completeness of coverage in the work domain, extensibility where natural coverage was inadequate, degree of pedagogical value, and appropriateness for the particular class of user being addressed.
In some cases, the work supported by an application needs to be performed in a rather structured and sequenced way, whereas in other situations the sequencing is not so important as the results or outcome is most important and the sequencing of the work is secondary. This distinction (which is actually a continuum) seems to be an important one when designing the interface to an application. At the workshop, the terms "object-oriented" and "procedure-oriented" were being used, but "object-oriented" became problematic because of so may different ways in which that term is used. As a result, we settled on "subject-oriented" and "task-oriented", borrowing the terms from Zetie (1995). When there is a requirement for work to be performed in a highly structured manner, there needs to be a structured (task-oriented) interface. Alternatively, when there are many different and varied tasks, the user needs to have a flexible, unstructured (subject-oriented) interface.
Some of the relevant criteria for more or less structure are when there are business rules, management constraints, or legal requirements that impose constraints and structure on the way work is performed or when users are relatively naive to the work to be performed. Some ways of implementing more or less structure in the interface are: impose a structure directly and explicitly in the interface; provide a wizard for task components; provide an apparent structure, but allow experienced users to make "short-cuts"; provide context-sensitive help (dynamic help) linked to task performance; selectively present and hide templates for information input.
Where it is appropriate, a subject-oriented interface implementation allows one to delay detailed modeling of task-oriented information and elicit it from the users later in the design step. This can lead to faster design production and provides flexibility or adaptability for future use of the application.
Subject-oriented interfaces are also appropriate for expert users that want a highly flexible interface that fits their unique work style. Also expert users may devise uses for an application that extend far beyond what the designer had ever intended or designed for. A good example of this is Macromedia Director which was originally designed as a basic slide creation tool for business presentations. Director is now widely used by "experts" for such diverse uses as multimedia game programming, and user interface prototyping. Had the original software been designed to function in a highly sequenced manner, it is unlikely that it would have had such appeal to diverse expert users.
Obviously it is easier to design for a homogenous user population,so most of the discussion centered on issues relevant to designing for a heterogeneous population. Even though there may be different user classes involved in the same application, there need to be ways to accommodate all of them in the same interface. Different levels of detail may be needed for different user classes, but it is often necessary to correlate information access by different user classes, depending on how the different user roles are related to one another.
Different classes of users need some common reference points. Also, users may change roles at different times. In this regard, there is a general need to accommodate learning and transitions (i.e., becoming experts). Often it is helpful to use different metaphors in the interface as away of accommodating users' differing needs for information access or for performing different sub-tasks and operations. A useful approach in general is to design an interface that works well for experts, and then modify and expand it to serve the needs of novices and casual users.
There was consensus among participants that both lo-fi and hi-fi prototypes were useful at different stages of design, and that it is useful to iterate between lo-fi and hi-fi designs. It was agreed that the success of hi-fi prototyping depends very much in the availability of good tools in the hands of knowledgeable designers. Some of the relative merits of the two types of prototypes are as follows:
As indicated earlier, one of the goals of the workshop was to derive a set of heuristics that could be used to guide interface design. Although there wasn't nearly enough time to be as thorough as we desired, a tentative list of heuristics, related to the issues above, was generated:
It should be noted that the heuristics listed above pertain to "what" to do in the "bridging" step and do not directly address "how" to do it. It became obvious at the workshop that "how to" information is best addressed in the context of concrete examples of design projects that differ in the relevant characteristics addressed in the heuristics. Our intention is to address these kinds of issues in a forthcoming book from CRC press, scheduled to be published in the Spring of 1997. Each participant and two experienced designers who were not able to attend the workshop (Carl Zetie and Pat Billingsley) will each author a chapter describing their use of the heuristics within the context of a design project.
Zetie, C. (1995). Practical User Interface Design. New Your: McGraw-Hill
Larry Wood is a professor of cognitive psychology at Brigham Young University, who has taught human-computer interaction and interface design courses for ten years. His research interests include all aspects of user-centered design.
Email: WoodL@byu.edu.
Ron Zeno is partner and user interface analyst at Intuitive Design Engineering, a company specializing in user-centered design. His interests include making the software design process explicit.
Email: RZeno@acm.org
Issue |
Article |
Vol.28 No.4, October 1996 |
Article |
Issue |