Human Computer Interaction Week 6 Interaction Design Support

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

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.

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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

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.

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’.

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.

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.

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)

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

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

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.

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.

Further Reading Preece, chapter 23, 24, 26