Human computer

interaction(unit -II)

C.Vinoth
Asst.Prof (Adhoc)
GCE-Srirangam
Trichy-12
UNIT II
DESIGN & SOFTWARE PROCESS
Interactive Design basics – process – scenarios – navigation –
screen design – Iteration and prototyping. HCI in software process –
software life cycle – usability engineering –Prototyping in practice –
design rationale. Design rules – principles, standards,
guidelines,rules. Evaluation Techniques – Universal Design.
INTERACTION DESIGN BASICS
• Interaction design is about creating interventions in often
complex situations using technology of many kinds including
PC software, the web and physical devices.
1. Design involves:
• achieving goals within constraints and trade-off between these
• understanding the raw materials: computer and human
• accepting limitations of humans and of design.
2. The design process has several stages and is iterative and
never complete:
3. Interaction starts with getting to know the users and their
context:
• finding out who they are and what they are like . . .probably
not like you!
• talking to them, watching them.
4.Scenarios are rich design stories, which can be used and
reused throughout design:
• they help us see what users will want to do
• they give a step-by-step walkthrough of users‘ interactions:
including what they see, do and are thinking.
5. Users need to find their way around a system. This involves:
• helping users know where they are, where they have been and
what they can do next
• creating overall structures that are easy to understand and fit
the users‘ needs
• designing comprehensible screens and control panels.
6. Complexity of design means we don‘t get it right first time:
• so we need iteration and prototypes to try out and evaluate
• but iteration can get trapped in local maxima, designs that
have no simple improvements, but are not good theory and
models can help give good startpoints.
WHAT IS DESIGN?
• A simple definition is: achieving goals within constraints
• achieving goals within constraints goals – purpose-who is it
for, why do they want it constraints- materials, platforms
trade-offs
• - Choosing goals and constraints
• The golden rule of design- understand your materials
The process of design:
• HCI professionals complain that they are called in too late
• A system has been designed and built, and only when it proves
unusable do they think to ask how to do it right!
• In the best companies, however, usability is designed in from
the start.
Requirements – what is wanted
• The first stage is establishing what exactly is needed.
• how do people currently watch movies?
• What sort of personal appliances do they currently use?
• used for this in HCI: interviewing people, videotaping them,
looking at the documents and objects that they work with,
observing them directly.
• Ethnography is the in-depth study of a culture or a facet of a
culture.
Analysis:
• The results of observation and interview need to be ordered in
some way to bring out key issues and communicate with later
stages of design.
Design:
• There is a central stage when you move from what you want, to
how to do it
• We need to record our design choices in some way and there are
various notations and methods to do this, including those used to
record the existing situation.
Iteration and prototyping:
• Humans are complex and we cannot expect to get designs right first
time.
• Need to evaluate a design to see how well it is working and where
there can be improvements.
• Evaluation can be done using the design on paper, but it is hard to get
real feedback without trying it out.
• User interface design’s therefore involves PROTOTYPING, producing
early versions of systems to try out with real users.
Implementation and deployment:
• Finally, when we are happy with our design, we need to create it and
deploy it.
• Involve writing code, perhaps making hardware, writing
documentation and manuals– everything that goes into a real system
that can be given to others.
User focus: know your users
• who are they?
• probably not like you!
• talk to them
• watch them
use your imagination
scenarios
• stories for design
– communicate with others
– validate other models
– understand dynamics
• linearity
– time is linear
- our lives are linear
but don’t show alternatives
• what will users want to do?
• step-by-step walkthrough
– what can they see (sketches, screen shots)
– what do they do (keyboard, mouse etc.)
– what are they thinking?
use and reuse throughout design
use scenarios to communicate with others
– designers, clients, users
• validate other models
– ‘play’ it against other models
• express dynamics
– screenshots – appearance
scenario – behaviour
NAVIGATION DESIGN
• Navigation within the application You need to be able to
understand what will happen when a button is pressed, to
understand where you are in the interaction.
• Environment The word processor has to read documents from
disk, perhaps some are on remote networks. You swap
between applications, perhaps cut and paste.
• In this section we will look mainly at navigation design, that is
the main screens or modes within a system and how they
interconnect.
• Who is going to use the application?
• How do they think about it?
• What will they do with it?
• This can then drive the second task – thinking about structure
• Individual screens or the layout of devices will have their own
structure, but this is for the next section. Here we will consider
two main kinds of issue:
Local structure
• – looking from one screen or page out
Global structure
• – structure of site, movement between screens.
Local structure:
• Much of interaction involves goal-seeking behavior.
• Users have some idea of what they are after and a partial model
of the system.
• In an ideal world if users had perfect knowledge of what they
wanted and how the system worked they could simply take the
shortest path to what they want, pressing all the right buttons
and links.
• To get you started, here are four things to look for when
looking at a single web page, screen or state of a device.
• knowing where you are
• n knowing what you can do
• n knowing where you are going – or what will happen
• n knowing where you’ve been – or what you’ve done.
Global structure – hierarchical organization:
One way to organize a system is in some form of hierarchy
• This is typically organized along functional boundaries
• but may be organized by roles, user type, or some more
esoteric breakdown such as modules in an educational system.
• The hierarchy links screens, pages or states in logical groupings
gives a high-level breakdown of some sort of messaging
system.
SCREEN DESIGN AND LAYOUT
• Grouping and Structure:
If things logically belong together, then we should normally physically group
them together.
• This may involve multiple levels of structure.
• For example: potential design for an ordering screen.
Notice how the details for billing and delivery are grouped together
spatially
• also note how they are separated from the list of items actually ordered
by a line as well as spatially.
• Order:
• Administrative information
• Billing details
• Delivery details
• Order information
• Order line 1
• Order line 2
• ...
• Order of groups and items
Decoration:
• design uses boxes and a separating line to make the grouping
clear.
• decorative features like font style, and text or background
colors can be used to emphasize groupings.
Alignment :Alignment of lists is also very important.
• For users who read text from left to right, lists of text items
should normally be aligned to the left.
• Numbers, however, should normally be aligned to the right
(for integers) or at the decimal point.
• This is because the shape of the column then gives an
indication of magnitude – a sort of minihistogram.
White space:
• In typography the space between the letters is called the
counter.
• painting this is also important and artists may focus as much
on the space between the foreground elements such as
figures and buildings as on the elements themselves.
HCI in the software process
• The software lifecycle- Software engineering is the discipline for
understanding the software design process, or life cycle Designing
for usability occurs at all stages of the life cycle, not as a single
isolated activity
• Requirements specification:
• Architectural design:
• Detailed design:
 Verification- designing the product right
 Validation- designing the right product
 The formality gap
