ITU: Usability med projekt i brugercentreret design, for å r 2008 v/ Egil Boisen

1. Kravsspecifikationer:Fokus på brugernes behov/ aktiviteter ~ CHAT og use case-beskrivelserd. 20/2-08 ITU: Usability med projekt i brugercentreret design, forår 2008 v/ Egil Boisen

2. Van’t Riet-moralen: Undersøg først brugernes behov

3. van’t Riet: Amblyopia i Rotterdam • Amblyopia kræver klap for øjet, 2-4 års alderen • Produkt: CD-ROM + web: QA, newsletter, tegneserie, spil og chat mellem forældre 1 time ugentl kl. 19 – 20. • Kvalitativ undersøgelse af 14 familier • Ingen problemer med ’coping’, ’anxiety’, komplians. • Ingen blev drillet • Produktet svarede til 7-års alderen • Kl.19-20 = rush hour! Chat ml. forældre er overkill => Ønske om asynkron mailliste med PRO. • Men: basalt set sympatisk projekt. • Projektet blev lukket efterfølgende.

4. van’t Riet: tre hovedpointer • Undersøg først brugeres behov • I eksemplet implementerede udviklerne deres fejlagtige fordomme. • Brug kvalitative metoder hertil. • ’hard data’ lukker erfaringsrummet ift. prædefinerede spørgsmål. • Et patientinformationssystem behøver ikke at have kliniske resultater som succeskriterie, hvis det forbedrer aspekter som ’trust’ eller ’anxiety’.

5. van’t Riet: operationalisering af evalueringsspørgsmål The starting question of the Eye Hospital had been to investigate whether this information system would improve the quality of delivered care—as measured by the effectiveness and efficiency of the system, and the patients’ satisfaction in using it. These three key aspects, often used as the core dimensions of the quality of care [17], are by themselves rather indefinite terms, requiring operationalization. The aspects ‘effectiveness’ and ‘efficiency’ were each made operational by selecting indicators that were expected to be affected by the introduction of the system. These indicators covered different dimensions of these key aspects (for the selected indicators per key aspect see Figs. 1– 3). Some of the indicators were drawn from documents stating the Eye Hospital’s own expectations about the system [12,18]; other indicators were added by the researchers on the basis of our initial experiences with the system (through the initial observations). The kind of indicators we selected are common in evaluation studies of patient information systems [1,19–21].

6. Effectiveness ..

7. .. efficiency ..

8. .. and patient satisfaction

9. van’t Riet: Kvalitativt ‘pilot study’ Qualitative research is primarily inductive and explorative in its procedures; it is therefore perfectly suited in situations such as these, where the natureof the impacts are to be investigated, and where the question why, and on which dimensions, the patient information system would be (un)successful is of paramount importance [13–16]. The research consisted primarily of in-depth interviews with users of the patient information system.

10. Different kinds of requirements • Functional • Use case-beskrivelser • UML • Data • UML • Environment • physical • social • organizational • technical • User characteristics • Personaer (se eksempel s.484-5) • Usability/ user experience goals PRS, 2007

11. CHAT-moralen: Undersøg først brugernes ‘virksomheder’: psykologiske/ menings-kontekst

12. CHAT • Cultural Historical Activity Theory (CHAT) • three principles • mediation… • activity aspects… • development… • Core inspiration: Engeström (1990) • ‘types of artefacts’ and learning …

13. x o s CHAT: mediation A model of the principle of mediation, adapted from Vygotsky 1978, p.41.

14. CHAT: aspects of activity activity ~ motive  ↓  ↓ action ~ goal  ↓  ↓ operation ~ condition Three aspects of activity (as illustrated by Kuutti, 1996)

15. artefact subject object rules community division of labor CHAT: development Engeström’s expanded model of the structure of human activity systems for analysing contradiction, which are seen as chances of focused development of the system: ‘expansive learning’ (Engeström 1987, p.78).

16. Artefacts and learning levels (eb)

17. Use case-moralen: Hvilken værdi tilfører systemet for hvilke aktører?Og hvordan?

18. Begrebet Use case UML 2 Toolkit, 2004: • Use case modeling describes what a system does to benefit users [..] the functionality the system should deliver, as perceived external actors. • en use case giver en håndgribelig, gerne fokal, værdi for en aktør • er altid initieret af en aktør • en use case er komplet: ikke bare en del-funktion, men en meningsfuld helhed – eksempelvis at købe en billet (men ikke hele biografturen). Fowler, 2000: • Use case: a set of scenarios tied together by a common user goal. • A snapshot of one aspect of your system. The sum of all use cases is the external picture of your system, explaining what it will do. • Central to understanding what your users want; an essential tool in requirements capturing; one of the primary tasks in the elaboration phase. • Backbone of the development process.

