Key Usability and Ethical Issues in the NAVI ... - Semantic Scholar

Key Usability and Ethical Issues in the NAVI programme (KEN) Deliverable 1 Basics of Human-Centred Design in Personal Navigation VERSION 1.0 Eija Kaasinen 1), Juha Luoma 2), Merja Penttinen2), Tuula PetäkoskiHult1), Rolf Södergård3)

1)

VTT Information Technology VTT Building and Transport 3) Helsinki University of Technology 2)

Last modified on 16 January, 2001 KEN_D1_10.doc

KEN

Basics of Human-Centred Design in Personal Navigation

1.0 15.1.2001

Version history Version

Date

Author(s)

Description

0.1

8.12.2000

Eija Kaasinen

First draft

0.3

21.12.2000

Eija Kaasinen

Navikärki material (MP, TPH)

Merja Penttinen

Usability issues in maps & navigation systems (RS)

Juha Luoma

Tuula Petäkoski- Usability issues in mobile systems (RS, EK) Usability issues in in-vehicle navigation systems Hult (JL, MP) Rolf Södergård Usability issues in adaptive systems (EK) Standards for in-vehicle navigation (JL, MP) 0.4

2.1.2001

Eija Kaasinen

Proof-reading, introduction, conclusions

1.0

15.1.2001

Eija Kaasinen

Language-check by Richard Walker Abstract, references revised

Contact information Eija Kaasinen VTT Information Technology P.O. Box 1206, FIN-33101 Tampere, Finland Street Address: Sinitaival 6, Tampere Tel. +358 3 3163 323, fax +358 3 317 4102 Email: [email protected] Web: http://www.vtt.fi/tte

End of editable fields

Copyright © KEN Consortium 2001. All rights reserved. The information in this document is subject to change without notice and does not represent a commitment on the part of KEN Consortium. No part of this document may be reproduced without the permission of KEN Consortium.

KEN


1.0 15.1.2001

Abstract This report is the first deliverable of the Key Usability and Ethical Issues in the NAVI programme (KEN) project. It brings together current knowledge about usability and human-centred design to serve as a basis for the co-operation of the KEN project and the projects of the NAVI programme. The report is targeted at anyone participating in the design of products and services for personal navigation and does not require any background knowledge about usability or personal navigation. Part I of the report describes the principles of the human-centred design approach and introduces human-centred design activities in different phases of design projects. The incorporation of a human-centred approach is characterised by: q

active involvement of users and clear understanding of user and task requirements

q

an appropriate allocation of functions between users and technology

q

the iteration of design solutions

q

multidisciplinary design

In the design and evaluation of the products and services for personal navigation we can utilise mainly the same methods as in designing any other products. However, the contexts of use in personal navigation are often very demanding. That is why the users and their contexts of use should be studied thoroughly from the very beginning and throughout the design process. Part I of the report can be utilised when planning a design project and defining the human-centred design activities needed. This part of the report can also be used as a reference book during the design process in adopting different usability design and evaluation methods. Part II of the report gives an overview of usability design issues in personal navigation. Personal navigation device usability can be seen as an intersection of the usability of maps, mobile devices, navigation systems and, in the case of location-aware systems, adaptive systems. Each of these elements has its own usability issues that have to be considered when designing navigation devices and services. Part II of this report also gives an overview of available usability guidelines and standards for different device and software environments. Part II of the report can be used as a reference book to select the usability design guidelines that each individual project should adhere to. This report presents mainly general principles for human-centred design. From here on we will concentrate on personal navigation specific issues. Together with the projects of the NAVI programme we will identify the most suitable usability design and evaluation methods, and we will design tools for these methods. We will also identify new usability design guidelines for different types of products and services for personal navigation.

VTT Information Technology

i

Modified on 16.01.01

KEN


1.0 15.1.2001

Table of Contents 1

INTRODUCTION .................................................................................................................. 1 1.1 1.2 1.3 1.4

2

PURPOSE ............................................................................................................................... 1 SCOPE ................................................................................................................................... 1 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ................................................................. 2 OVERVIEW ............................................................................................................................ 2

HUMAN-CENTRED DESIGN APPROACH...................................................................... 3 2.1 WHAT IS USABILITY?............................................................................................................ 3 2.2 WHY SHOULD YOU ADOPT A HUMAN-CENTRED DESIGN APPROACH?................................... 4

3

PRODUCTS AND SERVICES OF PERSONAL NAVIGATION ..................................... 5

PART I HUMAN-CENTRED DESIGN APPROACH 4

HUMAN-CENTRED DESIGN IN PROJECTS .................................................................. 7 4.1 PLANNING THE PROJECT ....................................................................................................... 7 4.2 MULTI-DISCIPLINARY PROJECT TEAM ................................................................................... 7 4.2.1 Who do you need as actors.......................................................................................... 7 4.3 THE DESIGN PROCESS............................................................................................................ 9

5

HOW TO DEFINE THE CONTEXT OF USE.................................................................. 10 5.1 METHODS FOR UNDERSTANDING THE CONTEXT OF USE ...................................................... 11 5.1.1 Interviews .................................................................................................................. 11 5.1.2 Observation ............................................................................................................... 12 5.1.3 Surveys ...................................................................................................................... 12 5.1.4 Diary Methods........................................................................................................... 12 5.1.5 Ethnographic Approach ............................................................................................ 13 5.1.6 Contextual Inquiry .................................................................................................... 13 5.1.7 Task Analysis............................................................................................................. 13 5.2 HOW TO DEFINE THE INTENDED CONTEXT OF USE ............................................................... 13 5.3 CONTEXT OF USE IN PERSONAL NAVIGATION ...................................................................... 14

6

HOW TO DEFINE USER REQUIREMENTS.................................................................. 14 6.1 RELATIONSHIP TO TRADITIONAL REQUIREMENTS ANALYSIS ............................................... 15 6.2 POINTS OF VIEW IN USER REQUIREMENTS ........................................................................... 16 6.3 METHODS FOR EARLY DESIGN............................................................................................. 16 6.3.1 Focus Groups............................................................................................................ 16 6.3.2 Group Discussions/ Future Workshops..................................................................... 17 6.3.3 Brainstorming ........................................................................................................... 17 6.3.4 Scenario Building...................................................................................................... 17 6.3.5 Literature study ......................................................................................................... 18 6.3.6 Evaluation of previous products................................................................................ 18 6.4 METHODS FOR DEFINING USER REQUIREMENTS .................................................................. 18 6.4.1 Task Allocation Charts.............................................................................................. 18 6.4.2 Functionality Matrix ................................................................................................. 18 6.4.3 Evaluation results of the previous iteration cycles.................................................... 19 6.5 BUILDING AN ITERATIVE SPECIFICATION OF USER REQUIREMENTS ..................................... 19 6.5.1 Prioritisation ............................................................................................................. 21 6.5.2 Requirements achievement........................................................................................ 21 6.6 USER REQUIREMENTS FOR PERSONAL NAVIGATION ............................................................ 22

7

HOW TO ILLUSTRATE THE DESIGN........................................................................... 23 7.1 USE CASES .......................................................................................................................... 24 7.2 SCENARIOS ......................................................................................................................... 24


ii


KEN


7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 8

1.0 15.1.2001

STORYBOARDING / PRESENTATION SCENARIOS .................................................................. 25 MOCK-UPS AND PROTOTYPES ............................................................................................. 25 CARD SORTING ................................................................................................................... 26 ICON INTUITIVENESS TESTING ............................................................................................ 26 PAPER PROTOTYPING .......................................................................................................... 27 WIZARD OF OZ PROTOTYPING ............................................................................................ 27 VIDEO PROTOTYPING.......................................................................................................... 27 RAPID PROTOTYPING...................................................................................................... 28 INFORMATION PRESENTATION IN PERSONAL NAVIGATION ............................................ 28

