Interac(ve Form: Inspec(on methods. Eva Ragnemalm, IDA

Transcription

1 Interac(ve Form: Inspec(on methods Eva Ragnemalm, IDA

2 2 Interac(ve form 1 Select an informa2on kiosk or machine Describe it s purpose, content and form Perform a cogni(ve walkthrough describe the result in wrieen report and oral presenta2on

3 3 Interac(ve form 2 Select a web-based map service Perform an analysis of it s quali2es in use (according to lecture 3) and describe the result Perform a heuris(c evalua(on and describe the result WriEen report and oral presenta2on

4 4 Goals of usability evalua(on Are we evalua2ng in order to improve the design? Forma2ve evalua2on Focus on describing problems and sugges2ng improvements Are we evalua2ng in order to determine if the prototype/ system fulfills the customer s requirements and can be delivered? Summa2ve evalua2on Focus on measuring proper2es that appear in the requirements

5 5 Type of evalua(on Inspec2on no user involved, employ usability experts User tes2ng set users to interact with the ar2fact or some representa2on of it (prototype) and study Both can be used forma2vely and summa2vely

6 6 When to use what? Applicable tes2ng method vs system representa2on Forma2ve Forma2ve Forma2ve Summa2ve (Forma2ve) Sketches, scenarios, storyboards Paper prototypes Computer prototypes Working system User tes2ng User tes2ng User tes2ng Inspec2on methods Inspec2on methods Inspec2on methods Inspec2on methods

7 7 Inspec(on methods Cogni2ve walkthrough Heuris2c Evalua2on Pluralis2c usability walkthrough (uses users) Ac2on Analysis

8 8 Cogni(ve walkthrough Originally designed for walk-up-and-use systems (such as informa2on kiosks, teller machines etc). Based on the idea that the user has a goal, looks for an ac2on that appears to lead toward that goal, performs the ac2on and evaluates if the result did bring him/her closer to that goal (repeats un2l goal is achieved). Proposed 1990 (C. Lewis, P. Polson, C. Wharton and J. Rieman) revised and extended into several versions Done in a group (developers), or informally, alone.

9 9 Cogni(ve walkthrough method Prepara2ons: Who are the users (what is familiar to them? What do they expect?) Detailed descrip2on of the task (or tasks) to focus List of the correct sequence of ac2ons the task requires For each step in the sequence of ac2ons, analyse if the user is going to find and execute that correct step (and understand that it was correct). tell a believable story (check to see it is believable) if no believable story is found, you have a problem in the design.

10 10 For each step in the correct sequence of ac(ons, tell the story and ask: Will the user be trying to achieve the effect of the step? Will the user no2ce the control (bueon/ac2on/...) is available? If the user no2ces the control, will they understand that it will lead to the desired effect? If the right ac2on is performed, will the user understand that progress is made toward the goal? For any ques2on that is answered in the nega2ve, focus on why not.

11 11

12 12 Result of cogni(ve walkthrough Unbelievable story, doubeul assump2on or ques2on answered in nega2ve indicate problems. List or problems at specified steps in the sequence. The why should provide clues to how to solve it. Examine the assump2ons underlying the story told. Having several experts in a group makes finding assump2ons easier.

13 13 Important Don t combine the finding of the correct sequence of ac2ons into the walkthrough itself! If the walkthrough shows at some step the user won t find the correct ac2on, you drop that problem there and con2nue to the next step as if the previous step had been correct. You are not a user! You may not find everything, and you may find things the user does not find problema2c.

14 14 For Interac(ve Form 1: Decide on a target to inspect. Determine your users, describe them. Select and describe (in detail) the task/tasks you re looking at. Then divide into pairs or triads, perform the analysis (using the ques2ons listed) separately Combine your results for the group report

15 15 Heuris(c Evalua(on Developed by Jacob Nielsen and Rolf Molich 1990 Discount usability engineering Experts are presented with an interface design and inspect it. Requires aggrega2ng the results from 3 to 5 experts Based on Heuris2cs - guidelines or rules of thumb for how to design interac2ve systems

16 16 Heuris(c evalua(on method Select set of heuris2cs to use The usability experts receives the representa2on of the system (prototype/specifica2on/scenario...) Expert explores system to become familiar Expert systema2cally checks system against heuris2cs and notes discrepancies and problems Collect and analyse data

17 17 Nielsen s 10 usability heuris(cs 1. Simple and natural dialogue 2. Speak the user s language 3. Minimize memory load 4. Consistency and standards 5. Provide feedback 6. Provide clear exits 7. Efficiency and shortcuts 8. Good error messages 9. Prevent errors 10.Provide help and documenta2on

18 18 Result: uncovered poten(al problems Situa2ons where the system does not follow the principles ex: loading of screen 3 might take 2me, give feedback to show work is progressing ex: screen 5 is labeled Wri2ng while the associated menu item is called prin2ng. Best results if experts are familiar with the domain as well as the principles. Note 1: all iden2fied problems are not perceived as problems by a user Note 2: The experts will not uncover all problems

19 19 Collec(ng and analysing data Not just number of errors or number of experts finding it Grade problems on: Frequency (how open will the problem occur?) Effect (how difficult is it for the user to cope with) Persistency (is it only a problem the first 2me or every 2me) Degree of seriousness (summa2ve/forma2ve) 0: It is not a problem even though the heuris2c is not followed 1 :cosme2c problem, not necessary to adress unless available 2me 2: lesser problem, low priorty 3: bigger problem, high priority 4:usability catastrophe, must be adressed before release

20 20 How many evaluators to employ?

21 21 Number of evaluators

22 22 Who should do the inspec(on? Heuris2c Evalua2on literature: don t evaluate your own design You already know everything about your own design. If you knew the principles you followed them and if you didn t know them you are not an expert. Cogni2ve walkthrough literature: you can do your own CW keep in mind the goal is to develop your design, not validate: focus on finding things to improve.

23 23 For Interac(ve Form 2 Number of experts=number of group members To become experts: go through the heuris2cs, discuss in groups how to interpret. Agree on what part of the system you are inspec2ng (exactly what screens and what sequence) When inspec2ng: for each screen (and each transi2on between screens) go through all the principles, write down problems (refer to the screen and the principle) Aggregate the problems found and grade

24 24 Research project: Heuris(c evalua(on of persuasive capacity of solware Design of persuasive systems (behaviour-change systems) help people exercise more, eat healthier, stop smoking etc Guidelines for persuasive systems developed by BJ Fogg (2005) ex: be trustworthy, correct, 2mely, provide sugges2ons, assess the user s behaviour, make it easy to do the right thing... Educa2onal systems that people do learn from must be persuasive! Then: Is a game persuasive? A computer tool like Word? Yes, some are!

25 Ques2ons?