MIT GSL week 4 Wednesday. User Interfaces II

Transcription

1 MIT GSL 2018 week 4 Wednesday User Interfaces II

2 User Centered Design

3 Prototyping! Producing cheaper, less accurate renditions of your target interface! Essential in spiral design process, useful in later iterations as well! Why?! Get feedback earlier, cheaper! Experiment with alternatives! Easier to change or throw away! Fidelity how similar it is to the final product! Low fidelity: omits details! High fidelity: more like finished product

4 Prototyping! Breath: % of features covered. Depth required for degree of functionality implemented! Look: Appearance, graphic design! Sketchy, hand-drawn! Feel: input method! Pointing and writing feels very different from mouse and keyboard

5 Look & Feel

6 Look & Feel

7 Paper Protype! Interactive paper mockup! Sketches of screen appearance! Paper pieces show windows, menus, dialog boxes! Interaction is natural! Pointing with a finger = mouse click! Writing = typing! A person simulates the computer s operation! Putting down & picking up pieces! Writing responses on the screen

8 Paper Prototypes! Describing effects that to show on paper Low fidelity in look & feel High fidelity in depth (person simulates the backend)

9 Why Paper Prototypes?! Faster to build! Sketching is faster than programming! Easier to change! Easy to make changes between user tests, or even during a user test! Focuses attention on big picture! Designer doesn t waste time on details! Only preschool skills required

10 Good Paper Prototypes Tips! Make it larger than life! Make it monochrome! Replace tricky visual feedback with audible descriptions! Tooltips, drag & drop, animation, progress bar! Keep pieces organized! Use folders & open envelopes

11 Testing a Paper Prototypes! Role for design team! Computer! Simulates prototype! Doesn t give any feedback that the computer wouldn t! Facilitator! Presents interface and tasks to the user! Encourages user to think aloud by asking questions

12 Testing a Paper Prototypes! Role for design team! Facilitator! Keeps user test from getting off track! Observer! Keeps mouth shut, sits on hands if necessary! Takes copious notes

13 What you can learn from Paper Prototype! Conceptual model - Do users understand it?! Functionality - Does it do what s needed? Missing features?! Navigation & task flow! Can users find their way around?! Are information preconditions met?! Terminology Do users understand labels?! Screen contents - What needs to go on the screen

14 What you can t learn from Paper Prototype! Look: color, font, whitespace etc! Feel: efficiency issues! Response time! Are small changes noticed?! Exploration vs deliberation! User are more deliberate with a paper prototype; they don t explore or trash as much

15 Computer Prototypes

16 Computer Prototype! Interactive software simulation! High-fidelity in look & feel! Low fidelity in depth! Paper prototype had a human simulating the backend; somputer prototype doesn t! Computer prototype may be horizontal covers most features, but no backend

17 What you can learn Computer Prototypes! Everything you learn from paper prototype plus:! Screen layout! Is it clear, overwhelming, distracting, complicated?! Can users find important elements?! Colors, fonts, icons, other elements! Well-chosen?! Interactive feedback! Efficiency issues Controls big enough? Too close together? Scrolling list is too long?

18 Why Use Prototype Tools! Faster than coding! No debugging! Easier to change or throw away! Don t let your UI toolkit do your graphic design

19 Computer Prototyping Techiniques! Storyboard! Sequence of painted screenshots! Sometimes connected by hyperlinks! Form builder! Real windows assembled from a palette of widgets (buttons, text fields, labels)! Wizard of Oz! Computer frontend, human backend

20 Storyboarding

21 Storyboarding Pros Your can draw anything Cons No text entry Widgets aren t active Hunt for the hotspot

22 User Testing

23 Types of User Tests Formative evaluation Find problems for next iteration of design Evaluates prototype or implementation, in lab, on chosen tasks Qualitative observations (usability problems) Field study Find problems in context Evaluates working implementation, in real context, on real tasks Mostly qualitative observations

24 Types of User Tests Controlled experiment Tests a hypothesis (e.g., interface X is faster than interface Y) Evaluates working implementation, in controlled lab environment, on chosen tasks Mostly quantitative observations (time, error rate, satisfaction)

25 Basic Principles (Belmont Report) Respect for persons voluntary participation, informed consent protection of vulnerable populations (children, prisoners, people with disabilities, esp. cognitive) Beneficence do no harm; risks vs. benefits: risks to subjects should be commensurate with benefits of the work to the subjects or society Justice - fair selection of subjects

26 Pressures on a User Performance anxiety Feel of an intelligence test Comparing self with other subjects Feeling stupid in front of observers Competing with other subjects

27 Avoiding errors Different things should act differently but similar things should? Separate dangerous functions from frequently used commands Safety from Mode Errors Eliminate modes Increase visibility of mode Disjoint action sets in different modes Confirmation Dialogs! use sparingly!!

28 Treat the User with Respect Time Don t waste it Make user feel comfortable Informed consent Tell the user honestly what you are looking for from them Privacy Preserve user s privacy Control the user should be able to stop at any time

29 User Testing Be prepared before the testing Make the user feel comfortable and able to take breaks during the testing After test Inform the user how they have helped you Answer any questions you couldn t answer before the testing Don t publish user identifying information Don t show video or audio without user s consent

30 Formative Evaluation Find some users Should be representative of the target user class, based on user analysis Give each user some tasks Should be representative of important tasks, based on task analysis Watch user do the tasks Roles User think out loud Facilitator brief users, provides tasks, controls sessions, coaches users Observers Be quiet and take notes

31 Heuristic Evaluation

32 Usability Guidelines Heuristics Nielsen s 10 princeiples Norman s rules from Design of Everyday Things Tognazzini s 16 principles. Helps designers choose design alternatives Help evaluators find problems in interface

33 Nielsen Heuristics Match the real world (L) Consistency & standards (L) Help & documentation (L) User control and freedom (S) Visibility of system status (S) Flexibility & efficiency (E) Error prevention (S) Recognition, not recall (S) Error reporting, diagnosis, and recovery (S) Aesthetic & minimalist design

34 Heuristic Evaluation Performed by an expert Steps Inspect UI thoroughly Compare UI against heuristics List usability problems Explain & justify each problem with heuristics

35 How to: Heuristic Evaluation Justify every problem with a heuristic Too many choices on home page (Aesthetic & minimalist Design) Can t just say I don t like the colors List every problem Even if an interface element has multiple problems Go through the interface at least twice Once to get the feel of the system Again to focus on particular interface elements

36 Example

37 Example Shopping cart icon is not balanced with its background whitespace (graphic design) Good: user is greeted by name (feedback) Red is used both for help messages and for error messages (consistency, match real world) There is a problem with your order, but no explanation or suggestions for resolution (error reporting)

38 Example ExtPrice and UnitPrice are strange labels (match real world) Remove Hardware button inconsistent with Remove checkbox (consistency) Click here is unnecessary (simplicity) No Continue shopping button (user control & freedom) Recalculate is very close to Clear Cart (error prevention)

39 Example Check Out button doesn t look like other buttons (consistency, both internal & external) Uses Cart Title and Cart Name for the same concept (consistency) Must recall and type in cart title to load (recognition not recall, error prevention, efficiency)

40 Heuristic Evaluation User Testing Evaluator is not the user either Analogy: code inspection vs. testing HE finds problems that UT often misses Inconsistent fonts Fitts s Law problems But UT is the gold standard for usability

41 User Centered Design

42 Now that we are all experts, lets prototype!