HOW TO EVALUATE THE DESIGN .............................................................................. 31 8.1 HEURISTIC EVALUATION ..................................................................................................... 32 8.2 CO-OPERATIVE EVALUATION.............................................................................................. 33 8.3 LABORATORY-BASED OBSERVATION ................................................................................. 33 8.4 DISCOUNT USABILITY ENGINEERING ................................................................................... 34 8.5 WALKTHROUGH.................................................................................................................. 35 8.6 PARALLEL DESIGN .............................................................................................................. 35 8.7 EMPATHIC MODELLING ...................................................................................................... 36 8.8 PARTICIPATORY HEURISTIC EVALUATION ........................................................................... 36 8.9 FIELD TRIAL ........................................................................................................................ 37 8.10 EVALUATION OF PRODUCTS AND SERVICES FOR PERSONAL NAVIGATION ....................... 38 8.10.1 Evaluation methods for in-vehicle navigation systems ......................................... 39 8.10.2 Questionnaires for user evaluation....................................................................... 42

9

HOW TO MAKE IT ITERATIVE ..................................................................................... 42 9.1 HOW CAN YOU MANAGE ITERATIVE DESIGN?...................................................................... 42 9.2 DESIGN RATIONALE ............................................................................................................ 43

PART II GUIDELINES FOR USABILITY DESIGN 10

INTRODUCTION ................................................................................................................ 45

11

USABILITY ISSUES IN MAPS.......................................................................................... 45 11.1 COGNITIVE PROCESSES IN MAP READING ........................................................................ 46 11.2 LAWS OF PERCEPTUAL ORGANISATION ........................................................................... 46 11.3 IMPLICATIONS OF HUMAN VISION FOR MAP READING ..................................................... 48 11.3.1 Symbol detection................................................................................................... 48 11.3.2 Symbol discrimination .......................................................................................... 49 11.3.3 Contrast ................................................................................................................ 49 11.4 IMPLICATIONS OF HUMAN COGNITION FOR MAP READING............................................... 50 11.4.1 Symbol identification ............................................................................................ 50 11.4.2 Transformation of information ............................................................................. 50 11.5 SCREEN MAPS ................................................................................................................. 51 11.5.1 Display size and resolution................................................................................... 51 11.5.2 Using colour ......................................................................................................... 52 11.5.3 Symbol design for screen maps............................................................................. 52

12

USABILITY ISSUES IN MOBILE SYSTEMS................................................................. 53 12.1 DISPLAY SIZE ................................................................................................................. 53 12.1.1 Semi-transparent widgets...................................................................................... 54 12.1.2 Font size................................................................................................................ 55 12.2 INPUT DEVICE ................................................................................................................. 55 12.2.1 Overloaded buttons............................................................................................... 55 12.2.2 Softkeys ................................................................................................................. 56 12.2.3 Pointing device ..................................................................................................... 56 12.3 MOBILE CONNECTIONS ................................................................................................... 56


iii


KEN


1.0 15.1.2001

12.4 OTHER USABILITY ISSUES ............................................................................................... 56 12.5 MOBILE USE ................................................................................................................... 57 12.5.1 The mobile use context.......................................................................................... 57 12.5.2 Alternative interaction styles ................................................................................ 57 13

USABILITY ISSUES IN NAVIGATION SYSTEMS ....................................................... 58 13.1 INTERACTION ................................................................................................................. 58 13.2 INFORMATION VISUALISATION ....................................................................................... 58 13.2.1 The navigation route............................................................................................. 59 13.2.2 Map orientation .................................................................................................... 60 13.2.3 Weather................................................................................................................. 60 13.2.4 Information freshness ........................................................................................... 61 13.2.5 Groups of objects .................................................................................................. 61 13.2.6 Movement.............................................................................................................. 62 13.3 ASCERTAINING THE USER’S LOCATION ........................................................................... 62

14

USABILITY GUIDELINES FOR IN-VEHICLE NAVIGATION SYSTEMS............... 62 14.1 DRIVER’S TASKS ............................................................................................................. 63 14.1.1 Overall design of in-vehicle information and communication systems................. 64 14.1.2 Information presentation ...................................................................................... 64 14.1.3 Interaction with displays and controls.................................................................. 65 14.1.4 Location of visual display and driver console ...................................................... 65 14.1.5 Auditory information............................................................................................. 65 14.1.6 Information about the system................................................................................ 66 14.2 ISSUES RELATED TO SYSTEM SAFETY .............................................................................. 66

15

USABILITY ISSUES IN ADAPTIVE SYSTEMS............................................................. 67

16

USABILITY GUIDELINES AND STANDARDS ............................................................. 69 16.1 USABILITY HEURISTICS .................................................................................................. 69 16.1.1 Ten Usability Heuristics by Jakob Nielsen 1994 .................................................. 70 16.1.2 Heuristic checklist for scenarios........................................................................... 71 16.2 USABILITY GUIDELINES FOR SOME COMMON ENVIRONMENTS ........................................ 71 16.2.1 MS Windows Design Guidelines ........................................................................... 71 16.2.2 Macintosh Human Interface Guidelines ............................................................... 71 16.2.3 Java Look and Feel Design Guidelines ................................................................ 72 16.2.4 Web Design Guidelines......................................................................................... 72 16.3 USABILITY GUIDELINES FOR MOBILE ENVIRONMENTS .................................................... 73 16.3.1 Java Touchable Look and Feel Design Guidelines............................................... 73 16.3.2 EPOC Guidelines.................................................................................................. 74 16.3.3 Guidelines for Mobile Web Access ....................................................................... 74 16.3.4 WAP Design Guidelines........................................................................................ 75 16.3.5 ACTS Guideline SII-G8 - User Aspects for Mobility ............................................ 76 16.4 USABILITY STANDARDS .................................................................................................. 76 16.4.1 General standards................................................................................................. 76 16.4.2 Standards for human-machine interaction in vehicle systems .............................. 77

17

CONCLUSIONS................................................................................................................... 79

18

REFERENCES ..................................................................................................................... 80

ANNEX 1 NAVIKÄRKI MATERIAL (IN FINNISH) .............................................................. 87


iv


KEN

1


1.0 15.1.2001

Introduction

1.1 Purpose The Personal Navigation (NAVI) programme was launched in May 2000 by the Ministry of Transport and Communications in Finland. The NAVI network and management board include representatives of device manufacturers, telecom operators, software industry, content industry and public administration. NAVI is a research and development as well as co-operation programme and it will last three years (2000–2002). The programme includes research, product and service development, regulation, awareness activities, education, follow-up, co-ordination and strategy work. The programme is expected to create new services as well as much new business and many internationally marketable products. The NAVI programme consists of projects focusing on vertical applications, generic technologies, horizontal support projects, practical training and co-ordination. Key Usability and Ethical Issues in the NAVI programme (KEN project) is one of the horizontal support projects in the programme. This report is the first deliverable of the KEN project. It brings together current knowledge about usability and human-centred design to serve as a basis for the cooperation of the KEN project and the projects of the NAVI programme. We describe the elements needed in a human-centred project and introduce human-centred design activities in different phases of design projects. We describe essential methods to design and evaluate usability and point out where the methods could be utilised. Currently, there is very little written information about the usability of personal navigation systems. We have made a literature review, where the problem of navigation device usability has been divided into map usability, mobile device usability, and navigation system usability. The usability issues of each of these three parts are discussed separately in this report. We also describe usability issues with adaptive systems – these should be taken into account, e.g., when designing location-aware services. Finally, we present an overview of currently available usability design guidelines and standards. This report is targeted at anyone participating in the design of products and services for personal navigation and does not require any background knowledge about usability or personal navigation.

1.2 Scope The report gives an overview of the human-centred design approach and usability design guidelines. The material is largely based on the work of the ACTS USINACTS project and the Navikärki project. ACTS USINACTS was a usability support project in the Advanced Communication Technologies and Services Research programme of the European Community in 1995-2000. The Navikärki project was the planning project for the NAVI programme in 1999-2000. The project was run under the management of VTT


