ACM SIGCHI Curricula for Human-Computer Interaction

by Hewett, Baecker, Card, Carey, Gasen, Mantei, Perlman, Strong and Verplank
Copyright © 1992,1996 ACM SIGCHI

Last updated: 2009-07-29 Accesses since 1997-04-17: 134,454

APPENDIX F: Case Studies in Human-Computer Interaction {p. 155}

Marilyn Mantei
Department of Computer Science
University of Toronto

Table of Contents

Introduction
Case Study 1: What are We Doing, Really? {p. 157}
Case Study 2: The Blessing {p. 161}

Introduction

A. Case Studies Used in the Example

The development of an integrated word processor, spreadsheet and database program for the Amiga microcomputer in a small start-up company.
The development of a computer assisted instruction package for building animated tutorials for chemical engineering students.

B. Classic Types of Problems in User Interface Design

Scope of task is defined as anything associated with human element.
Areas of effort between software developers and human factors personnel in conflict.
Representations and tools for design decisions.
Not enough theory to drive design decisions.
Technology oriented culture not supportive of human factors.

C. Areas of Human Factors Effort in Designing Human Factored Software

Identifying who the users of the software product will be.
Setting software functionality - what the intended goals of the user will be when employing the software aide.
Designing the user interface to the product.
Testing the user interface.

D. The Traditional Software Lifecycle

Feasibility Study
Requirements Definition
Design
Prototype Construction
User Evaluation
System Implementation
Testing
Update and Maintenance

E. Applying the Human Factors Tasks to the Traditional Software Lifecycle

                Software Lifecycle              Human Factors Tasks

        1.      Feasibility Study               Defining User
        2.      Requirements Definition         Setting Functionality
        3.      Design                          Designing User Interface
        4.      Prototype Construction          Designing User Interface
        5.      User Evaluation                 Testing User Interface
        6.      System Implementation
        7.      Testing                         Testing User Interface
        8.      Update and Maintenance          Defining User

Case Study 1: What are We Doing, Really? {p. 157}

Background Material

Company: Star-tronics

20 Employees
Product: Software

Sources of Income:

Sales from Sprite
Venture Capital
Equity Arrangements
Porting Agreements
Marketing: Via Co-op Contracts
Organizations Chart for Star-tronics

Description of Perky

Microprocessor Software
Integrated Spreadsheet, Word processor and DBMS
Icon and Mouse Based
Built-in Tutorial
Creative Use of Color
"Cute"

Human Factors Role

Give Advice on the Design of Perky
- Answer Detailed Design Questions
- Build Tutorial
- Decide on Templates
Advise HF Sprite Changes
- Manual Development
- On-line Tutorial Writing
- User Testing of Changes

Example of Perky Detailed Design Questions

Under what circumstances should the integrity of a paragraph be maintained when performing text insertion?
Should we constantly adjust lines during insertion or should we wait until insertion is an entire line?
Should we distribute spaces in line evenly for right-adjusted text or should we place spaces near long words?

What areas of the Human Factors Software Lifecycle need to be addressed?

        ___ Defining User
        ___ Setting Functionality
        ___ Designing User Interface
        ___ Testing User Interface

Who is the Star-tronics Customer?

Obtaining Information on the User

Existing Data Bases
Questionnaires
Interviews
Focus Groups
Observation
Case Study

User Information Gathered

Attitudes toward Computers
Social and Economic Status
Attitudes toward Tasks to be Supported by Software
Time Use Patterns
Usage of Existing Systems

Interaction with Software Development Team

Redo Management Structure to co-lead Perky Project
Teach Weekly Human Factors Seminar
Base Human Factors Seminar on Existing Product Built by Team
Ask for Amount of Effort Estimate on Each Design Change Requested
Serve as Management Go-between
Stay away from Programming

Answering Detailed Design Questions

Does Decision Affect Product Image?
Does Decision Affect Interface Consistency?
Does Decision Affect Completion Time?
Does Decision Affect Other Parts of Programs?

If none of the above, let software team make decision!

IF USER BASE IS DISCRETIONARY, LET PRODUCT IMAGE GOVERN THE DESIGN DECISION

IF TRAINING TIMES A SIGNIFICANT ISSUE, LET INTERFACE CONSISTENCY GOVERN DESIGN DECISION

Choosing Templates for Perky

Brainstorming Groups
- Videotape/CD lists
- Hobby lists
- Direct line to bank
- Personal letter writing
- Volunteer group accounting
Personal Diaries of Time Usage
- Sorting mail
- Changing clothes
- Housework
- Work brought home from office
Focus Groups
- Low amount of information processing tasks in home
- High need to manage money
- Conflicting perspective of family use of computing
- Education seen as best use
- Home task management
- Computer not a status symbol

Tasks Recommended for Sprite

Use data from helpline to find difficulties in user interface
Design consistent vocabulary for describing sprite interface
Make manual short and indexed by user tasks
Lay out command sequences for user tasks and check for user perceived consistency

Tasks Recommended for Perky

Define User
- Existing Economic Databases
- Focus Groups
  - Short Term User - Computer Co.
  - Mid Range User - France, Italy
  - Long Range User - Homebanking
Define Templates
- Brainstorming/Focus Groups
Run User Tests on Existing Software
- Mouse handling awkward
- Use threshold very high
- Graphics confusing
- Tutorial too fast
- Short animations very helpful
- Most detailed design decisions do not affect user unless they affect interface consistency

Five Years Later

Computer Contract with Amiga signed
Sales of Amiga sluggish and Star-tronics closed down
Company officers opened new company selling redone version of Sprite to France and Italy

Case Study 2: The Blessing {p. 161}

Background Material

Organization: Chem Engineering Department
Software funded by National Science Foundation grant
Grant about to expire
Software already in use
Software in public domain
Distribution channels in place
Discretionary adoption of software hoped for

Description of Software Product

Computer Aided Instruction System in Chem Engineering
Allowed instructors to build graphics simulations of processes
Simulations were driven by sets of equations
Students had control over setting the values of the parameters in the equations

Human Factors Role

Evaluate Software Product
Recommend Changes to Design of Software
Write Human Factors Evaluation for NSF Report

1. What areas of the Human Factors Software Lifecycle need to be addressed?

        ___ Defining User
        ___ Setting Functionality
        ___ Designing User Interface
        ___ Testing User Interface

Evaluation of CAI System

Instructor interface complex and difficult to use
- Required considerable external memory
- Required detailed command sequences
- No immediate feedback on command sequences
- No recovery from basic errors

Evaluations of CAI System

Student interface highly dependent on designed courseware
- Easy for students to get lost in sequence of screen displays
- Information on separate screens not integrated by student
- Students learning graphics manipulation not process concepts desired
- Response time too slow to connect engineering process behavior to student's input

Consultant Recommendations

Add editor to instructor interface
Build and market courseware, not CAI package
Build courseware templates for instructor use
Read large body of literature on computer courseware design
Run user tests on courseware

Five Years Later

Editor borrowed from other source and built into software package
Software not used
New graphics-based computes supporting more sophisticated software
Text book publishers beginning to market CAI courseware