PRINCIPLES OF HUMAN-COMPUTER INTERFACE

DR NOORMAIZATUL AKMAR ISHAKSCHOOL OF HUMAN DEVELOPMENT AND

TECHNOCOMMUNICATION (iKOM)

1

PART 2: DESIGN PROCESS

CHAPTER 3INTERACTION DESIGN BASICS AND

SOFTWARE PROCESS

DR NOORMAIZATUL AKMAR ISHAKSCHOOL OF HUMAN DEVELOPMENT AND

TECHNOCOMMUNICATION (iKOM)

2

CONTENT

3.1 What is design?

3.2 The process of design

3.3 User focus

3.4 Scenarios

3.5 Navigation design

3.6 Screen design and layout

3.7 Interaction and prototyping

3.8 The software life cycle

3.9 Usability engineering

3.10 Iterative design and prototyping

3.11 Design rationale3

INTERACTION DESIGN BASICS

4

INTRODUCTION

• A large part of HCI is about doing things and making things – design.

• The product of a design exercise is that we intervene to change the situation as it is for betterment.

• Design is never perfect first time (or ever), thus most interaction design involves several cycles of prototyping and evaluation.

5

WHAT IS DESIGN?

• Design is achieving goals within constraints.

• Goals– What is the purpose of the design we are intending to produce? Who

is it for? Why do they want it?

• Constraints– What materials must we use? What standards must we adopt? How

much can it cost? How much time do we have to develop it? Are there health and safety issues? Does it have to withstand rain? Must we use existing video standards to download movies? Do we need to build in copyright protection?

• Trade-off – Choosing which goals or constraints can be relaxed so others can be

met.

6

THE GOLDEN RULE OF DESIGN• For Human-Computer Interaction the obvious

materials are the human and the computer.

• Thus, we must:

– Understand computers – limitations, capacities, tools, platforms

– Understand people – psychological, social aspects, human error

7

TO ERR IS HUMAN

• People make mistakes.

• This is not ‘human error’ – an excuse to hide behind in accident reports – it is human nature.

• Therefore, systems should be designed to reduce the likelihood of those mistakes and to minimize the consequences when mistakes happen.

• If you design using a physical material:– Understand how and where failures would occur and strengthen the

construction

– Build in safety features or redundancy

– Understand the way human failures occur and build the rest of the interface accordingly.

8

THE CENTRAL MESSAGE – THE USER

• HCI focuses on basic psychology, technology, methods and models.

• However, it takes human attitudes to make it successes –not how good the HCI is.

• The core of interaction design

– Put the user first,

– Keep the user in the centre,

– Remember the user at the end.

9

THE PROCESS OF DESIGN

Process Explanation

Requirements Establish what exactly is needed. Technique in HCI – interview people, looking at the documents and objects that they work with.

Analysis Results from observation and interview bring out the key issues. Use for later stages of design.

Design Central stage from what we want to how to do it. Numerous rules, guidelines and design principles can be used to help.

Iteration and Prototyping

To evaluate a design to see how well it is working and where to improve. Most user interface design involves some form of prototyping, producing early versions of systems to try out with real users.

Implementation and deployment

When happy with the design, we need to create it and deploy it. It involves writing code, making hardware, writing documentation and manual.

10

INTERACTION DESIGN PROCESS

What is wanted?

• Interviews ethnography

• What is there vswhat is wanted

Analysis

• Scenarios task analysis

Design

• Guidelines principles

Implement and deploy

• Architectures documentation help

11

Prototype

Evaluation

Heuristics

Precise

specification

Dialog notations

USER FOCUS

• Know your user.

• Who are they? – demographic issues.

• Probably not like you – ability and interests.

• Talk to them – get their trusts, inside story.

• Watch them – how and why they do.

• Use your imagination – use persona. A persona is a rich picture of an imaginary person who represents our core user group

12

SCENARIOS• Scenarios are a resource that can be :

– used and reused throughout the design process,

– helping us see what is wanted,

