Ch.6: Requirements Gathering, Storyboarding and Prototyping Human-Computer Interaction

6.4 Requirements Gathering (RG) RG is the phase in which we find out what the proposed system needs to do. This involves gathering info. by probing potential users and the environment in which the system will be used. Ex: combination of interview with mgmt, workplace observation, user surveys and analysis of existing manual system. The product of this (the requirement stmt) will be info. about the nature of the task, the intended user group and the intended circumstances of use.

6.4 Requirements Gathering (RG) During this phase we are not concerned: With how a future system will support the task, or With what the system will look like. We are simply gaining a deeper understanding of the target that we are aiming for when we come to consider design options. Waterfall vs. UCSD Waterfall model: requirements are agreed and signed off by the project sponsor UCSD: views the above as being problematic. (WM): It assumes, for instance, that an accurate specification of requirements can be finalized at the start of a prj. When the requirements are already signed off, this knowledge cannot be refined or developed.

6.4 Requirements Gathering (RG) The purpose of RG is to describe what the proposed system should do, but not how it should do it or what it should look like. The output from this activity is the requirements stmt, which is divided into ‘functional’ and ‘usability’ requirements. For each req’t, you specify: What it is What its justification is (where it came from) And if possible, a metric that shows how the system can be measured against the req’t.

6.4 Requirements Gathering (RG) A ‘metric’ is simply a way of measuring the req’ts. Metrics can be: direct or indirect, quantitative or qualitative. For ex: Weighing a physical object such as a brick is a direct metric. Measuring the volume and density and subsequently calculating the mass is an indirect metric. Most HCI metrics are indirect. They can be quantitative (for ex, response time, key presses, number of errors) They can be qualitative (for ex, user satisfaction or user enjoyment). None measures usability directly.

6.4 Requirements Gathering (RG) Requirement Example: Requirement: the system should be readily learnable. Justification: the system will be used by people with little, if any, pervious experience of IT systems. Metric: a novice user should be able to complete the task in 20 seconds.

6.4 Requirements Gathering (RG) Types of Requirements: Functional: specify the functions that your system will need. Ex, there might be a need to be able to return to the home screen directly from any screen. Data: focuses on the types of input and output required. Ex, the system might require you to input a password in the form of a combination on numbers and letters. It might be required to output responses to users in the form of easy-to-understand sentences. Environmental: it sets out the environment in which the system will be used (technical or non-technical). For example, the system might work under the UNIX operating system (technical) and be used in an office setting only. User: it defines the user groups. (ex. Qualified lawyers) Usability: it identifies key usable issues. (ex. That the system is capable of being used by inexperienced users or those with visual impairments, usability could also include learnability, flexibility and consistency).

6.4 Requirements Gathering (RG) The distinction between useful and usable is relevant here and worth exploring: Useful means that the sys. can do the task. Functional req’ts are what makes the sys. useful. // // // typically quantitative. Usable means that using the sys. makes the task easy to do.

6.5 Design & Storyboarding Design rationale: it allows designers to consider & document the thinking & reasoning behind the design options that they are proposing at any stage of the process. This serves both to help designers check their own thinking, and to record the development of ideas over the course of a project. Part of the thinking behind Design Rationale is that no single design idea will be completely right, and that designers will at times need to: select between options or merge multiple solutions and also to rethink assumptions that may have gone into their production.

6.5 Design & Storyboarding Design space analysis: (it’s a design rationale example) QOC notation (question, option & criteria): to describe issues raised in design meetings (go to pages 84-85 for example). Storyboarding: They provide rough sketches of what the system will look like & are good for graphical interfaces and websites. They are cheap to produce & easy to change. You will also need a map to show how the ‘narrative’ of the storyboard runs: they show how sketches relate to one another. Prototype does not have to be done using a software. It can be doing using pen-and-paper sketches. Therefore, it is a cheap and rich way of expressing an idea.

6.6 Prototyping Iterative design & prototyping Prototyping is central to user-centered design It is best to think of prototyping as a process rather than simply the creation of an artifact: it is the process of creating an external representation of some design thinking. You can inspect & discuss the representation with other designers and users. The critical elements of the prototyping process are: To turn abstract design ideas into a physical form: must transform idea to a prototype, which may alert the designer of potential critical difficulties that may be associated with that idea. To communicate your ideas: consultation & teamwork is very important. To iterate & improve: it helps to nurture, develop and document the development of the prototype. Types of prototype: Throwaway, Evolutionary & Incremental.

6.7 Techniques Used In Prototyping There are few important distinctions to be noted when working with prototypes: Rapid prototyping High-fidelity vs. Low-fidelity Horizontal vs. Vertical prototypes Wizard of Oz Limited functionality simulation