User interface modelling (UIM) is basically a method for gathering user requirements that are applicable when designing the user interface to an information system. UIM is to be used as a complement to use case modelling (Jacobson, Christerson, Jonsson & O vergaard, 1992) in the system development process. An actor model, a goal model and a work model are specified during sessions where the end-users cooperate with software engineers and user-interface designers. The actor model is a description of characteristics for each category of users. The goal model is a list of high-level goals the users want to achieve. The work model is a specification of work situations, information objects and actions, and properties of attributes and operations, suitable for the design. UIM does not describe a step-by-step procedure on how to create usable interfaces. Interface design is partially a creative process than cannot be completely described with a method. However, the design process can be facilitated if the design decisions are based on a substantial model defining the users' requirements for the user interface. This model is created during UIM sessions.
The method has been tested in different development projects at the Swedish National Tax Board. It has been shown to provide useful input to the user-interface design process.
1999 Academic Press Floyd (1987) identifies two perspectives on software engineering. A product-oriented perspective regards software as a product standing on its own and assumes that all requirements on the software can be determined in advance. A process-oriented view is more concerned about the humans working with the software, and the continuously changing process in which they are involved. Floyd argues that it is important to move the focus in software engineering from a product-oriented towards a process-oriented view.
A method focusing on the users covering the whole process from requirements gathering to systems design is Contextual design (Beyer & Holtzblatt, 1998). Here, knowledge about the users and their work is gained by querying the users while they perform their work. This gives a deep insight into their current work situation, the tools they use, etc. The result of this analysis is specified in five different models that are used for redesigning the users' work situation. Storyboard techniques help to create visions of the new system and a User Environment Design shows the structure of the work to be supported by the system. Contextual design is especially useful for redesigning the users' work. The User Environment Design includes some important information but it does not give enough support for designing the user interface.
Another method that covers the whole process of software design is the LUCID methodology (e.g. Schneiderman, 1998). A framework is presented upon which different methods can be hung. It consists of six stages. The importance of developing a product concept and creating a key screen design is emphasized. LUCID presents a brief description of what should be done in each stage and in which order, to ensure usability. However, it does not supply the user of the method with enough information on how to actually collect or document the results in each stage.
Several methods for task analysis (TA) have been developed to assure that human-computer aspects are introduced in the design process. TA is generally concerned with what people do to get things done (Preece, Rogers, Sharp, Benyon, Holland & Carey, 1994). Most methods for TA include decomposition of tasks into subtasks and a sequential description of how they are performed. Salvador and Scholtz (1996) present one such approach called systematic creativity. A user-oriented framework where the user goals and user tasks are related to product goals and product tasks is introduced. Tasks (and sub-tasks) are also represented as object-action pairs. One problem with methods for TA is that the descriptions of the tasks are too fine-grained (Gulliksen, Lif, Lind, Nygren & Sandblad, 1997). When designing the interface a description of bigger concatenated tasks is more useful. Benyon (1992) claims that TA is not capable of being independent of the device that is used when carrying out the tasks. It is therefore a great risk that current practices will be embodied in the new system. He argues that human-computer interaction (HCI) should contribute to systems design with modelling tools to complement existing methods and tools of systems analysis, instead of ''inventing wheels which have already been painfully discovered by others'' (p. 119). Sutcliff and Wang (1991) believe that ''one reason for the poor spread of HCI principals and practice is the lack of integration between HCI research and practice with methods in software engineering' ' (p. 132).
In this paper, a method for gathering requirements for the interface is presented. Our intention is not to introduce a whole new method for systems development. Instead we have focused on a small but important part, namely how to collect aspects of the users 244 M. LIF