1


KEN


1.0 15.1.2001

Information Technology in co-operation with many enterprises and partners in the administration. This report presents mainly general principles for usability design and evaluation as well as general usability design guidelines and standards that might be utilised in designing products and services for personal navigation. In later reports of our KEN project, we will concentrate more on issues specific to Personal Navigation.

1.3 Definitions, Acronyms, and Abbreviations

ACTS

Advanced Communication Technologies and Services (ACTS) was part of the Fourth Framework Programme of European Community activities in the field of research and technological development and demonstration (1995 to 2000).

ETSI

The European Telecommunications Standards Institute

HCD

Human-Centred Design

HCI

Human-Computer Interaction

HMI

Human-Machine Interaction

ISO

International Standardization Organization

TICS

Transport Information and Control System

UMTS

Universal Mobile Telecommunication Systems

1.4 Overview Chapters 2 and 3 give an overview of human-centred design and products and services for personal navigation. Part I of this report describes the principles of human-centred design, starting from how to plan a human-centred project and concluding with guidance for different phases of the project. The introduction of different usability design and evaluation methods is largely based on the CD-ROM "Usability in the Information Society. How to design user-friendly products and services" produced by the ACTS USINACTS project (Concejero et al, 2000). Part II of this report gives an overview of usability design guidelines. We describe what is currently known about the usability


2


KEN


1.0 15.1.2001

issues in personal navigation. We also point out usability issues with environments and techniques related to personal navigation, i.e. maps, mobile systems and adaptive systems. Part II concludes with an overview of usability design guidelines and standards.

2

Human-Centred Design Approach

Human-Centred Design is an approach to design where the product development process focuses on users from the very beginning and throughout the development process. By adopting the Human-Centred Design approach we can ensure that we will develop useful and easy-to-use products. The key issue is to accept the fact that in most cases we cannot fix exact user requirements at the beginning of the design process. That is why we have to refine the initial user requirements throughout the design process by illustrating the planned design decisions to the users and actively gathering their feedback. Examples of such illustrations are use case scenarios, paper prototypes and computer-based prototypes. It is important that the Human-Centred Design approach is adopted from the very beginning of the design process. The earlier a new or a refined user requirement is identified in the design process, the easier it is to take it into account in the design. According to the International Organization for Standardization (ISO) standard ISO 13407:1999 (Human-Centred Design Processes for Interactive Systems), the incorporation of a human-centred approach is characterised by: q

active involvement of users and clear understanding of user and task requirements

q

an appropriate allocation of functions between users and technology

q

the iteration of design solutions

q

multidisciplinary design

The methods for the Human-Centred Design processes include usability design and evaluation methods, and methods for teamwork with users, designers and usability experts. They include methods for user requirements definition, design requirements definition and evaluation. The Human-Centred Design procedures can be applied to any system component with which the user may have to interact. These include hardware and software components, and user manuals.

2.1 What is Usability? Usability is a measure of the quality of a system from the user's point of view. Usability defines whether the system solves the right problems from the user's point of view (i.e. includes the right functionalities) and whether the system solves the problems in the right way (i.e. is easy to use). Usability design includes learning to know the users and


3


KEN


1.0 15.1.2001

understanding their needs so that the user's point of view is properly taken into account in the design. Usability has multiple components. For instance, it is defined by the International Organization for Standardization (ISO) in ISO 9241-11:1999 as "The effectiveness, efficiency and satisfaction with which specified users can achieve specified goals in particular environments". effectiveness

defines whether the system includes the right features from the user’s point of view

efficiency

defines how quick and easy the system is from the user’s point of view

satisfaction

defines that the system should be pleasant to use, so that the users are subjectively satisfied when using it; i.e. they like it.

By adopting the Human-Centred Design approach we can assure the usability of the product to be developed.

2.2 Why should you adopt a Human-Centred Design approach? There are many good reasons to adopt a Human-Centred Design approach. An important reason is the recent legal regulations for designing safe systems that do not harm the health or the well-being of their users (EU Directive 90/270, 1990). But usability engineering has proved that application of the principles of Human-Centred Design has high payoffs (INUSE, 1996): 1. Reduced production costs: the overall development times and costs can be reduced by avoiding over design and reducing the number of changes required late in design. 2. Reduced support costs: systems that are easier to use require less training, less user support and less subsequent maintenance. 3. Reduced costs in use: systems better matched to user needs improve productivity and the quality of actions and decisions. 4. Easy-to-use systems reduce stress and enable users to handle a wider variety of tasks. Difficult-to-use systems are time consuming to use, and are often not exploited to full advantage because the user may be discouraged from using advanced features. 5. Improved product quality: Human-Centred Design results in products that have a higher quality of use and are more competitive in the market. All these benefits are obtained, taking into account the total life-cycle costs of the product, not only those of the development, but also those of the set-up phase and the maintenance phase. The initial costs of Human-Centred Design activities are offset by all the benefits that are produced in the end. The ISO 13407 standard (ISO 13407, 1999) emphasises the ergonomic, economic and social benefits in the rationale for adopting a Human-Centred Design process. Making


4


KEN


1.0 15.1.2001

systems more usable results in better satisfaction of user and organisational needs. The systems a) are easier to understand and use, thus reducing training and support costs; b) improve user satisfaction and reduce discomfort and stress; c) improve the productivity of users and the operational efficiency of organisations, and d) improved product quality appeals to the users and can provide a competitive advantage. The complete benefits of Human-Centred Design can be determined by taking into account the total life-cycle costs: conception, design, implementation, support, use and maintenance (ISO 13407: 1999). A Human-Centred Design can make an important contribution to the success of a product. However, neither Human Factors nor usability engineering can work any kind of magic for solving usability problems at the end of projects. For this reason, it is important that usability is considered from the very beginning and throughout the design process. Usability engineering, even when carefully planned and carried out, cannot guarantee to sell a product per-se. Although an increasingly important attribute for people's purchasing decisions, marketing activities must complement and stress the most important features of the product.

3

Products and services of personal navigation

The products and services for personal navigation can be classified in different ways. From the usability point of view, the services can be classified into three categories according to the intended type of usage: 1. Location information and route guidance is the most traditional service type. The user gets information on his/her own location, the location of the intended points of interest and guidance on how to get there. Such services are already widely available for car navigation, but soon these systems will also be available for pedestrians, cyclists, roller skaters etc. via smart phones and other portable devices. 2. Location information on other people can help in finding lost persons or can provide parents with a new tool for the supervision of their children. Such services will also enable social navigation: a group of people can monitor where the other members of the group are and find out where something interesting is happening. It seems that social innovations will generate totally new ways to utilise these services. However, the possibility of locating people also raises a number of ethical questions. 3. Location-aware services will help mobile users in coping with information overflow. The user will get targeted information, selected on the basis of the current location, the context of use, and the personal preferences of the user. The user can actively browse the information or it can be pushed to him/her automatically, based on the current location.


5


KEN


1.0 15.1.2001

Typical usability design problems with location information and route guidance include: q

The context of use is often demanding: the user can devote only partial attention to the navigation device – he/she is primarily concentrating on actual movement

q

How to indicate the location and direction - map, 3D view, sound, ..

q

How to give an overview of the whole route to the user

q

How to update the route on the screen while the user is moving

q

How to synchronise the view with the movement of the user

q

How to react if the user leaves the predefined route

q

How to adapt the service to different terminal devices

Typical usability design problems with social navigation include: q

How to indicate the location of different persons

q

How does the user select which people to locate

q

How does the user give permission for him/herself to be located

q

What will be the real applications of these features - probably the applications will be found by social innovations

Typical usability design problems with location-aware services include: q

how does the user cope with the application views that change according to the location