19. Begrebet aktør • Aktør: • en use case er altid initieret af en aktør, i form af • en rolle, en type, ikke en instans • omfattende brugere eller andre systemer, • der har de samme brugsmønstre ift. systemet, • og får opfyldt et mål/ opnår en værdi herved.

20. Eksempel: sygehus-afd. Vendelhaven, 2002, s.72

21. Begrebet scenario • A scenario: a sequence of steps describing an interaction between a user and a system. (Fowler, 2000)

22. Third scenario? New use case ? Eksempel: Køb bog på nettet Buy a Product • Customer browses through catalog and selects items to buy • Customer goes to check out • Customer fills in shipping information (address; next-day or 3-day delivery) • System presents full pricing information, inclding shipping • Customer fills in credit card information • System authorizes purchase • System confirms sale immediately • System sends confirming email to customer Alternative: Authorization Failure At step 6, system fails to authorize credit purchase Allow customer to re-enter credit card information and retry Alternative: Regular Customer 3a. System displays current shipping information, princing information, and last four digits of credit card information 3b. Customer may accept or override these defaults. Return to primary scenario at step 6 (Fowler, 2000)

23. Begrebet Use case (2) • Begrebet use case definere nogle steder som beskrivende en sekvens af steps (eksempelvis Vendelhaven, 2002), men… Fowler, 2000: • a set ofscenarios tied together by a common user goal. • A snapshot of one aspect of your system. The sum of all use cases is the external picture of your system, explaining what it will do. • Central to understanding what your users want; an essential tool in requirements capturing; one of the primary tasks in the elaboration phase. Eriksson et al.: UML 2 Toolkit, OMG, 2004: Use case modeling • ’a set of sequences of actions a system performs that yield an observable result of value to a particular actor.’ • Læg mærke til udtrykket ’set of sequences’, ’et sæt af sekvenser’, og ikke bare ’en sekvens’ – der gemmer sig et ’spring i logisk type’ her, ligesom mellem ’klasse’ og ’objekt’ som instantiering af klassen. • en use case er komplet: ikke bare en del-funktion, men en meningsfuld helhed – eksempelvis at købe en billet (men ikke hele biografturen).

24. ‘Solskinsscenarie’ • Det scenarie hvor alting kører som skal. • Vendelhaven, 2002

25. Identificer use cases • Interviews med brugerne: • use cases skal angå ’business’ og ikke ’system’ (Fowler, 2000). • spørg om arbejdsopgaver; hvordan afgrænses de ift. hinanden og hvem udfører de enkelte opgaver; hvad er resultatet af opgaverne. • mønstre udspringer af behov og vilkår i anvendelsesområdet, mens mønstret er et løsningsforslag, en eksperimentel aktivitet. De kommende brugere bidrager med indsigt i anvendelses-området, mens udviklerne formulerer mønstre og bidrager med teknisk indsigt. (Mathiassen et al, 1997). • At tage udgangspunkt i: • aktører: Det kan være en hjælp at starte med en liste af aktører der benytter sig af et system, og dernæst lave en liste over use cases for hver aktør: hvilke funktioner skal systemet tilbyde disse aktører? (UML 2 Toolkit 2004; Fowler, 2000; Mathiassen et al, 1997) • hændelser: tænk på alle de eksterne hændelser som systemet skal reagere på (Vendelhaven, 2002; Mathiassen et al, 1997)

26. Identificer aktører • identificer forskellige roller ift. systemet/ forskellighed i formål med at bruge systemet. • aktøren ’kontohaver’ kan desuden opdeles i forskellige kundetyper. • tips: • Fowler: ’As long as I get all the use cases, I’m not worried about the details of the actors.’ • Fowler: ’always question use cases with system actors, find out who the real users are, and consider alternative ways of meeting those goals.

27. Andre nyttige begreber • Hand-offs • indenfor en use case bør der ikke være hand-offs, dvs. situationer hvor ‘bolden’ ligger stille. (Dette bruges som princip for analysen af use casens scope, eb). • Vendelhaven, 2002 • Levels: sky – kite – sea – fish – clam • Cockburn, 2001 • Stakeholders and interests • Cockburn, 2001

