HCI and the Design Lifecycle

HCI and the Design Lifecycle

Introduction

Making systems easier to use, so that people can achieve their goals faster, with less mistakes and greater satisfaction, is the aim of HCI, and so it is vital that it is considered throughout the development lifecycle. HCI is more than just designing a pretty interface: it dictates how a system reacts to what, and how information is obtained from and presented to the user. HCI is therefore about interaction as well as interface, and hence cannot be stuck on as a last minute thought. A superb interface may help cover up the cracks in a poor system, but if the underlying interaction is not well thought-out, the system will fail.

There are many models of software development, and many places at which HCI thinking should be specifically applied. The development cycle outline here is neither comprehensive nor unique, but it serves to demonstrate where and when HCI should be applied, and how the system develops from conception to implementation. This software lifecycle will be the one we follow during this semester. Note that this is not supposed to be unique to just this course: HCI should be applied to all software projects, no matter what their aim or complexity.

An HCI-Oriented Design Lifecycle

  1. Obtain user ideas about the proposed system
    Discuss the system with the prospective users/customers. Compare it to an existing one, if there is one, and identify the weaknesses and strengths of the existing system. Detailed questionnaires to targeted prospective users. Task analysis.
  2. Decide general design approach
    May depend on hardware and software to be used, and past conventions, as well as suitability to task in hand. Questions that may have to be considered: WIMP interface or command line? What input/output devices, what hardware, software tools? Interface guidelines?
  3. Initial requirements specification
    User requirements (what the user wants it to do: enter this, display that). May also include initial attempt at architectural design (how the system will provide the services).
  4. Design
    Interaction design and interface design Ð how the system responds to things, how and what information is presented and entered. Ties in to architectural design and detailed design i.e. structure and detail of code modules.
  5. Prototype
    Produce a developmental version to check that designers ideas meet customers requirements, and to try out novel concepts to see if they work, and so on. Prototypes are not necessarily functional, particularly if they are trying out new interface/interaction ideas - they can be mocked up, perhaps first on paper, then on the machine, before ever being attached to pieces of code.
  6. Evaluate
    Prototypes and near-working systems, in alpha or beta release, should be carefully evaluated to see if they meet the clients requirements and are easy, intuitive and sensible to use. It is often the case that prospective users are very different to the actual designers and so find certain things particularly difficult with the current system, and the aim of evaluating the system at this stage is to catch these errors.
  7. Redesign
    The system should be redesigned to correct the problems found earlier Ð this may be minor or may be major, depending on what was discovered.
  8. Reimplement
    The reimplemenation may be to produce the final version, or another prototype for another round of refinement of ideas. It is sometimes the case that many prototypes are tested, until finally the design is agree. For some projects, the prototype is then discarded and the system reimplemented from scratch, often in a different language, with considerations of efficiency and functionality as well as interaction and interface.