Docstoc

Lifecycl ppt HCI Lifecycle Ticket

Document Sample
Lifecycl ppt HCI Lifecycle Ticket Powered By Docstoc
					Human-Computer
Interaction




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



                                            2
                                   HCI and the Software Lifecycle




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




                                                                                           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.)




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

                                             Evaluation (Analytical, Empirical)


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

   HCI
       Quality of user interface

                                    4
    Systems Analysis + HCI
    Perspective
   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 - http://www.microsoft.com/misc/backstage/colu
                                                         6
    Conventional + HCI Data
    Gathering
   Read background material
   Guided tour of work environment
   Interviews
   Observation
   Questionnaires
   Forms analysis
   Verbal protocol
   Tape / Video recording / Transcript
                                          7
Definition of Design

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

                    Feilden Committee Report,
                    1963 Engineering Design,
                    HMSO

                                                8
    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
                       techniques
                                                  level up
                     – Standard menus


      60%           Metaphors, object
Conceptual design   attributes, relationships,
                    behaviours

                                                             9
 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?
                                                           10
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,
  etc.




                                         11
Roles in a Team for Interactive
System Development
                User
              (domain
               expert)



               Team
   User
interaction              User interface
 developer                 software
                           developer

                                          12
Design Team Roles
   User (domain expert)
       Person who is to use the system and/or who has
        detailed knowledge about what the system must
        do
   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)
                                                     13
Fundamental Activities of
Interactive System Design
   Problem Definition
   Information gathering and model
    building
   Synthesis (or enhancement) of a
    solution
   Analysis (or evaluation) of a solution
    These activities are iterated
                                             14
    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
    usability
   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?)?’

                                              16
Queue problem - possible
solutions
   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.



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

 For quick and easy – level of support

 Purchase of railway tickets – supported
  activity
 By passenger - users
                                                18
 Problem
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

                                       19
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
                                                      20
User Analysis
   Expertise level (novice, intermittent,
    frequent)
   Familiarity with specific hardware and
    software
   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

                                                                  22
    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
    experience
       Can we assume everyone has bought a ticket before?

                                                                         23
        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
                                                                   24
       Minimize typing, and be quick and easy to learn
Lecture Review

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


                                         25

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:265
posted:12/19/2010
language:English
pages:25
Description: Lifecycl ppt HCI Lifecycle Ticket