– Suggesting how users will deal with the potential design,

– Checking the proposed implementation will work

– Generating test cases for final evaluation.

• Communication with others designers, clients and users.

• Validate other models – task models, or dialogue and navigation models.

• Express dynamics – how system looks and behaves.

• Time is linear – we are natural storytellers and story listeners.

• But no alternatives – real interactions have choices but not the HCI systems.

13

NAVIGATION DESIGN

• Consider most tangible outputs of design.

PC Application Website Physical Devices

Widgets Form elements, tags and links

Buttons, dials, lights, displays

Screen design Page design Physical layout

Navigation design Site structure Main models of device

Other applications and operating

systems

The web, browser,external links

Swap between application, cut and

paste

14

LOCAL STRUCTURE

• Issue : Looking from one screen or page out.

• Much of interaction involves goal-seeking behaviour.

• Each state of the system or each screen needs to give the user enough knowledge of what to do to get closer to their goal.

– Knowing where you are

– Knowing what you can do

– Knowing where you are going – or what will happen

– Knowing where you’ve been – or what you’ve done

15

GLOBAL STRUCTURE – HIERARCHICAL ORGANIZATION

• Issue : Structure of site, movement between screens.

• It is the way to organize the system in the form of hierarchy along functional boundaries:– Roles or user types

– Modules eg in an educational system

• The hierarchy links screen, pages or states in logical groupings.

• It can be used during design and to structure the actual system.

• This may reflect the menu structure of a PC or smartphone application or the site structure on the web.

16

APPLICATION FUNCTIONAL HIERARCHY

17

The system

Information and help

Management

Add user Remove user

Messages

GLOBAL STRUCTURE – DIALOG

• In HCI, the word ‘dialog’ is used to refer to the pattern of interaction between the user and a system.

• In human-computer dialog, there are overall patterns of movement between main states of a device or windows in a PC application, but the detail differ each time it is run.

• A network diagram shows the principal states or screens linked together with arrows:– Show what leads to what

– Show what happens when

– Include branches and loops

– Be more task oriented than a hierarchy

18

NETWORK OF SCREENS/STATES

19

Main screen

Remove user Confirm

Add user

WIDER STILL

• Style issues :

– conform to platform standards eg positions for menus on a PC application, to ensure consistency between applications.

• Functional issues

– On a PC application, we need to be able to interact with files, read standard formats and able to cut and paste.

• Navigation issues

– Support linkages between applications eg in a mail system, able to double click an attachment icon and have the right application launched for the attachment.

20

SCREEN DESIGN AND LAYOUT

• The basic principles at the screen level reflect those in other areas of interaction design:

– Ask : what is the user doing?

– Think : what information is required? What comparisons may the user need to make? In what order are things likely to be needed?

– Design : form follows function – let the required interactions drive the layout.

21

TOOLS FOR LAYOUT

• A number of visual tools available to help us suggest to the user appropriate ways to read and interact with a screen or device.

• Thus, we need to consider:

– Grouping and structure

– Order of groups and items

– Decoration

– Alignment

– White space

22

GROUPING AND STRUCTURE• If things logically belong together, then physically group them

together.

• Below is an example of a reworked information architecture for the website:

23

ORDER OF GROUPS AND ITEMS

• In general we need to think: what is the natural order for the user? – this should match the order on screen.

• For data entry forms or dialog boxes, we should set up the order in which the tab key moves between fields.

24

DECORATION

• Other decorative features like font style, and text or background colours can be used to emphasize groupings.

25

ALIGNMENT

• It is very important.

• For users who read text from left to right, lists of text items should normally be aligned to the left.

• Number (integers) should be aligned to the right or at the decimal point.

26

Numbers Text

545.231.0998763

34748.9809

Dix, AllanAllan DixFamous Amos

WHITE SPACE

• The way of presenting information on screen depends on the kind of information:

– Text, numbers, maps, tables,

– Technology available to the present : character display, line drawing, graphics, virtual reality

