1 human computer interaction week 6 interaction design support
Post on 14-Jan-2016
217 Views
Preview:
TRANSCRIPT
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
top related