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 

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  

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)  Look at page 26 of this paper (also referred to in the day 8 slides)

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