q

how to keep the personalisation of the system sufficiently simple

q

location-aware services should often also adapt to the context of use

q

how to keep the services of different service providers consistent

q

it is tempting to push different information to the user, but how can this be kept under user control

q

personalised services will require long-term field trials to assess user acceptance in real contexts of use

Navigation services can be classified in many other ways as well, e.g., professional consumer services, utility – entertainment, type of mobility, user terminal. The KEN project will analyse these classifications in more details in the forthcoming deliverable D002, "Classification of products and services for personal navigation – the user's point of view".


6


KEN


1.0 15.1.2001

Part I Human-Centred Design Approach

4

Human-Centred Design in projects

4.1 Planning the project When planning a project that will adopt a Human-Centred Design approach, the following things should be defined in the project plan (ISO 13407: 1999): a) There should be activities for 1. 2. 3. 4.

defining the context of use specifying user and organisational requirements, producing prototypes and evaluating the designs

b) The above-mentioned activities should be integrated with other system development activities, e.g., analysis, design, testing. c) The plan should identify the persons or organisations that are responsible for the Human-Centred Design activities and the range of skills and viewpoints that they provide. d) The plan should define the procedures for analysis of the results of the evaluation and feedback of the results to the design. The plan should also define how to document the iterative design. e) There should be milestones for the Human-Centred Design activities. f) The project time scale should allow for the feedback and for the possible design changes. It is especially important to ensure that there are evaluation activities during the early phases of the design.

4.2

Multi-disciplinary project team

4.2.1 Who do you need as actors The multi-disciplinary project team may include the following actors: q

technical experts


7


KEN


q

users or their representatives

q

application field experts

q

usability experts

q

visual designers

q

marketing experts

1.0 15.1.2001

The project plan has to define the teamwork between these actors. Each actor has his/her own role and responsibilities in the project. The nature of the project and the system to be developed determine which of the above actors are needed and how they should participate. When designing a tailored system for professional use, the future users play a substantial role. They are the only ones who know how things are currently organised and how a smooth transition to a new system could be organised. Often this requires re-design of the work organisation in parallel with the design of the new system. The design and evaluation methods should be selected so that they facilitate active user participation. In such projects, it is important to make sure that the actual users – not, e.g., only their managers - participate. However, it is important to include the points of view of both the users and the organisation in the design. When designing consumer products, or professional products for a wider market, you cannot communicate with all the actual users. In this case you have to select a representative group of users with whom the product can be designed and evaluated. When designing products for professional use, you also have to select a representative group of target organisations so as to incorporate the organisational point of view into the design. Integrated design means an approach to the design where the product and all supporting activities and materials are designed in the same design process. The supporting activities and materials may include manuals, training, maintenance, technical support, package, marketing and marketing materials, etc. In this kind of design you have to involve the appropriate actors in the design process: e.g., technical writers, trainers, maintenance people and marketing people. In the project plan, you need to reserve resources for q

Defining the context of use

q

Defining initial user requirements

q

Illustrating design decisions

q

Prototyping

q

Evaluating during analysis and design phase

q

Analysing the results of the evaluation

q

Redesign based on evaluation results

q

Field trials

Most activities require group work involving different experts. However, a named person should be responsible for the human-centred activities in the project. It is essential that the


8


KEN


1.0 15.1.2001

users and the designers participate together in most activities. Second-hand information is never the same as actually meeting the users and seeing how they cope with your system.

4.3

The design process

ISO standard ISO 13407:1999 Human-Centred Design processes for interactive systems, provides guidance on Human-Centred Design activities throughout the life cycle of computer-based interactive systems. The standard is targeted at people who manage design processes. According to ISO 13407:1999, Human-Centred Design consists of four different types of design activities: q

understand and specify the context of use

q

specify the user and organisational requirements

q

produce design solutions

q

evaluate design against requirements.

These design activities are carried out iteratively; i.e. there is likely to be more than one pass through the cycle as the design develops. This is because the process of producing design solutions and evaluating them with users tends to identify new requirements or to reveal the need for more information to be collected about the context of use. Figure 1 illustrates the design process.

Figure 1


Human-Centred Design process

9


KEN


1.0 15.1.2001

According to ISO 13407, a human-centred development project must specify the procedures used, the information collected and the use made of the results. The results of user involvement are most effective in the early phases of projects. That is why the HCD process emphasises the application of methods for the analysis of the context of use, user requirements definition and design requirements analysis. User requirements cannot be fixed at the beginning of the project; rather the project must be prepared to refine user requirements throughout the design process. New ideas during the development should be registered even if the project does not plan to implement them at that moment. Information on the origin of each requirement and how the project decided to handle it must be documented. If the requirement was rejected, the project must record why. The usability activities in the design process include: 1. Define the context of use 2. Define user requirements 3. Visualise and evaluate design decisions in the design requirements phase 4. Prototype during the design phase and evaluate with the users 5. Organise field trials in the end Expert evaluation as well as laboratory trials should always precede the field trials. In the laboratory trials the main usability problems can be identified and they can be solved before the field trials. In this way, the field trials can focus on collecting feedback that only can be obtained in the field, e.g., the usability, utility and user acceptance of the system in real and continuous use.

5

How to define the context of use

Defining the context of use is the starting point of an iterative Human-Centred Design process. According to ISO standard 9241-11:1999, context of use consists of users, tasks, equipment and the physical and social environments in which a product is used. This information, together with a review of the current processes and a review of similar systems or products on the market (if available), is used to identify an initial statement of requirements. At the end of this stage, a list of design ideas or a design concept can be produced and evaluated by the intended users. If the ideas or the concept are acceptable, then the design process can move to the next stage of specifying user and organisational requirements in more detail. The description of the context of use generated during this phase of the design process should: q

specify the users, tasks and environments in sufficient details to support design


10


KEN


1.0 15.1.2001

q

be confirmed by the users or their representatives

q

be adequately documented

q

be made available to the design team

q

be a working document, which will be updated throughout the design process

In order to collect information about the context of use, it is first necessary to create a project summary, which describes the goals and scope of the project. It is best to describe a project in terms of a ‘problem’ in need of a solution; a Human-Centred Design process will then determine the exact solution. This approach has a better chance of achieving a successful outcome than one which begins with pre-conceived solutions. Once you have outlined the project in this way, describing the problems that need to be solved, you can begin to define the context of use of the product, system or service that the project might deliver. The context of use includes the characteristics of users, tasks and environment which are likely to have an impact on the design. During the iterative design process, the context of use can be refined. For instance, new user groups can be identified or the characteristics of the present user groups can be refined. Often in the evaluation stage the users will identify new tasks that they would like to perform with the system. These new features may again generate new user groups or changes to the planned physical or social environment.

5.1 Methods for understanding the context of use You cannot figure out what people want, need, can do and will do without talking to them yourself. You cannot rely on descriptive data. Even if a description of the users is as complete as possible, it is not a substitute for direct interaction. In the project team, it is essential that the designers have direct contact with the users. The usability experts in the design team facilitate the communication between users and designers, but cannot take care of the communication on behalf of the designers. Direct contact helps to reduce the often-mentioned problem that the users and the designers do not speak the same language. You may not have any idea about what you would like to know about the users until you meet them personally in their own environment. The following methods are different and often complementary ways of collecting information about aspects of the context of use.

5.1.1 Interviews Interviewing is still the most widely used method of learning about the users and what they want. There are 3 types of interviews: unstructured interviews, semi-structured interviews and structured interviews. The type, detail and validity of data gathered vary with the type of interview and the experience of the interviewer. Interviews can be used in all phases of the design process: context of use analysis, definition of user requirements and evaluation at different phases. Unstructured interviewing is characterised by an unconstrained attitude to the agenda and is a technique that can be conducted in practically any human endeavour.


11


KEN


1.0 15.1.2001

