our focus is on the design of the UI we will give a brief description of the requirements for the application as a whole before concentrating on the user requirements for the system. We will describe the process used to design the UI and present some of the prototypes and other informal design artifacts developed as part of this process. We will then show how the presentation models were derived from these. We will outline the benefits we obtained from using these models, show how we were able to identify problems within the design using them and describe how we subsequently fixed these problems. We will also discuss problems we encountered when using the models and suggest some possible solutions to these. Finally, we will present some conclusions based on our experiences of designing a UI in this way. This hierarchical view allowed us to start to consider what the different parts of the UI may be (in terms of windows and dialogues) and what sort of actions the users will perform with the UI in order to perform these sub-tasks (e.g. entering text, selecting options, etc.) Each of the initial requirements we presented was expanded into its own task hierarchy and these were then used as the basis to begin the design of the UI. With the information, we had gathered from the previous steps we now had enough information to begin developing paper prototypes for each part of the UI. From the task analysis, we had identified the need for three main parts to the UI: the ‘Main’ navigation window; a ‘View Presentation Model’ window. The prototypes for the ‘Main’ window.

To allow informal UI designs to be considered as part of a formal software design process. However, it is also possible to use the models to test designs for certain desirable properties, such as consistency and responsiveness. Before using the models to check for correctness in respect of the formal description of the system as a whole we, therefore, decided to use them to test for these UI properties. To check for consistency within the UI design we analyzed the behaviors and controls described. Generally, we would consider that the model represents a consistent UI if controls with the same name exhibit the same behavior, and conversely if behaviors that are the same are exhibited by controls with the same name. This suggests a UI where a user knows what common widgets will do because they have seen similarly labeled widgets previously (such as Print, Save, etc.) and are not surprised by their behavior. The final stage of testing using the presentation models involved returning to the system specification to ensure that the behaviors described in the models are correct with respect to the specification. That is, does the UI correctly describe all of the required behaviors and so represent the same system as that given in the formal specification? This is the point at which we are able to integrate our formal and informal processes. We now have models of the designs that can be used in conjunction with the specification of the system.