– Purpose for which it is being used – different purpose, different requirement.

• Using white space in layout:

– Space to separate

– Space to structure

– Space to highlight27

USER ACTION AND CONTROL

• There are three things to consider:

– Entering information

–Knowing what to do

–Affordances

28

ENTERING INFORMATION• Some of the most complicated and difficult screen

layouts are found in forms-based interfaces and dialog boxes.

• In each case the screen consists of information presented to the user, and places for the user to enter information or select options.

• Both presenting and entering information must have clear logical layout.

• Users are likely to read from left to right and top to bottom (depending on their native language!) means that a screen can be designed so that users encounter items in an appropriate order for the task at hand.

29

KNOWING WHAT TO DO

• Some elements of a screen are passive – simply give information; others are active – fill in the blank or give command.

• Standard can help for common actions such as save, delete or print.

• For more system-specific actions, one needs to follow broader principles.

• Eg ‘DELETE’ – bold, current state of a system or the action that will be performed if the button is pressed.

30

AFFORDANCES

• The psychological idea of affordance says that :– things may suggest by their shape and other attributes what you co do

to them, a handle affords pulling or lifting or button affords pushing

• Affordances are not intrinsic – depend on the background and culture of users eg click on an icon.

• Experienced users may double click if a single click has no effect, yet novices would not even think of double clicking –after all, double clicking on most real buttons turns them off again.

31

APPROPRIATE APPEARANCE

• Presenting information

• Aesthetics and utility

• Making a mess of it: colour and 3D

• Localization / internationalization

32

PRESENTING INFORMATION• The advantage when presenting information in an

interactive system that it is easy to allow the user to choose among several representations, thus making it possible to achieve different goals.

• For more complex numerical data, we may be considering scatter graphs, histogram or 3D surfaces.

33

AESTHETICS AND UTILITY

• An interface should be aesthetically pleasing and improve quality.

• The application of aesthetic concepts can aid comprehensibility.

• Devices are designed to be good to touch and feel as well as look at.

34

MAKING A MESS OF IT: COLOUR AND 3D

• One of the worst features in many interfaces is their appealing use of colours. Monitors only support limited range of primary colours.

• The increasing use of 3D effects in interfaces has posed a whole new set of problems for text and numerical information

35

LOCALIZATION / INTERNATIONALIZATION• If you are working in a different country, you might see a document being

world processed where the text of the document and the file names are in the local language, but all the menus and instructions are still in English.

• The process of making software suitable for different languages and cultures is called localization or internationalization.

• A different resource database is constructed for each language, and so the program can be customized to use in a particular country by simply choosing the appropriate resource database.

36

ITERATION AND PROTOTYPING

• Almost all interaction design includes some form of iteration of ideas.

• It starts with paper designs and storyboards being demonstrated to colleagues and potential users.

• Then use mockups of physical devices or tools eg Visual Basic to create prototype versions of software.

• Formative evaluation : – Paper-based or running software – evaluate to see whether they are

acceptable and if there is room for improvement.

• Summative evaluation : – Performed at the end to verify whether the product is good enough.

37

ITERATION AND PROTOTYPING• Iteration and prototyping are universally accepted

‘best practice’ approach for interaction design.

• Two things you need in order for prototyping methods to work:

– To understand what is wrong and how to improve.

– A good start point – know what you want to achieve.

• A really good designer might guess a good initial design based on experience and judgement.

• Very common in graphical design, is to have several initial design ideas and drop them one by one as they are developed further.

38

SUMMARY

• The design in HCI is not only about creating devices or software, but instead is about the whole interaction between people, software and their environment.

• We must understand our materials like computer and technical devices, and also human.

• A good designer understands the natural limitations of ordinary people.

• To make iterative processes work, we need either extensive personal experience or theoretical understanding to help us get better initial designs.

39

EXERCISE #5

• Use a pocket alarm clock or wristwatch to set yourself alarms every 15 minutes one working day.

Write down exactly what you are doing. How surprising is it?

40

