Previous | Table of Contents | Next |
4.6. RANTZER (CHAPTER 7)
Rantzers design methodology is called the Delta method, which expands the concept of user interface to include not only functions provided by the system and the graphical presentation, but also the enabling information (i.e., user documentation). It thus raises usability requirements to the same status as the technical and functional requirements.
Rantzer discusses the Delta method in the context of the development of a next-generation telecom simulation system used for installing and testing of switched and cellular communication equipment. On the requirements side of the gap, the Delta method begins with a system definition where the goal is to set the scope of the project and to gather some preliminary customer requirements. The next phase consists of gathering user profiles and generating descriptions of user work tasks and the work environment. This also includes creating user scenarios describing at a high level the work that will be performed (including new tasks) with a new system in place.
In the Delta method, the bridging process begins with a conceptual design produced by the design team in a design room through activities such as structure workshops, contextual walkthroughs, and construction of activity graphs (user scenarios) and user environment diagrams. This is done in an interactive, iterative manner, progressing from one to the other. Because user environment diagrams reflect the work at a high level, they become the basis for creating low-fidelity prototypes through rough sketches of the layout of potential screens and the flow among them. During this process, appropriate metaphors are also chosen, which play an important role in the final design. As the low-fidelity prototypes are developed and evaluated with users, high-fidelity prototypes are then developed, embodying specific visual design details and navigational issues.
4.7. ROHLFS (CHAPTER 8)
Rohlfs describes methods which she has developed for redesigning complex legacy systems. She defines the typical legacy system as a transaction-oriented, mainframe-based system used for administrative and/or customer service support. Examples are systems for financial/insurance portfolio management and for management of supply, warehousing, and distribution of retail products. Her techniques are described in the context of a hypothetical system to support a large company that offers a wide range of financial and insurance services, with branch offices and mobile sales representatives.
Rohlfs distinguishes between approaches appropriate to fire-prevention vs. firefighting situations. Work done on firefighting assignments is aimed at quickly addressing the most glaring usability problems within the confines of project schedule, resources, and budget. On the other hand, work done on fire-prevention assignments allows extra time and effort to ensure higher quality information for decision making and more exploration of alternatives, which in turn leads to a higher level of quality in the final GUI design.
Because the context of the work is redesign, it is particularly important to specify the new user tasks by carefully considering the current tasks along with a malfunction analysis of those tasks. Rohlfs places a heavy emphasis on the development of an appropriate metaphor and claims it is the most challenging, far-reaching, but enjoyable part of a project. Another important issue is the decision regarding whether a system should provide a task-oriented dialogue or if it should be more object-oriented (as proposed by Dayton, Kramer, and McFarland, Chapter 2). Rohlfs acknowledges that generally novice users prefer a task-oriented dialogue, whereas more experienced users prefer an objected-oriented one. However, she maintains that the type of work supported in a redesigned legacy system is by nature more task than object-oriented.
When it comes to the translating the user information (including the choice of a metaphor) to the actual GUI design, Rohlfs proposes a horizontal-first, vertical-second approach. Horizontal-first refers to such decisions as major windows, their relationship to each other, and placement of tasks in a foreground/background relationship. Such decisions are based on information regarding frequency of task performance as well as the information about user classes, objects, and functions. This stage is intended to ensure that all tasks and user classes are considered from the perspective of high-level navigation so that users are able to find and initiate key tasks. Vertical-second design means that after high-level navigational concerns are addressed, then the design to support each individual task is worked out using storyboards and scenarios, with the entire design being refined by iteration.
Previous | Table of Contents | Next |