1

Human Computer Interaction

Week 6Interaction Design Support

2

Introduction The importance of visualization in

design – considering alternatives Avoid evolutionary prototyping of

the interface Creating alternatives

create separate groups to work on alternatives

Keep ‘idea logs’ – never lose an idea Design Rationale

3

Supporting the Design Process The use of supporting techniques

and tools Software Support for diagramming

(ER/DFD editors) Discussions with the users (User

Centered Design) Considering and choosing alternatives Software Support for designing and

producing screen layouts, icons, etc.

4

Designer experience – hire good and experienced designers

Previous known solutions – use knowledge of previous projects to identify known successful solutions to similar problems

Problem decomposition – decompose large problems into less complex, more well-defined subproblems

Supporting Designers (1)

5

Alternative Designs – explored and evaluated

Design Simulation – prototyping Understanding the problem

domain – understanding the task and the task environment

Reasoning Strategy – opportunistic and evolutionary

Supporting Designers (2)

6

Communication – communicate ideas The problem of communication –

inadequacy of written documentation The most common form of team

interaction is meeting

Supporting Design Teams

7

Different kinds of support

Guidance – ranging from universal design guidelines to detailed design rules

Support for communicating and recording design decisions – capture ideas and explore alternatives

Software support – capturing ideas, exploring alternatives, recoding decisions, translating into executable code

8

Principles: must be interpreted and translated into a strategy

Design rules: an instruction that can be obeyed with minimal filling out and interpretation by the designer

Guidelines: Principles and Rules

9

Care must be taken to interpret principles appropriately

Be careful not to misinterpret principles e.g. Human STM 7+/- 2 is misinterpreted into the number of color used, or the number of menu items in a menu

From Principles into Design Rules

10

Design Rationale (1)

Design Rationale is the reasoning (rationale) behind the design of that software.

Design Rationale is documented as a coherent description of the system structure and purpose

11

Design Rationale (2) Design Rationale is needed by

many people: Software maintainers Trainers Marketing Personnel New staff in development team Design team members End users

12

Uses of Design Rationale (1) For New staff in the development team:

learn why certain design decisions have been made.

For Design team members:benefit from an explicit representation to the design’s rationale while it is being developed.

For End users:benefit from understanding how the system is constructed.

Having a design and its decisions recorded could facilitate Reuse

13

Uses of Design Rationale (2) For Software Maintainers:

know how the system can be changed without disrupting its overall stability.

For Marketing Personnel:helps answering customers’ questions appropriately.

For Trainers:helps end users to build a suitable understanding of the system.

14

Design Rationale Tips DON’T:

document every design decision in detail. DO:

document only practical or document key decisions in detail.

document the decisions that were particularly contentious or difficult to make.

document where an exploration of alternatives is important.

15

IBIS (Issue-Based Information Systems)an early documentation technique that led to the development of many others.

Design Space Analysisactively encourages designers to explore alternatives and results in a documented account of the alternatives considered and the reasons for choosing the final design.

Claims Analysisconcentrates on analysing and refining an existing design.

How to document design rationale

16

IBIS (1)

IBIS is a technique which was devised in order to capture design decisions as the design progressed.

The central activity of IBIS is deliberation, that is, considering the pros and cons of alternative answers to questions.

17

IBIS (2)

The questions are called issues The answers are called positions The pros and cons are the arguments for or against the position.

18

IBIS (3) An IBIS discussion begins with a root issue,

which is the main question to be addressed; for instance: what should this system do?

Positions are put forward to answer this question, together with arguments for and against them.

Secondary issues can be generated and deliberated in the same way, and these may lead to tertiary issues, and so on until a solution is reached.

19

IBIS (4) The issue deliberations are charted by

producing a graphical diagram called an issue map, which illustrates the issues and their relationships.

Various relationships between the issues were recognized as ‘more general than’, ‘similar to’, ‘replaces’, ‘temporal successor of’, and ‘logical successor of’.

20

Problems with IBIS

Dependencies between issues were not catered for; that is, no account was taken of whether the answer to one question relied on the answer to another.

Only questions which become issues, that is, which are deliberated, are represented on the issue map.

21

Design Space Analysis Design can be viewed as an

exploration of a space of alternatives. There are a host of alternative

designs that fulfill the system’s specification.

The process of design involves identifying the one, or ones, that satisfy the system’s constraints and goals as closely as possible.

22

Design Space Analysis Notation QOC (Questions, Options, and Criteria)

Questions represent issues that must be considered.

Options are answers to questions. Criteria are positive goals, used to

distinguish between the various options; they argue for or against the various alternatives

unbroken lines = positive relationship (option is supported by the criterion)

dotted lines = negative relationship (option is not supported by the criterion)

23

Design Space Analysis Example

The design of UNDO in a multi-user text editor.

Two versions of undo: Relative to the individual: individual users can

UNDO only their own actions. Relative to the document: actions can be undone

regardless of who carried out the original action. Two versions of software:

first release: single insertion point, with control moving between the users by an explicit action.

second release: multiple insertion points, each user can make changes simultaneously

24

Design Space Analysis Example

C: User predictability O: Individual user

Q: What is UNDO C: Learnability relative to? O: Document

C: Ease of Implementation

C: Awareness of others’ work

O: OneQ: How many C: Low cognitive load simultaneous O: Many insertion points? C: Accessibility

25

Claims Analysis (1)

Claim Analysis is done by creating scenarios of the system’s use and analyzing them for claims.

Core tasks that the system is intended to support and key errors that the system must be able to handle should be included.

26

Claims Analysis (2) The primary purpose is to identify how the

system positively supports the user Claims Analysis may also identify trade-

offs. Claims Analysis can be used to guide the

redesign of an existing system, or to help in the prototypical development of a new system.

The Premise of Claims Analysis is that the system should support the user.

Claims Analysis concentrates on refining one design.

27

Further Reading

Preece, chapter 23, 24, 26