HCI IN THE SOFTWARE PROCESS

41

INTRODUCTION

• The design goal is to provide reliable techniques for the repeated design of successful and usable interactive systems.

• We have exercise of identifying paradigms and examine the process of interactive system design.

• We also have been introduced the elements of a user-centred design process, and placing the design of interactive systems within the established frameworks of software development.

42

INTRODUCTION

• Software engineering addresses the management and technical issues of the development of software systems.

• Software life cycle describes the activities that take place from the initial concept formation for a software system up until its eventual phasing out and replacement.

• Therefore, the issues from HCI affecting the usability of interactive systems are relevant within all the activities of the software life cycle.

43

THE SOFTWARE LIFE CYCLE

• A fundamental feature of software engineering is to provide the structure for applying techniques to develop software systems.

• To consider two parties:

– The customer who requires the use of the product.

– The designer who must provide the product.

• The term ‘customer’ refers to the group of people who interact with the design team.

• The ‘user or end user’ refers to those who will interact with the designed system.

44

ACTIVITIES IN THE LIFE CYCLE

• The analogy of the waterfall provides a good starting point for discussion the logical flow of activity.

– Requirements specification

– Architectural design

– Detailed design

– Coding and unit testing

– Integration and testing

– Maintenance

45

THE ACTIVITIES IN THE WATERFALL MODEL OF THE SOFTWARE LIFE CYCLE

Requirements Specification

Architectural Design

Detailed Design

Coding and Unit Testing

Integration and Testing

Operation and Maintenance

46

VALIDATION AND VERIFICATION

• Design must be checked to ensure that it both satisfies the high-level requirements agreed with the customer and is also complete and internally consistent.

• Validation = designing ‘the right thing’. A design demonstrates that within the various activities the customer’s requirements are satisfied.

• Verification = designing ‘the thing right’. A design will most often occur within a single life-cycle activity or between two adjacent activities.

47

FEEDBACK FROM MAINTENANCE ACTIVITY TO OTHER DESIGN ACTIVITIES

Requirements Specification

Architectural Design

Detailed Design

Coding and Unit Testing

Integration and Testing

Operation and Maintenance

48

MANAGEMENT AND CONSTRACTUAL ISSUES

• In a technical discussion, managerial issues of design, such as time constraints and economic forces, are not as important.

• Management focuses on the marketability of a system, its training needs, the availability of skilled personnel or possible subcontractors, and other topics for the development of the isolated system.

• Contractual obligation is a necessary consequence of managing software development.

• It is very difficult in the design of an interactive system to determine a priori what requirements to impose on the system to maximize its usability.

49

REPRESENTING ITERATION IN THE WATERFALL MODEL

Requirements Specification

Architectural Design

Detailed Design

Coding and Unit Testing

Integration and Testing

Operation and Maintenance

50

INTERACTIVE SYSTEMS AND THE SOFTWARE LIFE CYCLE

• In reality, even for batch-processing systems, the actual design process is iterative, work in one design activity affecting work in any other activity both before or after it in the life cycle.

• Traditional software life cycle:– The requirements for an interactive system cannot be determined

from the start –systems must be built and the interaction with users observed and evaluated in order to determine how to make them more usable.

– It is very difficult for an expert on human cognition to predict the cognitive demands that an abstract design would require of the intended user if the notation for the design does not reflect the kind of information the user must recall in order to interact.

51

USABILITY ENGINEERING

• The emphasis for usability engineering is in knowing exactly what criteria will be used to judge a product for its usability.

• Since a user’s direct experience with an interactive system is at the physical interface, focus on the actual user interface is understandable.

• In relation to the software life cycle, one of the important features of usability engineering is the inclusion of a usability specification, forming part of the requirements specification, that concentrates on features of the user-system interaction which contribute to the usability of the product.

52

Examples Of Usability Metrics From ISO 9241

Usability objective Effectiveness measures

Efficiencymeasures

Satisfaction measures

Sustainability for the task

Percentage of goals achieved

