Iterative design and

prototyping
Iterative design and prototyping
• Requirements of the iterative segments
cannot be specified from the beginning.

• Only way is to built them and test them on

real users.

• It is software engineering problem,together

with technical and managerial issues.
 PROTOTYPES
• Iterative design is described by the use of the
prototypes.

– simulate or animate some features of intended

system

– different types of prototypes

• throw-away
• incremental
• evolutionary
THROW AWAY
• The prototype is built and tested.
• The experience gained is taken to built original
system.
• Actual prototype is discarded.
INCREMENTAL
• Final product is built as a separate component.
• Final system is partitioned into independent
components.
• Final component is released as a series of
product.
EVOLUTIONARY
• Prototype is not discarded it serves as basic
for the next iteration of design.
• Actual system evolves from the limited initial
version to its final release.
 Cont…

• An animation of requirement can involve no

real functionality.
• Full functionality can be provided at the
expense of other performance characteristics.
• Prototype of an interactive system is used to
test requirements by evaluating with user.
• Providing realism is costly.
 CONT..

On the management side there are

several problems

• Management issues
–time
–planning
–non-functional features
–contracts
TIME
• Building prototype takes time.
• Value of prototyping is appreciated only if it was Fast.
• At the same time it should not produce erroneous
results.
Planning
• Most project managers do not have the experience
necessary for adequately planning and costing a
design process which involves prototyping.
NON-FUNCTIONAL FEATURES

• Most important features of the system will be non-functional

one.
• This problem is similar to the technical issue of prototype
realism

CONTRACTS

• The design process is often governed by contractual

agreements b/w customer and designer.
• There must be an effective way of translating the result from
prototype into document.
 Techniques for prototyping
Storyboards
• Probably the simplest of a prototype is the
storyboard.
• Storyboard do not require must in term of
company system power to construct.
• For Interactive system design storyboard provides
snapshot of interface at particular points of
interaction.
• Storyboard usually includes annotations and
scripts Indicating how the interaction will occur.
Limited functionality simulations

• More functionality must be bulit into the

prototype to demonstrate the work that the
application will do.
• Some portion of the functionality must be
simulated by the design team.
• Once the stimulation is built,it can be
evaluated and changed rapidly based on users
experiences.
 Cont..
• Well-known and successful prototyping tool is
hypercard.
• The graphical images are placed on cards,and
links between cards can be created for
animation effects.
• One technique for simulation which does not
require very much computer supported
functionality ,is the wizard of Oz techniques.
 High-level programming support
• HyperTalk was an special purpose high-level
Programming language
• It makes easy for the designer to program
certain features of an interactive system.
• Attach functional behaviour to the specific
interactions that the user will be able to do.
• It is Implementation dependent.
 Cont..
• “User interface management system”
• Can be considered to provide high level
programming support.
• It is separate the application functionality
from its presentation.
• The job of UIMS ,is to allow the programmar
to connect the behaviour at the interface with
the underlying functionality.
 WARNING ABOUT ITERATIVE
DESIGN
There are 2 problems
• First,it is often the case that design
decisions taken at the very beginning stage of
prototyping is wrong.
• Second,if in the process of evaluation ,a
potential usability problem is diagonised,it is
important to understand the reason for the
problem
 DESIGN RATIONALE
• Design rationale is information that explains
why a computer system is the way it is.

• Design rationale relates to an activity of both

reflection and documentation that occur
throughout the entire life cycle.
 REASONS FOR DESIGN
RATIONALE
• Explicitly,design rationale provide a
communication mechanism among the
member of the design team.
• Accumulated knowledge in the form of design
rationale for a set of products can be reused
for another situation.
• The effort required to produce a design
rationale forces designer to be more delibrate.
 CONT….
• Usually there is no single best
alternative.often designer is faced with a set
of Trade-off’s between different alternatives.

• In project management, accountability is

good.

• Usability is very much dependent on the

context of its use.
 PROCESS-ORIENTED DESIGN
RATIONALE
• Process-oriented
– preserves order of deliberation and
decision-making

• 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

• gIBIS is a graphical version

 structure of gIBIS
.
supports
Position Argument
responds to
Issue
responds to
objects to
Position Argument
specializes

Sub-issue generalizes

questions

Sub-issue

Sub-issue
 Design space analysis
• structure-oriented
• 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

• DRL – similar to QOC with a larger language and more formal

semantics
 The QOC notation

option
Criterion

Question option
Option Criterion

option Criterion

Consequent
 Psychological design rationale
• To support task-artefact cycle in which user tasks are
affected by the systems they use
• aims to make explicit consequences of design for users
• designers identify tasks system will support
• scenarios are suggested to test task
• users are observed on system
• psychological claims of system made explicit
• negative aspects of design can be used to improve next
iteration of design
THANK YOU!!!!!