User Interface Prototyping
1. Essential UI Prototyping
• represents general ideas behind the UI
• not exact details
• represents UI requirements
• what needs to happen
• rather than how it will be implemented or with which
technology (both are design decisions)
• a launchpad for subsequent prototyping and design
• at this point we are still trying to understand the problem,
before we move on to solve it
1. Essential UI Prototyping
• focus is on users and their usage of the system
• integrates well with use case modelling
• is done as a paper exercise
• can use flip charts, sticky notes
• avoids narrowing the design space to whatever development
or prototyping tools you use
• quick and easy to explore - and discard ideas
• really easy to involve stakeholders
Creating an Essential UI
Prototype
• Explore system usage
• Model major UI elements
• Model minor UI elements
• Explore the usability of your UI
Explore System Usage
• what happens during the use case(s):
• information provided by the system
• information input by the user
• actions taken by the user
Model UI Elements
• Major Elements:
• such as screens (or main sections of an interface)
• name them: e.g. “Course Enrolment UI”
• Minor Elements:
• such as input fields, lists and action items
• just placeholders for now
Explore Usability
• clear?
• consistent?
• learnable?
• easy to remember?
• achievable?
Example Essential UI Prototype
pink input fields
yellow info only
blue action items
from The Object Primer (Ambler 2004, 2009)
From requirements gathering
into analysis...
2. The Prototyping Process
[finished]
Determine Build Evaluate
Needs Prototype Prototype
[continue]
from The Object Primer (Ambler 2004, 2009)
Screen Sketches
from The Object Primer (Ambler 2004, 2009)
Screen Sketches
• provide finer detail
• give a better idea of how UI will be implemented
• can still easily involve stakeholders in their creation
Concrete Prototypes
from The Object Primer (Ambler 2004, 2009)
Concrete Prototypes
• hand-coded or using prototyping tools
• moving closer to design
• good if we are ready to solve the problem
• but might be harder to involve stakeholders in their
creation and exploration
To conclude
• don’t need to prototype entire system
• do enough to allow you to:
• capture and represent requirements in key areas
• move onto design across the whole system
• explain your UI ideas to others
• don’t shy away from known requirements
• if it has to use a stand-alone GUI, don’t waste time or struggle trying to be too general
• ask:
• what’s good?
• what’s bad?
• what’s missing?
References & Recommended
• this presentation was adapted from Scott W. Ambler’s
online guides to prototyping:
• http://www.agilemodeling.com/artifacts/essentialUI.htm
• http://www.agilemodeling.com/artifacts/uiPrototype.htm
• those guides and figures used here were derived from:
• Chapter 6 of The Object Primer, Cambridge University Press,
2004 ISBN#: 0-521-54018-6