CSE 3345 User interface design A software engineering perspective Chapter 8: Prototypes and Defect Correction

What Paper Prototyping Is Good For Concepts and terminology –Do the target users understand the terms you've chosen? Are there key concepts they gloss over or misconstrue? Navigation/workflow –If there's a process or sequence of steps, does it match what users expect? Do they have to keep flipping back and forth between screens? Does the interface ask for inputs that users don't have, or don't want to enter? Content –Does the interface provide the right information for users to make decisions? Does it have extra information that they don't need, or that annoys them? Page layout –Although your scribbled screens may not be pretty, you'll still get a sense of whether users can find the information they need. Do you have the fields in the order that users expect? Is the amount of information overwhelming, not enough, or about right? Functionality –You may discover missing functionality that users need, or functionality you'd planned but users don't care about.

What Paper Prototyping Isn’t Good For Technical feasibility –Paper prototypes don't demonstrate technical capability. It's possible to create a paper prototype that can't actually be implemented. There should always be at least one person involved who understands the technical constraints. Download time or other response time. –Because a person simulates the behavior of the computer, the "response time" is artificial. Colors and fonts –If you really need to see how something looks on a computer screen, (handwritten) paper prototyping can't show you that.

Procedure to Make a Paper Mockup Make a full graphical (hand drawn or tool-drawn) version of each page (window). –Pages should be drawn with empty data fields. Copy the pages and fill in the necessary data for the specific tests you plan to run. Make the necessary menus (drop-down and pop-up). Make message boxes for all error and information messages. –Make a few empty message boxes that can be customized during testing Make drop-down lists for combo boxes and any other pieces of the interface that the user might see. A state diagram will often be helpful ….

Procedure to Make a Paper Mockup FindRooms, Repair, Add... FindGuest, FindStay... NewStay NewGuest OpenStay AddService DelService... FindRooms Book, Checkin PrintConfirm, Checkout AddServiceLine... Book Checkin Return RecBreakfast Return EditService FindRooms... vwServiceList vwBreakfast vwRooms vwStay(new) vwRooms vwFindGuest vwRooms vwStay(rec) pSearch pStay(new) pStay(rec) pBreakfast pServiceList CancelStay

Good and Bad Error Messages Good error messages are 1.Friendly (don’t blame the user) 2.Precise (what is wrong?) 3.Constructive (what to do?) 4.Prevented (cannot occur) Example: User clicks Check In on the Stay window Be precise: Be con- structive:

Evaluation and Usability Testing Make heuristic evaluations ahead of time to find potential problems. –Remember the first law of usability: Heuristic evaluation has only a 50% hit-rate. Compose tests and metrics by which to measure success Run the usability tests. –Test team members … facilitator log keeper observer (optional support member) user (actual user(s), not a developer) Record defects, evaluate results, fix agreed upon problems, re-test.

Evaluation and Usability Testing Plan test Test-users: choose actual users not IT professionals Test-tasks: choose realistic scenarios the users will encounter in the real world Study system yourself: testers are not usually part of the actual design effort Carry out test Explain purpose: -Find problems when using the system -System’s fault - not yours Give task - think aloud, please Observe, listen, note down Ask cautiously: -what are you looking for? -why... ? Help users out when they are surely lost

Evaluation and Usability Testing Planning the test tasks –Tests need to reflect real-world usage of the system. –Each test needs to reflect a real and meaningful unit of work. –Have an assortment of tests at various levels of difficulty. –Start with easy tests first. –The tests should be independent of each other. –The task needs to be stated without hints on how to carry out the task.

Examples of Hidden Help Version A: John Simpson wants to check in. Find him on the FindGuest screen. Double click to open his Stay screen. Version B: John Simpson wants to check in. He has stay number 710. Version C: John Simpson arrives 23rd October. He says there should be two rooms for him. If asked:He cannot remember his booking number (or stay number). He lives 456 Orange Grove, Victoria Australia (can’t remember zip code) He leaves 26th October.

Hotel System Paper Mockup 11

Hotel System Paper Mockup 12

Hotel System Tool-based Mockup Menus Drop-down lists Message boxes Platform surprises: Only main menus Name part ? Two Find buttons Earlier: Free from + Free to State shown

Tabs rather than one long list Buttons, not menus Same window for create and edit Hotel System Tool-based Mockup

One Find Stays and guests Live search Two dates Expert users Hotel System Final Product

Updates immediately, but no OK is scaring Hotel System Final Product

Defects and Their Cure Create a list for recording defects. Include the following data for each defect. –Unique defect ID number –Description of the defect –Test case that revealed the defect –Proposed fix or resolution –Defect status (pending, rejected, ignore, training, done, release x, duplicate). See page 284 for defect status definitions.

Fig 8.3A Defects and their cure

Problems, Causes and Solutions Finding the cause of a user’s problem leads to finding a solution sooner. Encourage the user to think out loud Ask the user why he did something but only after the test has been completed. Just because one user has a problem with some feature of the system does not mean it is a problem. Run each test case with several users. Only when a significant number of the users have a problem with a feature is it a problem.

User Problem Observation SolutionCause severity, time Fig 8.4 Problem - cause - solution

Paper Prototype Examples

Other Resources Template for Usability Test Tasks Rules for Usability Test Observers