oo+hci site under construction
introduction 'Object-Oriented Modeling and User Interface Design: Designing Interactive Systems' object modeling with UML HCI fundamentals and background methods for interactive system design some useful design techniques a discussion form to be implemeted soon you are here need help?

Oohci Methods: Introduction

Designing highly usable interactive systems

The methodological approaches adopted by this site include

  • cognitive engineering
  • user centered design
  • model-based design
  • appropriate use of UML and non-UML notations
  • participatory design and
  • paper prototyping, prototype testing using formative evaluation techniques

Many of these approaches will be found to be described as part of the HCI background

While these approaches are encouraged, not all are adopted by the range of existing oohci methods. In order to be considered an oohci method, a method must (probably) incorporate at least the first four of the above approaches.

Activities A-G below provide a characterisation of oohci methods that incorporate all six of the methodological approaches listed above.

  1. have early contact with users and other relevant stakeholders
  2. discover the users' conceptual model - a model of how users view referents (application objects) and tasks (user activities) in the application area
  3. the users conceptual model is used as the basis for the system by selecting objects and tasks from the conceptual model for implementation in the system
  4. design the first version of the system's user interface (GUI)
  5. perform rapid prototyping using cheap and easy-to-construct prototypes that are made from paper and other low-tech materials
  6. test and modify these prototypes with users to improve and validate the conceptual model and the user interface design
  7. deliver a UML-expressed object model, accompanying use cases, and the corresponding validated user interface design to any remaining OOA activities and to later OOD activities.

To some extent this is also a method framework, and design techniques that are potential candidates to populate the framework to create individual methods will be mentioned here and described on the design techniques page

In considering methods for interactive system design, no one method can prescriptively determine how a the up-front design of a system should proceed. Each project will have different kinds of resources, different designer skill sets, different levels of user participation, different management support for different kinds of work, and so on.

As a result of this oohci methods may need to be invented or changed to fit particular project circumstances.

Activities A-G are discussed below in the light of a participatory design approach where

  • users
  • analysts and developers
  • managers and business sponsors, and
  • a facilitator
co-design the application. Some of the particular methods discussed by this site (here) may not subscribe to this participatory approach, but participatory design and its accompanying technique of formative evaluation (see F) lie at the heart of oohci methods. This is because they are very effective techniques in the designing of highly usable interactive systems.

A. Have early contact with users and other relevant stakeholders

Analysts and designers must meet users and observe them in their work place. This contact is absolutely necessary in order to implement usable systems, regardless of if a participatory design approach is used in the design process.

B. Discover the users' conceptual model

In a participatory design approach users, developers and other stakeholders build a shared understanding of the application. They do this by identifying user tasks and identifying the referents (the objects that the users use).

The tasks may be restructured, thus redefining how work is done. A task model might be expressed with cards and arrows for users. Developers might perhaps use a more formal notation such as a hierarchical task model or a set of use cases.

Referents are gathered and represented within an object model. This content model might be expressed on cards for users, each card representing a kind of referent.

Ultimately analysts and developers would render the content model using a UML class diagram. UML diagramming tools can be used for this, but a whiteboard or flipchart are suitable for initial drafts of the model.

C. Use the users' conceptual model as the basis for the system

The conceptual model is refined for use as the system analysis model. Once an appropriate division of tasks between users and the system has been made, the referents from the content model are used or maintained by the system are selected for inclusion in the UML analysis model. This activity can be done in a participatory way through card-based media, with the UML-skilled rendering the participatory card-based UML model for their own use. The tasks can be rendered as use cases if they have been expressed in some other notation.

In a participatory approach B and C will have proceeded in a somewhat organic interleaved iterative fashion that hones down on the models described here in C. The models be rendered in the same styles as shown above under B.

The resultant models (content and user task models) can be tested by users referring to the models as they discuss how tasks are performed. As inaccuracies and inefficiencies are discovered they can be rectified in the models. (This is formative evaluation, see F.)

D. Design the first version of the system's user interface

The system structure and high-level behaviour model from C is used to design a user interface to the interactive system. The user interface must provide suitable controls and satisfy the data needs in order for users to perform their tasks.

This is model-based user interface development, where the user interface is derived from the models designed in G. However, changes in the interface as a result of E and F may result in changes being propagated back to the models.

This web site needs information on the relatively easy transformation of models to a user interfaces.

E. Perform rapid prototyping using cheap and easy-to-construct prototypes

Paper and other office and art materials can be used to construct prototypes of the system. This is rapid, cheap, and effective.

The use of paper and other low fidelity prototyping materials encourages users who later test and improve the prototypes to concentrate on the content and use of the system, rather than get hung up on less important presentation details such as "should the buttons look 2-D or 3-D?"

F. Test and modify the prototypes with users

The prototypes are tested by users, with the developers neutrally operating the prototypes and watching for problems in their use. As problems are discovered by users and developers the problems can be rectified by cooperative redesign of the problematic parts of the interface. The discovery of problems, redesign and subsequent retesting takes place in one smooth iterative process.

This is called formative evaluation. In formative evaluation the process of evaluation and discovery of problems is used to form the solutions to those problems in evaluation and redesign sessions.

G. Deliver an interactive system design

Deliver a UML-expressed object model, accompanying use cases, and the corresponding validated user interface design to any remaining OOA activities and to later OOD activities.

Usability of the design is relative well assured, because the significant conceptual level models and the prototyped interactive system have been tested and iteratively improved until the stakeholders are satisfied with the design.