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