The User-Centred System Design Process

1
The User-Centred System Design Process
2
The Water fall model

• The water fall model is a common
  conceptualisation of the traditional approach to
  interactive systems design.

3
The Water Fall Model
Requirements
Architectural Design
Detailed design
Coding and unit testing
Integration And testing
Operation and Maintenance
4
Stages of the Waterfall model

• Requirement specification
• Architectural design
• Detailed design
• Coding and Testing
• Integration and deployment
• Maintenance

5
Requirements specification

• This is the first stage in the water fall model
  and the most critical. For this reason, the
  outcome of this stage- the requirements
  specification should be based upon a good
  understanding of the users and their needs.
• There are different types of requirement
• Functional requirements
• Data requirement
• Environment requirement
• User requirement
• Usability requirement

6
Type of requirements

• Functional requirements specify what functions
  are needed. For example, provide a means of
  undoing an action
• Data requirements specify the data inputs and
  outputs of the system.
• Environment requirements specify the
  environment or context required. For example, the
  system must run on the Linux OS.
• User requirements define the user population,
  For example, the typical user, significant
  subgroups and important exceptions

7
Type of requirements (Cont.)

• Usability requirements specify the usability
  measures of a system. For example, the system
  must provide clear instructions.
• -? Task analysis is an important set of
  techniques during requirements specification and
  is covered later.

8
Architectural Design

• Requirements focus upon what is required
• Architectural design is focused on how it can be
  achieved.
• The overall architectural design identifies the
  main components and set out the relationships
  between them.

9
Detailed Design

• The detailed design is developed from the
  architectural design, selecting between available
  options. Careful of documentation of the options
  available- and the rationale from choosing among
  them is important.

10
Coding and Testing

• Given a detailed design, the next step is to
  produce software and to test it throughly.

11
Integration and Testing

• At this stage, individual components are
  integrated according to the overall architectural
  design.
• Relationships between the different components
  are evaluated.
• Testing may also including asking users to test
  the system to evaluate it against design and
  standards.

12
Maintenance

• This is when the system is in use. At this stage,
  practical use of the system often identifies
  further errors in the code or the design

13
Weakness of the Waterfall model

• Traditional methods often focus on technology or
  take purely technical system approach. The user
  is often ignored or given a minimal role. User
  preferences and abilities are often overlooked.
• Such methods often reflect only the views of the
  designer other than steakholders
• The user interface is often designed around a
  technical view of how the system works. The
  designer may focus on the technical issues in
  particular adding new function at the expense of
  user needs.

14
User-Centred System Design
Task analysis
Requirements gathering
Design and storyboarding
Prototype and implementation
Evaluation
Installation
15
Key Attributes of User-Centred System Design

• Task analysis
• Requirement gathering
• Design and storyboarding
• Prototype implementation
• Evaluation
• Installation

16
Task Analysis

• We need to consider the tasks for which the new
  or revised
• system is to be used. Whatever the task involved,
  you need
• to understand them well and analyze them
  systematically.

17
Task analysis (cont.)

• Input to task analysis
• Problem statement
• Observation of existing systems
• Analysis of user population
• Output of Task analysis
• Hirarchical task analysis (HTA)

18
Task analysis (cont.)

• Why do a task analysis?
• It gives a clearer understanding of what user
  want.
• It is rare for something completely new to be
  designed usually something existing is redesigned

19
Requirement gathering

• Task analysis is an important stage in UCSD , but
  it is not the complete picture. A heirarchical
  task analysis will tell you about the tasks that
  the system needs to support. Equally important is
  an analysis of the abilities , skills and
  preferences of your users

20
Requirement gathering

• Input to Requirement gathering
• Hierarchical task analysis
• Design heuristics
• Relevant user models
• Usability principles
• Other constraints (e.g. external standards,
  hardware platform)

21
Requirement gathering (Cont.)

• Output of Requirement gathering
• A statement of requirements
• Why do we need a statement of requirements?
• It provides an explicit, testable description of
  what is
• wanted of the system
• It describes what the system should do without
  worrying too much about how it does it.

22
Design and Storyboarding

• Storyboards provide users with an opportunity to
  visualise the design and to test them, quickly
  and cost-effectively.

23
Design and Storyboarding

• Input to Design and Storyboarding
• Statement of requirements
• Usability principles, heuristics
• Other constraints
• Evaluation from previous iterations

24
Design and Storyboarding(Cont.)

• Outputs of Design and Storyboarding
• A storyboard design
• System justification why the system is going to
  be the way it is.
• A first-draft design of how the system works and
  what it looks like
• A stakeholder needs a analysis

25
Design and Storyboarding(Cont.)

• Why do we need a design and storyboarding?
• It provides designers with an apportunity to
  visualize their design and to review it, quickly
  and cost-effectively with users.

26
Prototype Implementation

• Designers and users often find it diffcult to
  hold in mind all the critical details of a
  proposed new system.
• A prototype provides an early opportunity to
  evaluate the strength and weakness of the
  proposed system.
• Prototypes are simulations of the live system
  rather than pen-and-paper sketches. They are
  closer approximation to the proposed system.

27
Prototype Implementation

• Inputs to Prototype Implementation
• A storyboard design
• Evaluations from previous iterations
• Outputs of Prototype Implementation
• A working, testable prototype
• Why do we need to prototype our design?
• It provides a relatively low-cost implementation
  that real users can usefully test.

28
Evaluation

• User-centred system design is based on the belief
  that usable systems evolve through an iterative
  process of gathering, representing, testing and
  refining ideas. In other words, they are
  developed through an iterated process of
  requirements gathering, prototyping and
  evaluation.

29
Evaluation

• Inputs to Evaluation
• A working prototype
• The statement of requirements
• Outputs of Evaluation
• Transcripts of the evaluation what was said or
  done during the evaluation
• The Evaluation report (Are the requirements met?
  If not, why not?)

30
Evaluation (Cont.)

• Why do an evaluation?
• It provides evidence of how a system is actually
  used.

31
Installation

• By this stage, we have a fully featured prototype
  that has
• been through extensive evaluation.
• Inputs to installation
• A fully featured prototype
• Outputs of installation
• An acceptable evaluation
• The finished system

32
Summary

• UCSD places the user, their goals, needs and
  activities at
• the heart of the design process. Key aspects of
  the UCSD
• approach are iteration and evaluation.