Semi-structured interviewing is useful in situations where broad issues may be understood, but the range of respondents' reactions to these issues is not known or suspected to be incomplete. Structured interviewing should only be carried out in situations where the respondents' range of replies is already well known and there is a need to measure the strength of each shade of opinion (Maguire, 1998; Preece et al., 1994). 5.1.2 Observation Observational methods involve an investigator viewing users as they work and taking notes on the activities that take place. Observation may be either direct, where the investigator is actually present during the task, or indirect, where the task is viewed by some other means such as video. Observation is useful for studying currently executed tasks and processes, and is commonly used for that purpose (Maguire, 1998).

5.1.3 Surveys A survey involves administering standard questionnaires to a large sample population. Surveys can help determine customer preferences, work practice, attitudes, etc. There are two types of questionnaires: closed, where the respondent is asked to select from available responses, and open, where the respondent is free to answer as he/she wishes. Surveys can be used at the early phases of the evaluation process to collect information on the context of use, user requirements or user attitude to previous products. Open surveys are applicable in the same kinds of situations as semi-structured interviews, closed surveys as structured interviews. Interviews are preferable in situations where there is a lot of person-power available and the user group is easily accessible. Surveys should be used, by preference, in situations where the user group is spread out geographically or where resources are limited. Unless the user group is especially motivated, response rates of 20% or less are typical. Before a survey, it is often useful to have an interview with a smaller group of users. If the context of use is new to you, this might be the only way to know which questions to ask in the survey (Gould, 1995). 5.1.4 Diary Methods Diary methods require the informants to record their daily activities. The structure of the diary may vary. It can be unstructured, which means that the informant writes in his/her own words. Highly structured questionnaires with check-boxes can also be used. The diary can simply be kept with paper and pencil. Tape and video diaries or computerised on-line questionnaires can also be used. The diary methods can be used during the initial phases of design to provide a picture of the activities the user group is engaged in. The frequency, duration and difficulty of performing tasks can be recorded. It helps in understanding what the users' difficulties are


12


KEN


1.0 15.1.2001

and where a technical aid needs to be introduced. The methods can also be used to collect information during a field trial (Kirakowski & Korbett, 1990).

5.1.5 Ethnographic Approach In the ethnographic approach, the investigator takes part as an active member of the group of users involved in the situation. The approach provides a descriptive report, utilising mainly informal interviews and observation. The approach can be used in situations where the subject domain is unclear/unfamiliar to the team or where context of work may be expected to have a significant effect on system use (Whiside et al., 1988).

5.1.6 Contextual Inquiry Contextual Inquiry is a variation of the Ethnographic Approach. It is also based on ethnography and the sociological research tradition where the researcher/observer visits the users’ own environment, rather than vice versa. The observer not only observes the user but also asks questions about events that are not obvious as such. Work products like data sheets and notes can also be collected for later reference. The observation session can be videotaped for later reference. This method can be used for task analysis and especially to gain fresh insights and to create a basis for design ideas (Beyer and Holtzblatt, 1998).

5.1.7 Task Analysis Task analysis covers different sub-methods, e.g., focus groups, surveys, interviews, observations and diaries to collect information. Task analysis can be defined as the study of what a user is required to do, in terms of actions and/or cognitive processes, to achieve a certain goal. Task analysis is best suited to situations where you have a well-defined user group with well-defined tasks. Usually such contexts are working places where different groups of employees have well-defined responsibilities. Task analysis has classically been used in areas where the users' actions at the computer can be defined in terms of specific goals. For situations where the users' interest is likely to be unfocused, such as browsing or searching, task analysis may still be useful, but yields less tangible results (Kirwan and Ainsworth, 1992).

5.2 How to define the intended context of use Once you have become familiar with the current context of use, you have to define the intended context of use for the new product. You have to define the users, their tasks and the environment.


13


KEN


1.0 15.1.2001

The characteristics of the intended users which should be defined include knowledge, skills, experience, education, training, physical attributes, habits, preferences, and capabilities. If the users have different roles, these should also be described (e.g., purchaser, secretary, financial manager, inventory personnel, ...). It is important to ensure that the intended users are the real users, not, e.g., their managers. However, in the context of use there are also organisational issues, which the managers may know better than the actual users. That is why you usually have to involve both these actors. If there are many user groups involved, it is also important to study how their contexts of use are connected to each other (Gould, 1995). The description of the user tasks should describe the tasks, the goals of the user, the frequency of the tasks and their importance to the users. If there are different user groups, the task descriptions should be connected to the appropriate user groups. At this phase of the design process you should keep in mind that you should describe user tasks, not functions of the system to be designed. However, the task descriptions can give initial ideas about which parts of the tasks could be allocated to the technology to be designed. The current processes for achieving user goals should also be reviewed, and any problems documented. It is also useful in this stage to review existing systems and products which are aimed at meeting the same user/task goals, to identify good features which could be incorporated into a new system or bad features which should be avoided. The environment description defines the other systems (hardware, software, networks) which affect the use of the planned system. This description also defines the physical environment (home, office, car), the legislative environment (laws and directives), and the social and cultural environment (organisational structure, work practises, target cultures, etc.)

5.3 Context of use in personal navigation According to the report of Navikärki project (Petäkoski-Hult et al., 2000), the most important design decision to be made is: At whom are the development work and the results to be targeted? You have to identify the main user groups desired for the new product. Also the cultural factors and the user interests must be taken into account. A new product will be wanted if it meets the cultural and functional needs of the user. You should consider which groups could lead the adoption of new products and possibilities. On the basis of this analysis you can identify so-called lead-users who might be the first to accept and use the new solution or application. Annex 1 (In Finnish) presents the prediction of Navikärki project for the phases in which personal navigation products may spread out to different contexts of use. The Annex also presents the prediction of Navikärki project for potential user segments and their characteristics.

6

How to define user requirements

Only after you know who the users will be and what kind of context of use they will have, can you start defining the user requirements. User and organisational requirements specify the system requirements from the users’ point of view. These requirements will


14


KEN


1.0 15.1.2001

include the functions required to support the user tasks, the user-system interfaces, user needs for support, physical and organisational requirements, equipment and hardware. They also include usability goals that must be achieved and the approach for installing the system. In consumer products there are no organisational requirements but there may be other actors whose requirements should be taken into account, e.g. service providers. In Human-Centred Design the user and organisational requirements should:

q

define the range of relevant users

q

set Human-Centred Design goals

q

define priorities of the different requirements

q

provide measurable usability criteria

q

be confirmed by the users or their representatives

q

include statutory or legislative requirements

q

be adequately documented

q

be a working document, which will be updated throughout the design process

User requirements are defined in co-operation with, e.g., technical experts, application field experts, users, representatives of user organisations, service providers and usability experts. Initial user requirements are refined throughout the design process on the basis of continuous feedback from the users. User requirements cannot all be fixed at the beginning of a project. You have to be prepared to identify new requirements and to refine or reject existing ones throughout the design process.

6.1 Relationship to traditional requirements analysis Traditional approaches to requirements engineering concentrate on identifying functional requirements and validating that the developed product meets these requirements. Other non-functional requirements (e.g. efficiency, reliability, usability, maintainability and portability) have had less importance. Yet from the user’s perspective, non-functional requirements may be critical to successful implementation of a new system. A humancentred approach emphasises the importance of obtaining a complete understanding of users’ needs and of validating the emerging requirements against potential scenarios of usage. Existing requirements engineering methods and tools can be used within this framework to document and trace the detailed requirements through the development process. The user-centred methods will help to identify and prioritise requirements from the user’s perspective. In addition to user and organisational requirements, there will be business and technical requirements for the system, which will be identified and developed in parallel with the user and organisational requirements.


15


KEN

6.2


1.0 15.1.2001

Points of view in user requirements