Time to complete a task

Rating scale for satisfaction

Appropriate for trained users

Number of power features used

Relative efficiency compared with an

expert user

Rating scale for satisfaction with power features

Learnability Percentage of functions learned

Time to learn criterion

Rating scale for ease of learning

Error tolerance Percentages of errors corrected

successfully

Time spent on correcting errors

Rating scale for error handling

53

PROBLEMS WITH USABILITY ENGINEERING

• They rely on measurement of very specific user actions in very specific situations.

• When the designer knows what the actions and situation will be, then she can set goals for measured observation.

• However, at early stages of design, designers do not have this information.

• It also provides a means of satisfying usability specifications and not necessarily usability where designer is still forced to understand by a particular usability metric enhances usability for real people.

54

ITERATIVE DESIGN AND PROTOTYPING

• The design can be modified to correct any false assumptions that were revealed in the testing.

• Iterative design is a purposeful design process to overcome the inherent problems of incomplete requirements specification by cycling through several designs, incrementally improving upon the final product with each pass.

• On the technical side, iterative design is described by the use of prototypes – things that simulate or animated some but not all features of the intended system.

• Prototyping has three main approaches – throw-away, incremental and evolutionary.

55

Throw-away Prototyping Within Requirement Specification

56

Preliminary

requirements

Build

Prototype

Evaluate

Prototype

Adequate?

?

Final

Requirement

yes

no

Incremental Prototyping Within the Life Cycle

57

Req

Arch

Det

Impl

Int

Designing component/prototype

Identify

components

Operation and

MaintenanceAdequate?

?

no yes

Deliver

system

Deliver

increment

Evolutionary Prototyping Throughout the Life Cycle

58

Req

Arch

Det

Impl

Int

Designing component/prototype

Build

Prototype

Operation and

Maintenance

Evaluate

Prototype

ITERATIVE DESIGN AND PROTOTYPING

• Prototypes differ according to the amount of functionality and performance they provide relative to the final product.

• The prototypes of an interactive system is used to test requirements by evaluating their impact with real users.

• An honest appraisal of the requirements of the final system can only be trusted if the evaluation conditions are similar to those anticipated for the actual operation.

59

Management Problems With Prototyping

Issues Explanation

Time Takes time especially in throw-away prototype from the real designtask. Rapid prototyping – rapid development and manipulation toavoid delay with jeopardize the quality.

Planning Project managers lack of experience for adequate planning andcosting a design process with involves prototyping.

Non-functionalfeatures

Such as safety and reliability that being sacrificed in developing aprototype. For evaluating usability features of a prototype, responsetime – yet another feature often compromised in a prototype - couldbe critical to product acceptance.

Contracts The design process is often governed by contractual agreementsbetween customer and designer which are affected by many of thesemanagerial and technical issues. Prototypes and otherimplementation cannot form the basis for a legal contract, and so aniterative design process will still require documentation which servesas the binding agreement.

60

TECHNIQUES FOR RAPID PROTOTYPING

Techniques Explanation

Storyboards Originated from film industry. Graphical depiction of the outward appearance ofthe intended system, without any accompanying system functionality. Forinteractive system design, the storyboards provide snapshots from an intendedfilm sequence in order to get the idea across about the eventual scene.Animation is computer aided to illustrate the dynamic aspects of the intendeduser-system interaction that impossible with traditional paper-basedstoryboards.

Limitedfunctionalitysimulation

Due to storyboards and animation limitation, designed team needs to simulatethe function using programming. Designer can rapidly build graphical and textualinteraction objects and attach some behaviour to those objects, which mimicsthe system’s functionality. Simulation is suitable for throw-away prototype.Using Wizard of Oz technique, designer can develop a limited functionalityprototype and enhance its functionality in evaluation by proving the missingfunctionality through human intervention.

High-levelprogrammingsupport

HyperTalk and other special-purpose high-level programming languages allow theprogrammers to attach functional behaviour to the specific interaction that theusers will be able to use eg position and click on mouse over a button on thescreen.