28. Cockburn: om use cases • Use cases: contracts for behavior • requirements: they accurately detail what the system must do (not all the requirements) • A project-linking structure (requirements for): performance, UI, business rules, data formats • Essentially a prose essay – make it easy to read • Three goal levels: sky – sea – underwater • Sea level: at kunne gå ud og tage en kop kaffe-testen • Ask ‘why’ to shift levels upwards – ask ‘how’ to shift levels downwards (an ever-unfolding story) • Tips til processen/ analysen • Warm up with a usage narrative (ét enkelt scenarie) • Manage your energy: Work breath first: Start sketchy, gå dernæst mere i dybden • Four stages of precision • Actors and goals • Use case brief/ main scenario • Failure conditions: Brainstorm all failures to main success scenario • Failure handling: alternative scenarier/ extensions • Tre principper for hver eneste sætning: • Scope: what is really the system under discussion? • Primary actor: who has the goal? • Level: how high- or low-level is that goal? • Preconditions: what must be true before and after the case runs • Action steps: guidelines

29. Use case as a contract Contract: actors (goals) and stakeholders (interest) • The system under discussion is a mechanism to carry out a contract between various stakeholders. Use cases provide the behavioral part of that contract. Every sentence is there because it describes an action that protects or furthers some interest of some stakeholder. A sentence must describe an interaction between two actors or what the system must do internally to protect the stakeholders’ interest. • The actors and goals model explains how to write sentences in the use case (detailing the behavioral aspect of the contract)…

30. Cockburns use case niveauer Why? How?

31. Cockburns action steps: guide lines (excerpt) • Use simple grammar • System .. deducts.. the amount.. for the account balance • At each step one actor has the ball (the message) - Who has the ball? • Write from bird’s eye view: • ikke set fra systemets synspunkt: ‘the system deducts’, ikke ‘deduct’ • Show actors intent, not movements • ‘User hits tab key’ (why? To get to the address field) • Include a reasonable set of actions (s.94)

32. Use case diagram • Use case relationer • Generalization: f.eks. hvis ’Regular Customer’ er en selvstændig, specialiseret use case baseret på ’Buy a Product’ (en stamkunde får ’det sædvanlige’ og ikke remsen om muligheder) … • Extend: en betinget funktion der giver en selvstændig værdi (ex: hvis en gæst ankommer regnvåd, hænges overtøjet til tørre) … • Include: hvis en funktion kan genbruges af andre use cases (når der arrangeres frokosttallerken og efter rengøring vaskes der hænder). … • Hvor mange use cases pr. system? • 12 base use cases for a 10-person year project (op mod 100 scenarier) (Fowler, 2000)

33. Use case relationer (UML) generalization generalization extend include

34. Use case-opgave: kritisér • systemet viser de indkomne henvisninger, og afdelingssygeplejerske-aktøren ’modtager’ en henvisning ved at ’se’ den (gå ind og læse dens oplysninger), hvilket registreres. Henvisningen indeholder oplysninger om patienten (hvilke er tilstrækkelige her?) og overlægens anvisninger. • afdelingssygeplejersken foretager søgning (evt. ud fra søgekriterier) angående de påkrævede ressourcer til denne ydelse i form af en tid (dato og klokkeslæt), lokale og personaleressource samt evt. apparatur. (Dette step kunne indeholde en række parallelle steps, men det kan også være at afdelingen mener at det skal være efter en særlig sekvens, hvilket skal afklares). Systemet viser en række alternativer. Afdelingssygeplejersken vurderer hvilket alternativ er bedst egnet og godkender dette, hvilket registreres som en bekræftelse af bookingen. Extension point: patientens ressourcepræferencer (angående tid og personale). • afdelingssygeplejersken kontrollerer om der er brug for booking af flere ydelser til pågældende patient. I så fald gås til step 2. Ellers gås til step 4. • afdelingssygeplejersken genererer på baggrund af denne bookingprocedure en indkaldelse, som kan sendes afsted til patienten. Indkaldelsens oplysninger kontrolleres af afdelingssygeplejersken og godkendes til afsendelse, hvilket registreres i systemet med dato. • afdelingssygeplejersken sender indkaldelsen afsted til patienten via mail.

35. Use case-opgave • Beskriv en aktivitet fra egen hverdag, eksempelvis det at benytte kursusbasen, i form af: • En række aktører og deres use cases • en eller to sætninger pr. use case der beskriver hvad use casen tjener til (værdi for en aktør) • en liste af steps der beskriver dens forløb (solskins-scenariet), herunder evt. alternative scenarier.