1. Human Computer Interaction
Week 6
Interaction 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. Supporting Designers (1)
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

5. Supporting Designers (2)
Alternative Designs – explored and evaluated
Design Simulation – prototyping
Understanding the problem domain – understanding the task and the task environment
Reasoning Strategy – opportunistic and evolutionary

6. Supporting Design Teams
Communication – communicate ideas
The problem of communication – inadequacy of written documentation
The most common form of team interaction is meeting

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. Guidelines: Principles and Rules
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

9. From Principles into Design Rules
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

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: DO:
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. How to document design rationale
IBIS (Issue-Based Information Systems) an early documentation technique that led to the development of many others.
Design Space Analysis actively encourages designers to explore alternatives and results in a documented account of the alternatives considered and the reasons for choosing the final design.
Claims Analysis concentrates on analysing and refining an existing design.

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: One
Q: 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