Day 5

Specifying designs

Objectives

Learn about the need for prototypes and user testing with these

Learn about different ways in which prototypes vary

Why specify the design?

It helps you think through important issues brings up many issues that cannot be adequately

anticipated helps ensure your design can accommodate all

features you have planned for it

It communicates the design to clients, team members, and users serves as focal point for discussion, illustrating the

design’s accommodation of its intended features can be used to perform early usability testing of the

design on the target audience

Prototypes

prototypes are simplified versions of something being designed

they provide a good idea of the look and feel of a product

prototypes can range from very low-fidelity, such as pen and paper sketches - very high-fidelity, such as functional software

Some terminology - types of prototypes

The term “wireframes” comes from the term for simple representations

of 3D drawings that look like wire bent into different shapes

in UID, wireframes show the basic composition of elements on screens, without suggesting the finished graphic look

They range from quick pencil and paper sketches to software created more polished looking representations

A pencil wireframe

A software produced wireframe

another

and another

Still another

yet another

The last one

More terminology – types of prototypes

The term “storyboards” comes from the animation and movie industries they show the sequences of screens but, then again, so can wireframes – whether pencil

or software generated In fact, some people would say they are the same Marc Silver (the author of “Exploring Interface

Design”) uses storyboard to mean “a set of sketches or images that illustrate use cases” – thus they illustrate the series of screens that a user must access to perform a particular task

A “storyboard”

A final word on terminology

Many people, when referring to what Silver calls storyboards, simply use the word “prototype”

They will just make a distinction between different levels of fidelity – low or high fidelity prototypes

Don’t get too caught up in terminology

I’m going to use the word prototype!

paper prototypes

people do use paper prototypes in usability tests to see how users interact with the proposed system

paper prototypes may be more than sketches

Some links on prototyping

http://www.sapdesignguild.org/resources/prototypes.asp

On a whiteboard

Starting at tables in teams

One page of a paper prototype

And another, more detailed

Implementing a paper prototype

They can be implemented in a number of ways depending on personal experience or preferences

Typical materials used for paper prototypes are: cardboard – for the screen post-it notes in different sizes - for menus, dialog boxes drop-

down menus, or other screen elements erasable markers – for user input write on transparencies - for user input pencils – for user input, either to write with or use as a mouse to

“click” clips – to keep the paper screens organised water – to erase erasable marker ink removable tape – so parts can be moved or removed

An interactive prototype

Each tab is on a separate piece of paper so it can be moved to the front if the user selects it

The drop-down list for paper size is written on a separate piece of paper and is shown if the user touches the drop-down arrow

The radio button is simulated using removable tape

The preview components (shown in red) are tacked on with restickable glue so they can be changed if the user selects Landscape

Example Usability Test with a Paper Prototype http://vimeo.com/2273993 http://www.youtube.com/watch?v=9wQkLthhHKA

Prototypes vary along 3 dimensions

fidelity

medium

interactivity

Mary and John talk …

Don’t get carried away in the early stages

The prototype only needs to be good enough for you to get answers to the questions you’re most concerned about

paper prototypes don't need: typed text images colour

“You can put earrings on a pig, but it's still a pig.” Colour can't save an inherently flawed design. Colour can be added later once you’re sure you aren’t creating a pig

consistent sizing of components

Don’t assume high-fidelity is always best

Quote 1

“One thing I can say from experience is that most times [level of visual design] really depends of who you are going to be showing this prototype to. I would never show a client, a marketing person, or a designer a fully (heck anything that looks “done” at all – even halfway) rendered prototype – you’re just asking for a world of hurt”

Quote 2

“In eight years of usability testing, I've collected a number of “war stories” where technical glitches caused tests to be postponed or cancelled. This was disruptive to the development teams, which were relying on the tests to answer important questions about the interface. But I've never had to abort a usability test due to a problem with a paper prototype. I've even done paper prototyping during a power failure!”

Quote 3

A polished-looking design can actually encourage the wrong kind of feedback. If you're trying to make sure you've got the right content and functionality, you may not want to hear comments like, “Hey, those fields don't line up,” or “I don't like that shade of green.” Paper prototypes avoid that kind of feedback because it's obvious to users that you haven't specified the look yet. This encourages users to focus on the concepts and functionality.

Quote 4

Developers are less committed to paper prototypes

Carolyn Snyder on paper prototyping

You don't have to struggle with computers

It's faster to do changes

It takes less time

It requires zero coding effort

You avoid nit-picky feedback

You encourage creativity

Moving on …

Debates about paper vs software prototypes are perhaps looking at things the wrong way

You could start out with low-fidelity paper based no to moderate interactivity

And move to high-fidelity software based moderate to full interactivety

Remember

The prototype only needs to be good enough for you to get answers to the questions you’re most concerned about

Decide at each stage what questions you are most concerned about and create appropriate tasks for your user testing

For examples tasks

Look at section 7 of this paper (also referred to in the day 8 slides)

http://www.cit.gu.edu.au/~mf/uidweek10/ergosoft.pdf

Look at page 26 of this paper (also referred to in the day 8 slides)

http://www.cit.gu.edu.au/~mf/uidweek10/Tower_Test_Report.pdf

Tasks – and the prototype

Today’s lab

prototypes and user tasks

make sure to read the suggestions on the website regarding things you could do by next week