Beruflich Dokumente
Kultur Dokumente
• Usability engineering
• Design rationale
the software lifecycle
Architectural
design
Detailed
design
Coding and
unit testing
Integration
and testing
Operation and
maintenance
Activities in the life cycle
Requirements specification
designer and customer try capture what the system is
expected to provide can be expressed in natural language or
more precise languages, such as a task analysis would
provide
Architectural design
high-level description of how the system will provide the
services required factor system into major components of the
system and how they are interrelated needs to satisfy both
functional and nonfunctional requirements
Detailed design
refinement of architectural components and interrelations to
identify modules to be implemented separately the
refinement is governed by the nonfunctional requirements
Verification and validation
Real-world
requirements
and constraints The formality gap
Verification
designing the product right
Validation
designing the right product
Detailed
design
Coding and
unit testing
Integration
lots of feedback! and testing
Operation and
maintenance
Usability engineering
The ultimate test of usability based on measurement of user
experience
Usability engineering demands that specific usability measures
be made explicit as requirements
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
part of a usability
specification for a VCR
• effectiveness
– can you achieve what you want to?
• efficiency
– can you do it without wasting effort?
• satisfaction
– do you enjoy the process?
some metrics from ISO 9241
Usability Effectiveness Efficiency Satisfaction
objective measures measures measures
• 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
Throw-away prototyping within
requirements specification
Incremental prototyping within
the life cycle
Evolutionary prototyping
throughout the life cycle
Techniques for prototyping
Storyboards
need not be computer-based
can be animated
Limited functionality simulations
some part of system functionality provided by designers
Many tools available
Wizard of Oz technique: Domain expert user types inputs
to a system, a human at backend translates them to valid
system input and presents output to user.
• Another example is the original
Mechanical Turk
Limitations
• Time
• Planning Most project managers do not
have the experience necessary for
adequately planning and costing a
design process which involves
prototyping.
• Non-functional features
• Contracts Prototypes and other
implementations cannot form the basis
for a legal contract.
Warning about iterative design
design inertia – early bad decisions stay bad (also next slide)
diagnosing real usability problems in prototypes….
…. and not just the symptoms
pitfalls of prototyping
Types of DR:
• Process-oriented
– preserves order of deliberation and decision-making
– for use during actual design discussions
• Structure-oriented
– emphasizes post hoc structuring of considered
design alternatives
• Two examples:
– Issue-based information system (IBIS)
– Design space analysis
Issue-based information
system (IBIS)
• basis for much of design rationale research
• process-oriented
• main elements:
issues
– hierarchical structure with one ‘root’ issue
positions
– potential resolutions of an issue
arguments
– modify the relationship between positions and issues
Sub-issue generalizes
questions
Sub-issue
Sub-issue
• Other versions of the IBIS notation, both
graphical and textual, besides gIBIS.
• Some add extra nodes while some add richer
language.
• Use during design meetings as a means of
recording and structuring the issues
deliberated and the decisions made.
• Historically accurate description of a design
team making some decision on a particular
issue for the design..
Design space analysis
• structure-oriented
• (Questions, Options, Criteria) QOC –
hierarchical structure:
questions (and sub-questions)
– represent major issues of a design
options
– provide alternative solutions to the question
criteria
– the means to assess the options in order to make a choice
Option Criterion
… Consequent …
Question
Question
QOC
1. Decompose your problem into
interaction problem questions.
– E.g. How can users of an online community
be assigned rating?
2. Think of Options
– By polling.
– Performance over time automatically.
– How many connections (s)he has.
Next slide
3. Decide criteria. It should be
– Objective
– Specific
– Non-overlapping
• E.g. Usability criteria: Learnability,
Efficiency, Effectiveness, User
satisfaction…..
• The key to an effective design space
analysis using the QOC notation is
deciding the right questions to use to
structure the space and the correct
criteria to judge the options.
• An advantage of the post hoc technique
is that it can abstract away from the
particulars of a design meeting and
therefore represent the design
knowledge in such a way that it can be
of use in the design of other products.
Psychological design rationale
• http://usabilitygeek.com/white-spaces-
improving-usability-web-designs/
• https://eight2late.wordpress.com/2009
/07/08/the-what-and-whence-of-issue-
based-information-systems/
• http://www.slideshare.net/koenvanturn
hout/how-to-perform-a-qoc-analysis