• Usability engineering:The ultimate test of usability based on
measurement of user experience
• Usability specification
– usability attribute/principle
– measuring concept
– measuring method
– now level/ worst case/ planned level/ best case
• Problems
– usability specification requires level of detail that may not be
– possible early in design satisfying a usability specification
does not necessarily satisfy usability
• Iterative design and prototyping:
Iterative design overcomes inherent problems of incomplete
requirements
• Prototypes
– simulate or animate some features of intended system
– different types of prototypes
• throw-away
• incremental
• evolutionary
• Management issues
– time
– planning
– non-functional features
contracts
Techniques for prototyping:
• Storyboard- need not be computer-based can be animated
Limited functionality simulations some part of system
functionality provided by designers tools like HyperCard are
common for these
Design rationale:
• Design rationale is information that explains why a computer
system is the way it is.
• Benefits of design rationale
• – communication throughout life cycle
• – reuse of design knowledge across products
• – enforces design discipline
• – presents arguments for design trade-offs
• – organizes potentially large design space
• capturing contextual information
Types of DR:
• Process-oriented
– preserves order of deliberation and decision-making
• Structure-oriented
– emphasizes post hoc structuring of considered design alternatives
• Two examples:– Issue-based information system (IBIS)
Design space analysis
• Design Rules:
Principles of usability- general understanding
• Standards and guidelines -direction for design
• Design patterns - capture and reuse design knowledge
Types of design rules
• principles
• – abstract design rules
• – low authority
• – high generality
• standards
– specific design rules
– high authority
– limited application
• guidelines
– lower authority
• more general application
Principles to support usability
• Learnability -the ease with which new users can begin
effective interaction and achieve maximal performance
• Flexibility -the multiplicity of ways the user and system
exchange information
• Robustness - the level of support provided the user in
determining successful achievement and assessment of goal-
directed behaviour
Principles of learnability
• Predictability
– determining effect of future actions based on past interaction
history
– operation visibility
Synthesizability
– assessing the effect of past actions
immediate vs. eventual honesty
Familiarity
– how prior knowledge applies to new system
– guessability; affordance
Generalizability
– extending specific interaction knowledge to new situations
Consistency
-likeness in input/output behavior arising from similar situations
or task objectives
Principles of flexibility:
Dialogue initiative
– freedom from system imposed constraints on input dialogue
– system vs. user pre-emptiveness
Multithreading
– ability of system to support user interaction for more than one
task at a time
– concurrent vs. interleaving; multimodality
Task Migratability
-passing responsibility for task execution between user and system
Substitutivity
– allowing equivalent values of input and output to be substituted
for each other
– representation multiplicity; equal opportunity Customizability
modifiability of the user interface by user (adaptability) or system
(adaptivity)
Principles of robustness
Observability
– ability of user to evaluate the internal state of the system from its
perceivable representation
• – browsability; defaults; reachability; persistence; operation
visibility
Recoverability
• – ability of user to take corrective action once an error has been
recognized
• reachability; forward/backward recovery; commensurate effort
Responsiveness
• – how the user perceives the rate of communication with the
system
• – Stability
Task conformance
• – degree to which system services support all of the user's tasks
• task completeness; task adequacy
Standards:
• set by national or international bodies to ensure compliance by a
large community of designers standards require sound underlying
theory and slowly changing technology
• hardware standards more common than software high authority
and low level of detail
ISO 9241 defines usability as effectiveness, efficiency and
satisfaction with which users accomplish tasks
Guidelines
• more suggestive and general
• many textbooks and reports full of guidelines
• abstract guidelines (principles) applicable during early life cycle
activities
• detailed guidelines (style guides) applicable during later life cycle
activities
understanding justification for guidelines aids in resolving conflicts
Golden rules and heuristics
• “Broad brush” design rules
• Useful check list for good design
• Better design using these than using nothing!
• Different collections e.g.
– Nielsen’s 10 Heuristics (see Chapter 9)
– Shneiderman’s 8 Golden Rules
Norman’s 7 Principles
Shneiderman’s 8 Golden Rules
1. Strive for consistency
2. Enable frequent users to use shortcuts
3. Offer informative feedback
4. Design dialogs to yield closure
5. Offer error prevention and simple error
handling
6. Permit easy reversal of actions
7. Support internal locus of control
8. Reduce short-term memory load
Norman’s 7 Principles
1. Use both knowledge in the world and knowledge in the head.
2. Simplify the structure of tasks.
3. Make things visible: bridge the gulfs of Execution and Evaluation.
4. Get the mappings right.
5. Exploit the power of constraints, both natural and artificial.
6. Design for error.
7. When all else fails, standardize.
Evaluation Techniques:

Goals of Evaluation-
assess extent of system functionality, assess effect of
interface on user, identify
• specific problems
Evaluating Designs
1. Cognitive Walkthrough
2. Heuristic Evaluation
3. Review-based evaluation
Cognitive Walkthrough:
Proposed by Polson et al.
– evaluates design on how well it supports user in learning task
– usually performed by expert in cognitive psychology
– expert ‘walks though’ design to identify potential problems using
psychological
principles
• forms used to guide analysisFor each task walkthrough
considers
– what impact will interaction have on user?
– what cognitive processes are required?
– what learning problems may occur?
Analysis focuses on goals and knowledge: does the design lead
the user to generate the correct goals?
Heuristic Evaluation:
• Proposed by Nielsen and Molich.
• usability criteria (heuristics) are identified
• design examined by experts to see if these are violated
• Example heuristics
– system behaviour is predictable
– system behaviour is consistent
– feedback is provided
Heuristic evaluation `debugs' design.
Review-based evaluation
• Results from the literature used to support or refute parts of
design.
• Care needed to ensure results are transferable to new design.
• Model-based evaluation
• Cognitive models used to filter design options
e.g. GOMS prediction of user performance.
Design rationale can also provide useful evaluation information
Universal design:
universal design principles
• equitable use
• flexibility in use
• simple and intuitive to use
• perceptible information
• tolerance for error
• low physical effort
size and space for approach and use