61

WARNING ABOUT ITERATIVE DESIGN

• Design decisions made at the very beginning of the prototyping process are wrong, and in practice, design inertia can be so great as never to overcome an initial bad decision.

• As a result, the only impact of interactive design was a change to the documentation alerting the user on the practice as it was too late to perform any hardware change eg. Issues in car manufacturing where certain badge is called back for inspection or replacement.

• If in the process of evaluation, a potential of usability problem is diagnosed, it is important to understand the reason for the problem and not just detect the symptom.

62

DESIGN RATIONALE

• Design rationale is the information that explains why a computer system is the way it is, including its

– structural or architectural description, and

– functional or behavioural description.

63

Benefit

Provides a communication mechanism among the members of a design team. Maintenance is possible through understand critical decisions, alternative investigation and reason for going for alternative.

Accumulated knowledge for a set of products can be reused to transfer what has worked in one situation to another situation which has similar needs.

The process of deliberation can be assisted by the design rationale technique by suggesting how arguments justifying or discarding a particular design option are formed.

PROCESS-ORIENTED DESIGN RATIONALE• Much of the work on design rationale is based on Rittel’s

issue-based information systems (IBIS) – a hierarchical structure to a design rationale.

• A root issue is identified which represents the main problem or question that the argument is addressing.

• Various positions are put forth as potential resolutions for the root issue, and these are depicted as descendents in the IBIS hierarchy directly connected to the root issue.

• Each position is supported or refuted by arguments, which modify the relationship between issue and the rooposition.

• The hierarchy grows as secondary issues are raised which modify the root issue in some way. Each of these secondary issues is in turn expanded by positions and arguments, further sub-issues, and so on. 64

The Structure Of A gIBIS Design Rationale

65

Issue

Position

Position

Argument

Argument

Sub-issue

Sub-issue

Sub-issue

supports

objects to

responds to

responds to

generalizes

specializes

questions

DESIGN SPACE ANALYSIS• MacLean and colleagues proposed Questions, Options and

Criteria (QOC) notation that characterized as design space analysis (DSA).

• The design space is initially structured by a set of questions representing the major issues of the design.

• The key to an effective design space analysis using the QOC notation is deciding the right questions to use the structure the space and the correct criteria to judge the options.

• Lee and Lai developed another structured-oriented technique called Decision Representation Language (DRL) to complement QOC.

• DSA addresses that no design activity can hope to uncover all design possibilities – thus, document the small part of the design space that has been investigated. 66

The QOC Notation (p252)

67

Question

Option

Option

Option

Criterion

Criterion

Criterion

Consequent question

PSYCHOLOGICAL DESIGN RATIONALE

• Introduced by Carroll and Rosson, and referred this real-life phenomenon as the task-artifact cycle.

• It identifies the tasks that the proposed system will address and to characterize those tasks by questions that the user tries to answer in accomplishing them:

– What can I do – what are the possible operations or functions that this programming environment allows?

– How does it work – what do the various functions do?

– How can I do this – once I know a particular operation I want to perform, how do I go about programming it?

• By forcing the designer to document the psychological design rationale, it is hoped that she will become more aware of the natural evolution of user tasks and the artifact, taking advantage of how consequences of one design can be used to improve later designs.

68

SUMMARY• Software engineering life cycle aims to structure design in order to

increase the reliability of the design process.

• In interactive system design,

– a reliable and reproducible means of designing predictably usable systems,

– Designer must be able to evaluate early prototypes and rapidly correct features of the prototypes which detract from the product usability.

• Usability engineering encourages incorporating explicit usability goals within the design process.

• Design process is composed of a series of decisions that is actually delivered to the customer.

• Design rationale allows the designer to manage information about the decision-making process – when and why design decisions were made, and what consequences those decisions had for the user in accomplishing his work.

69

EXERCISE #6

• How can design rationale benefit interface design and why might it be rejected by design teams?

70

END OF CHAPTER 3

71