Lifecycl ppt HCI Lifecycle Ticket by MikeJenny

VIEWS: 178 PAGES: 25

Lifecycl ppt HCI Lifecycle Ticket

More Info

HCI Lifecycle Overview
and Initial Analysis
Lecture Overview
   Overview of interactive system design
   Development team roles
   Problem statement
   Systems analysis + HCI perspective
   User analysis

                                   HCI and the Software Lifecycle

                                                     Problem statement
                                       Systems Analysis (inc. user and task analysis)

U s e r P a r t i ci p a t i o n

                                             Requirements spec. (inc. usability specs.)
                                                   User object modeling
                                      System design spec. (inc. Interface design spec.)

                                      User’s conceptual model design / Interaction style
                                           Interaction design / Presentation design
                                                 Prototype (inc. online help)

                                             Evaluation (Analytical, Empirical)

Perspectives in Tension
   Systems analysis and software
       Logical flow of data
       Computational efficiency
       Ease of development

   HCI
       Quality of user interface

    Systems Analysis + HCI
   Systems analysis
       Identify entities of significance to the „system‟
       Functionally oriented and data driven
       Design notation
            E.g. Data flow diagrams, Entity-Relationship diagrams
            Often met with resistance by users
   HCI perspective
       Identifies issues of practical effectiveness
       Usability orientation -
            E.g. speed, error rates
       Design notation
            Designed to be understood by users e.g. task hierarchy
             diagram, screen sketch                                   5
Microsoft: Using Customer Feedback
for Developing Web Site
   Listening to and understanding users
   Observing how they work with software
    and what tasks they perform
   Coming up with features to address
    these work styles and tasks
   Testing the features with the people
    that actually use them
    See -
    Conventional + HCI Data
   Read background material
   Guided tour of work environment
   Interviews
   Observation
   Questionnaires
   Forms analysis
   Verbal protocol
   Tape / Video recording / Transcript
Definition of Design

      “ . . . the use of
       scientific principles,
      technical information
      and imagination.”

                    Feilden Committee Report,
                    1963 Engineering Design,

    Balance Among Conceptual, Interaction
    and Presentation Design Effort
Detailed            Presentation
design              (‘Look’)
                      – Visual
       10%              representations            Design
                      – Aesthetics               proceeds
                    Interaction (‘Feel’)           mainly
                                                 from the
       30%           – Interaction                bottom
                                                  level up
                     – Standard menus

      60%           Metaphors, object
Conceptual design   attributes, relationships,

 Balance of Design Effort
Conceptual Level – 60% of Design Effort
  Deciding what is required in terms of data,
  functions and usability. Deciding on metaphors
  that might be used in the interface. What objects
  should the interface have (buttons, keyboard, etc),
  how should they behave, are there any
  relationships between them?

Interaction Design – 30% of Design Effort
   How will interface „feel‟ to the user? How will they
   interact with it – press buttons (direct or roll-ball
   device), select from menus? If so, what should
   these contain? Will user need to type in data?
Balance of Design Effort (2)
Presentation – 10% of Design Effort
  How should the interface look? How
  will information be represented? What
  colours to use, size of objects, buttons,

Roles in a Team for Interactive
System Development

interaction              User interface
 developer                 software

Design Team Roles
   User (domain expert)
       Person who is to use the system and/or who has
        detailed knowledge about what the system must
   User Interaction Developer
       Person who designs interface and support
        materials. Designs conceptual models of what is
        required from users point of view. Decides on
        menus, colours, fonts, etc.
   User Interface s/w Developer
       Person who programs and implements designs
        (data, process and interface)
Fundamental Activities of
Interactive System Design
   Problem Definition
   Information gathering and model
   Synthesis (or enhancement) of a
   Analysis (or evaluation) of a solution
    These activities are iterated
    Problem Statement
    A definition of Design Objectives
   Supported activity – human activity that
    proposed system will support
   Users –who will perform that activity
   Level of support to be provided - system
   Form of solution – to the problem

   Statement of overall goal of whole system in a
    single phrase or sentence
        Aim: show clear understanding of what is needed
        Main assumptions should be separately stated 15
Problem statement - example
   A railway company has a 'situation of
    concern' - passenger queues at ticket offices
    are too long, too often. They might
    consider a number of possible solutions that
    involve design problems.
   Can you think of possible solutions (think -
    ‘what, precisely, is the problem?)?’

Queue problem - possible
   A railway company has a 'situation of concern' - passenger
    queues at ticket offices are too long, too often. They might
    consider a number of possible solutions that involve design
    problems. For example,

       Easier ticket preparation by the clerks.
       Easier payment handling by clerks.
       Easier record keeping by clerks.
       Ticket machines for passengers.

 Design a cash-operated machine for quick and
       easy purchase of railway tickets for
Problem Statement
 A cash-operated machine – form of solution

 For quick and easy – level of support

 Purchase of railway tickets – supported
 By passenger - users
Design a hand-held, inexpensive machine
which will allow professional/managerial
people to maintain an appointments diary
and which will support the functions of
adding, deleting, modifying, viewing
appointments, and will allow and alarm to
be set for a user-specified time before
certain appointments

Problem Statement: Example
for Diary Management System
   Form of solution
       Portable hardware, low selling price
   Level of support to be provided
       Appointment (an object)
       Maintain (an operation)
            Add, modify, delete, view appointments
            Adjust alarm
   Supported activity
       Maintain appointments
   Users
       White collar customers
User Analysis
   Expertise level (novice, intermittent,
   Familiarity with specific hardware and
   Software with which users are familiar
   Job-related information access needs
       E.g. summary vs detailed
   Skill base e.g. keyboarding
   General educational level
   Organization-specific knowledge and/or
    experience                               21
  User Analysis: Example for
  Railway Ticket System
 Expertise level –
    Novice eg one off travellers on the line such as tourists
    Intermittent eg people in the area who travel occasionally
    Expert eg frequent commuters

 Familiarity with specific hardware and software
    No assumptions can be made in this case

 Software with which users are familiar
    Eg ATM machines

 Job-related information access needs
    Cost of journey to specific locations

    User Analysis: Example for
    Railway Ticket System (2)
   Skill base
       Are all users likely to be able to type accurately and quickly
        on QWERTY or alphabetic keyboard?

   General educational level
       All levels must be catered for including those who don‟t
        speak English or can handle English currency

   Organization-specific knowledge and/or
       Can we assume everyone has bought a ticket before?

        User Analysis: Example for
        Diary Management System
   User characteristics
       Professional, white collar
       Keeps schedule for self and/or others
       Sometimes just for personal use
       Keeping diary is a very small part of user‟s job
   Skills
       High general skill level
       Not necessarily computer skilled
       Not all will have keyboard skills
   Conclusions
       Keep it simple
       Functionality and usability greater than for paper diary
       Minimize typing, and be quick and easy to learn
Lecture Review

   Overview of interactive system
   Development team roles
   Problem statement
   Systems analysis + HCI perspective
   User analysis


To top