When defining the user requirements, the end-users are often not the only actors whose requirements should be taken into account. In addition to the actual end-users you may have to take into account the points of view of the user organisation, the service providers and society as a whole. You also have to consider the possibilities and limitations of the technology that will be developed and/or utilised.

Mobile user

utility, usability, safety

Technology

Service providers

easy maintenance, compatibility, reliability, pricing legislation, control, ethical issues possibilities and limitations of the technology

Society

Figure 2

Points of view in defining user requirements for a consumer service

6.3 Methods for early design Once the context-of-use information has been collected, the design team can develop one or more ideas (or system concepts) for the new system. It is desirable to develop and compare several concepts. The most feasible concepts are then taken forward as part of the user requirements specification. The following techniques are useful for this type of early design concept generation.

6.3.1 Focus Groups A focus group brings together a cross-section of interested parties in an informal discussion group format. The group should include users or their representatives. A facilitator elicits views on relevant topics. Meetings can be recorded for later analysis. Focus groups are useful early in the user requirements specification. They help to identify


16


KEN


1.0 15.1.2001

issues which may need to be tackled, and provide a multi-faceted perspective on them (Maguire, 1998).

6.3.2 Group Discussions/ Future Workshops Group discussions help to summarise the ideas and information held by individual members. The group should include both designers and users or their representatives. New ideas, design options, costs and benefits, screen layouts, etc. are discussed within the design process. By discussion, a collective view is established from the individual parts. The 'future workshops' concept is designed specifically to allow all members to participate in the discussion. A future workshop goes through three phases: Critique: the participants voice current problems in a constructive manner; Fantasy: the participants generate visions of the ideal future scenario; Implementation: the `visions' are evaluated and a plan for future action is formulated. Group Discussion/ Future Workshops are useful for obtaining opinions from a range of people who may not feel secure about voicing their opinions (Maguire, 1998). 6.3.3 Brainstorming Brainstorming is one of several group approaches. The idea is to let people come together and inspire each other in the creative, idea generation phase of the problem-solving process. The method is used to generate new ideas by opening the mind to any idea that is suggested, allowing freedom for creativity. Brainstorming is used for rapid generation of ideas or identification of problems in a specific domain, and is focused on the quantity of the responses. Clustering methods may be used to enhance the outcome of a group session. Brainstorming is typically used early in the development phase when little of the actual design is known, and there is a need for new ideas (Maguire, 1998). 6.3.4 Scenario Building Scenario building aims to predict future situations. That is why it is well suited to the design of new product concepts and to the design of consumer products, where the context of use may vary a lot. It is easier to build scenarios in a group of people. That is why group methods, e.g., brainstorming, group discussions and focus groups are well suited to scenario building. The group should include people with different expertise, e.g. designers, end-users, application field experts, marketing people and usability experts. Scenario building is a good way to generate design ideas for new products and to identify the possible users and contexts of use for the product to be designed. Scenarios can be used to illustrate early design suggestions (Carrol, 1995).


17


KEN


1.0 15.1.2001

6.3.5 Literature study Useful sources of information are available usability studies and market surveys. The user requirements definition should analyse what has already been found out and what kind of user requirements can be identified on the basis of previous studies. This is not a primary way to define user requirements, but it is a good starting point. 6.3.6 Evaluation of previous products Sometimes a good source of information for user requirements is the evaluation of previous products. By studying how people deal with these products you can identify problems with current solutions, needs for new features and ideas for further development. The evaluation can be made as a normal user evaluation. The methods should be chosen according to the type of the product and/or available resources and time.

6.4

Methods for defining user requirements

User requirements should be defined in co-operation with technical experts, application field experts, users, representatives of user organisations, service providers and usability experts. Initial user requirements are refined throughout the design process on the basis of continuous feedback from the users about the proposed design as it develops. The best way to collect feedback from users is to build up the user requirements specification and to review it is through the group work of different actors (e.g. designers, users and usability experts). Many of the methods used for understanding and specifying the context of use can also be applied when analysing user requirements. It is important to find ways of representing the emerging design to the users as early as possible, so that they can evaluate it and, if necessary, refine their requirements. Techniques such as use cases, scenario building, storyboarding and prototyping all help users to envisage how the design will look and what the product or system will be like to use. Techniques such as the functionality matrix and task allocation charting help to explore and identify different options for system functions and the way in which tasks are allocated between the users and the system. 6.4.1 Task Allocation Charts This method defines the allocation of tasks between the system and the user. A range of task allocation options is established between different users and the system to be developed. The allocation is used to identify the optimal division of labour between the user and the system. The optimal division is expected to provide satisfying and efficient operation of the whole work process. Using task allocation charts is most useful for systems, which affect whole work processes rather than single user, single task products. (Ip, Damodaran, Olphert, and Maguire, 1990). 6.4.2 Functionality Matrix This is a way of specifying which functions different users or user groups will need. Identifying which tasks are critical allows more time to be paid to these important tasks


18


KEN


1.0 15.1.2001

during design and usability evaluation. The method progresses by identifying user groups, tasks, critical and occasional functions and entering them into matrix rows. The method is applicable mainly to systems where tasks are well defined (Catterall et al., 1990). 6.4.3 Evaluation results of the previous iteration cycles User requirements as well as the intended context of use should be updated throughout the design process by analysing the evaluation results of previous iteration cycles in the Human-Centred Design.

6.5 Building an iterative specification of user requirements The information collected during the previous stage of the Human-Centred Design process (defining the context of use) will be the starting point for the specification of user requirements. The information should be analysed to identify potential requirements that arise from the different aspects of the context of use, i.e., the users themselves, the tasks and the environment. The requirements that emerge from this analysis will fall into a number of different categories (Kaasinen et. al., 2000):


19


KEN


1.0 15.1.2001

REQUIREMENT CATEGORIES

EXAMPLES

General system characteristics (not functions)

these may describe, for example, the appearance of the system, the price of the system, performance requirements, customisation or flexibility features, etc.

The organisational structure and work or job design requirements

e.g. new roles that might be created, new responsibilities added to existing jobs, etc.

Job design requirements

responsibilities added to existing jobs, etc.

The technical environment of the system

such as the general characteristics of the software (e.g. Windows 98), characteristics of the hardware (e.g. touch screen input, hands-free telephone) and ancillary equipment that will be used alongside the system (e.g. printers, scanners, speakers, etc.)

System functions and features

e.g. the need for user identification/validation through PIN, the need for different modes of operation for users with different levels of expertise

User interface design requirements

e.g. methods of interaction, standards to be used, tools to be used for building the interface, etc.

User support requirements

e.g. training needs, documentation, access to ‘experts’, helpdesks, etc.

Physical environment requirements

e.g. location (where the system will be used), space and furniture needed to use the system comfortably, health and safety hazards, etc.

Social and organisational environment requirements

e.g. organisational structure and culture, team working, job functions, organisational policies which must be complied with, needs and policies of service providers, etc.

Standards and style guides to apply

e.g. ISO 9241, internal standards or style guides, etc.

Table 1

Categories of user requirements

This will produce a series of potential user requirements that should be considered as a basis for agreed user requirements and which will form the basis of the user and organisational requirements specification. The requirements should be reviewed by the design team and users. The following activities should be carried out: - duplicate requirements should be removed - unnecessary or superseded requirements should be removed - new requirements arising should be added The remaining requirements can be prioritised and areas of constraint and flexibility noted. It is useful if you can define measurable targets for the usability of the system at this phase. The targets could be, e.g., "70 % of the intended users are able to carry out the task of locating themselves in 2 minutes without guidance." Or "on average, users should call the help hotline less than once a day during the first week of using the system." These targets could be based, e.g., on user evaluation of the previous system and planned improvements to it. The metrics give a clear idea of the progress that has been made in the iterative design and what is still required. It is also useful to set up a process for monitoring progress in achieving requirements.


20


KEN


1.0 15.1.2001

Once the requirements have been carefully reviewed in this way, they should be written up as a draft User Requirements Specification document. Representatives of the development team should then review this document with users in order to check or validate the user requirements. 6.5.1 Prioritisation The user requirements can be prioritised in order to decide which ones the design must absolutely satisfy and which ones are less critical. This process should involve all the key actors, i.e. end-users, marketing and industry personnel, managers, usability experts and technical designers. The rating team should consider the requirements one at a time and assign a priority to each requirement. For example, a rating scale of 1 to 5 can be used, where 1 is ‘critical’ or ‘vitally important’ and 5 is ‘unimportant’. (If a rating as low as 5 is actually assigned to a requirement, you should consider whether it can be deleted to simplify the specification.) Some aspects of the design, for instance the hardware to be used, may be fixed in advance and cannot be changed by the design process. These items should be included in the requirements specification but marked as constraints on design. Other requirements may be flexible in the design, e.g., the labelling and colour of keys. These items should also be labelled to show that they are flexible. For more details about prioritising requirements, see the Quality Functional Definition (QFD) process (Fehin, 1997).

6.5.2 Requirements achievement Progress in achieving the user requirements as the design progresses can be monitored at the meetings of the design team. Progress in achieving a requirement can be estimated using a 3-point scale, where 1 = some progress, 2 = considerable progress and 3 = the requirement has been fully achieved. If no progress is achieved, no rating is assigned. If this approach is followed, it is possible to estimate the current level of progress in achieving the user requirements by means of the following calculation: Sum of [each priority assignment (1-5) * progress level (1-3) ] _________________________________________________ Sum of [each priority assignment (1-5) * 3 ]

This value will be a proportion, which can then be converted into a percentage by multiplying it by 100. Thus if each requirement is fully met (progress level 3) the current achievement level will be 100%. However, in practice not all requirements will be fully met, and the design team will be looking to achieve the highest percentage possible. In deciding what percentage is acceptable it maybe stated that, for instance, all requirements with a rating of 3 or more must be fully met.


21


KEN


1.0 15.1.2001

6.6 User requirements for personal navigation The Navikärki project classified the general quality factors for usability of personal navigation into three categories, namely technology, user interface and information content (Petäkoski-Hult et al., 2000). Factors related to technology may include • Overall reliability • Accuracy, speed and functionality of location information • Speed and reliability of telecommunications connection • Data security and data privacy (as recognition and encryption completeness) • Resolution and contrast of the display • Power consumption; duration of battery vs. weight of the device Factors related to the user interface may include • Efficiency • Effectiveness • Satisfaction • Learnability and comprehensibility of the information • Multimodality • Scaling, adaptation and personalisation • Functionality in emergency situations Factors related to information content may include • Accuracy, topicality and phenomenality • Personalisation • Scaling and adaptation according to the context of use (user, task, environment) The total quality of the product or service is also affected by the comprehensibility and clarity of instructions as well as the availability and service level of the technical support. In complicated service architectures, the responsibility for quality issues can be unclear. Most often the partner closest to the customer has the best knowledge of total quality and the possible weaknesses of the product (Petäkoski-Hult et al., 2000). The Navikärki project also identified a draft list of the characteristics of a personal navigator. These factors should be considered in the design (Petäkoski-Hult et al., 2000). 1. Cover, enclosure • Pocket size, as small as possible • Durable: shock- and water-resistant, resistant to extreme temperatures • Easy to find and identify as own • Antitheft secure: separate modules, antitheft alarm system, easy to modify, not tempting at tourists sites • Modifiability (everyday use/special occasions, work/leisure) • Comfortable even in long continuous use • Ergonomically well designed and manufactured • senses: vision, hearing, sense of touch • anthoropometric attributes, individual characteristics • People with special needs, e.g., children and elderly - difficult to lose and forget, yachters - floating


22


KEN


1.0 15.1.2001

2. Keyboard/input device • Difficult to lose especially if it includes separate parts • Usable even in bad visibility and at night • Easy and fast to take into use and use • Modifiability of the input device: (children, elderly, disabled, sensory disabled, using with gloves), possibility to use with one hand • Restrictions of use while driving a car 3. Location information • All the information needed in the respective context of use should be available: Location, routes, distances, services, etc. • Easy to zoom in/out and choose which level of detail is visible • Adaptive to the location of the user • Good graphics, full-colour display, 3D • Indoor navigation 4. Desirable add-ons for personal mobile navigator • Flashlight • Calculator • Dictionary with common phrases • Games • Exchange rates • Clock • Recognition of a person with a special profile (date services) • Emergency call (automatic/button/voice signal)

7

How to illustrate the design

Illustrating the potential design solutions in the early phases of the design allows the designers to communicate more effectively with the users and reduces the need for and costs of reworking later on. The potential design solutions can be based on the established state of the art as well as the experience and knowledge of the project participants. The established state of the art includes scientific knowledge of ergonomics, psychology, cognitive science, product design and other relevant disciplines. User interface style guides, knowledge of previous products and marketing knowledge can be used to support the initial design. Generic human factors and ergonomic design guidelines and standards should also be used. The benefits of early, concrete illustrations include: q

Design decisions become more explicit and easier to comment on

q

Designers can explore several design concepts before selecting one

q

User feedback can be gathered early in the design

q

Several iterations of a design can be evaluated and alternative designs compared

q

Illustrations help in evaluating and completing the functional specification


23


KEN


1.0 15.1.2001

To obtain maximum benefits, it is best to carry out several iterations with the users during different phases of the project. User comments and usability problems identified in the evaluation of the prototypes should be analysed in the project group. The findings may indicate changes to the planned context of use, new user requirements that were not identified before, new functional requirements or implementation requirements. Depending on the results, the iterative design process allows refinement of the definitions of the context of use, of user requirements, of system requirements or of the design. The identified needs for changes should be documented and the appropriate design documents updated accordingly.

7.1 Use cases Use cases were originally defined as a part of object-oriented software engineering. They describe a "black box view" of a system. The use cases of a system describe all the different ways that the users can interact with the system. The use cases are the highest level of the object model of the system. In use cases the environment of the system is defined by describing different users, who represent different user groups. The representatives of the user groups are called actors. An actor can also be another system that will be connected to the system to be designed. The actors use the system through a number of use cases. The use case model of a system is an external view of the system. The object model is an internal view of the same system. Use cases form a model of the whole structure of the system. A complete object model of a system is seen through a set of object model views — one per each use case. Use cases are defined during the user requirements definition phase of the design process. They simplify the traceability between different object models. Later on in the design process, use cases can be used in evaluations to ensure that the planned functionality has been implemented. Use cases should be updated throughout the iterative design process (Jacobson, 1995).

7.2 Scenarios Scenarios embody information about the environment, the user and the planned system in relation to real-world tasks. They reflect the complexity of the real-world human interaction by describing other objects and activities around the usage situation, e.g. the social settings, resources and goals of the users. A scenario is not a narrowly focused task description but provides " a bigger picture" about how some particular tasks are performed. Scenarios resemble use cases but they describe instances of the usage situations, describing a fictitious user, user aim and environment. On the one hand, a scenario is broader than a use case; it describes not only the user and the system acting together but also what is and what happens around them. On the other hand, a scenario is narrower than a use case; it describes an individual user in a certain usage situation. Because scenarios describe individual users in individual usage situations, scenarios cannot be


24


KEN


1.0 15.1.2001

used to describe the whole functionality of a system. Use cases are treated more formally. They can and should be used to make a model of the system as a whole. The value of scenarios is that they concretise something for the purpose of analysis and communication. The concreteness enables designers and users to deal with complicated and rich situations and behaviours in meaningful terms, and to understand better the implications of particular design solutions for performing realistic tasks (Carrol, 1995). Scenarios can be used to: q

describe problems to be solved

q

catalyse interaction within a design team, thus improving team-building

q

facilitate user involvement in the early design

q

support collaborative design where all the participants don't need to know the technology

q

help in transferring and explaining design ideas

7.3 Storyboarding / Presentation Scenarios Storyboards are sequences of images, which demonstrate the relationship between individual screens and actions within a system. A typical storyboard contains a number of images depicting features such as menus, dialogue boxes and windows. A sequence of these screen representations conveys further information on the structure, functionality and navigation options available within an intended system. The storyboard can be shown to colleagues in a design team and to potential users. This allows others to offer critical feedback about the composition and scope of the intended interface. Storyboarding can be used early in the design cycle, in which case it supports the exploration of design possibilities and the early verification of user requirements. The method is of general relevance, especially to products in which a complex structure of information is being developed (Androile, 1991).

7.4

Mock-ups and prototypes

A prototype is a representation of all or a part of a product or system that, although limited in some way, can be used for evaluation (ISO 13407:1999). In the HumanCentred Design approach, prototypes are not simply demonstrations to show users a preview of the design, but they are developed to collect user feedback that is then used to drive the design process. A prototype can be as simple as a pencil and paper sketch or as complex as a computer-based simulation. A mock-up is a simple prototype. Usually it is a paper-based sketch of the planned system, but it can also be a simple software illustration. It can, for instance, be a collection of sketched screen views. Mock-ups of hardware products are threedimensional models constructed of simple materials. Simple prototypes are valuable in the early stages of design to explore alternative solutions. They should be kept simple enough and not too much design effort should be devoted to them. In this way it is easier for both the users and the designers to assess them


25


KEN


1.0 15.1.2001

freely. If the prototype looks too "finished", the users often tend to be too polite to criticise it, and the developers have invested too much effort to discard the prototype readily. In software design, prototyping typically starts with screen-view mock-ups and continues with simple prototypes which support only a subset of user tasks. Successive prototypes illustrate the implementation of support for various user tasks. The prototypes are updated on the basis of user feedback and are combined to cover more functionality. The first prototypes can be evaluated in design walkthroughs. Functional prototypes can be evaluated in user trials under laboratory conditions. Later on, the trials can be done in more realistic contexts.

7.5 Card Sorting Card sorting is a common usability technique that is often used to discover users' mental model of an information space. A typical application of card sorting is to get ideas for menu structures by asking users to sort cards with the command names: commands that get sorted together often should probably be in the same menu. A limitation of the method is that users may not always have optimal models. Card sorting (or other similarity measures) is often used to assess the difference between the way novice and expert users understand a system. A typical Card Sorting session proceeds in the following way: q

One note card is prepared for each concept in the application. The concepts are found beforehand, e.g., by performing a task analysis and interviewing users.

q

Each note card is given to a user in a random order.

q

The user sorts the cards on the basis of similarity. The user does not get any detailed instructions, but rather is just told to put the cards into piles that she/he thinks are similar.

q

The user then groups the piles into larger groups. This could continue until a tree hierarchy is established, but can be stopped at a certain level.

q

The user names the groups, e.g., using post-it notes. The verbal disagreement phenomenon (i.e. different people call the same thing by different names) is a great way to get suggestions for topic names.

One user participates in the test at a time. The evaluator should answer any questions asked by the user with another question (Never answer questions in user-testing.) (Nielsen and Sano, 1994).

7.6 Icon Intuitiveness Testing It is often useful to test the intuitiveness of the planned icons in the system by showing the user an icon/picture and asking what image/response it evokes in him/her. Graphics need to communicate value -- not just pictures. It is often useful to test the icons in isolation. The test is simple and by testing the icons first, usability problems related to incomprehensible icons can be avoided in later phases of the design (Nielsen and Sano, 1994).


26


KEN

7.7


1.0 15.1.2001

Paper Prototyping

This method features a paper-based simulation of an interface or system. Paper prototypes provide a valuable and cost-effective means of evaluating and iterating design options before deciding on one implementation. Interface elements such as menus, windows, dialogues and icons can be sketched on paper or created in advance using card, acetate, pens, etc. The result is sometimes referred to as a low-fidelity prototype. After the paper prototype has been prepared, a member of the design team sits in front of a user and plays the part of the computer by moving interface elements around in response to the user's actions. The user makes selections and activates interface elements, e.g., by using his/her finger as a pointing device and speaking out 'typed' input. Another person provides task instructions and encourages the user to express his/her thoughts and impressions. An observer may make notes and/or the session can be recorded on video for later analysis. The method is most suitable in contexts where it is easy to simulate system behaviour or when the evaluation of detailed screen elements is not required. Paper prototyping is appropriate for the early stages of the design cycle, where changes can be readily made before there is a commitment to one implementation.

7.8 Wizard of Oz Prototyping This approach involves a user interacting with a computer system, which is actually operated by a hidden developer - referred to as the "wizard". The wizard processes input from a user and simulates system output. During this process the user is led to believe that she/he is interacting directly with the system. This form of prototyping is beneficial early on in the design cycle and provides a means of studying a user's expectations and requirements. The approach is particularly well suited to exploring design possibilities in systems which are demanding to implement. The approach is highly applicable to "intelligent interfaces" which feature agents, advisors and/or natural language processing (Maudsley, Greenberg & Mander, 1993).

7.9

Video Prototyping

This method allows designers to create a video-based simulation of interface functionality by using simple materials and equipment. Interface elements are created using paper, pens, acetates, etc. For example, a start state for the interface is recorded using a standard video camera. Stopping and starting the camera as interface elements are moved, taken away and added may then simulate the movements of the mouse pointer over menus. Users do not interact with the prototype directly although they can view and comment on the completed video-based simulation. Video prototyping is particularly well suited to simulating interface functionality. A limitation of the method is that it must be possible to easily simulate the interface elements with basic materials. The method is relevant in the early stages of the design cycle to demonstrate design options and concepts (Vertelney, 1989).


27


KEN


1.0 15.1.2001

7.10 Rapid Prototyping This method is concerned with developing different proposed concepts by evaluating software or hardware prototypes. The development of a simulation or prototype of the future system can be very helpful. It allows users to get an idea of the look and feel of the system and provide feedback on it. Thus it can be used to clarify user requirements options. Rapid prototyping is described as a computer-based method which aims to reduce the iterative development cycle. Interactive, quickly replaceable prototypes are developed in line with design feedback. This feedback may be derived from colleagues or users as they carry out set tasks with the prototype. The prototypes exhibit a higher resemblance to the end product than in methods such as paper prototyping. The method requires more technical resources than prototyping methods which rely on paper materials. An additional cost is the human expertise required to master the development tools, along with the time necessary to implement a software prototype.

7.11 Information Presentation in Personal Navigation Table 2 illustrates some common views of personal navigation (Petäkoski-Hult et al., 2000).


28


KEN


Type of view

1.0 15.1.2001

Example

Geographical view. Possibilities Map 3D-map (3D-environment) Photo or video compared to digital elements

View corresponding perceptions

visual

As a user would see it himself if he went to the place. Different photos

Context view What is close to me? What are those? What do they want to tell me? What can I do to those?


This is a statue

29


KEN


Type of view

1.0 15.1.2001

Example

Route view: how can I reach location B? (From location A or from the current location)

B A

Logistic view – abstract route model map of the underground lines, for example No distances or specific directions, the only information that matters are the intermediate and final points Geographical information view Characteristics of the objects and sites on the map.

A

X

B zzzzz zzzzz zzz zzzzzz zzzz zzzzzz zzzzz zzzzzz zzzz

zzzzz zzzzz zzz zzzzzz zzzz zzzzzz zzzzz zzzzzz zzzz

Guidance view What needs to be done next? > > How? When? Output as picture, text or voice signal or even haptical impulses Status view > Also as part of the other views Output as picture, text or voice > > signal or even haptical impulses

Table 2

Next turn to the right < Current speed limit 80 km/h