2. Litteratur
Cooper, Alan: “The Inmates are running the Asylum”, SAMS, 1999, pp.
123-177
Carroll, John M. “Five reasons for Scenario-Based Design”, Proceedings of
the 32nd Hawaii International Conference on System Sciences – 1999http://
ieeexplore.ieee.org/iel5/6293/16783/00772890.pdf
Nielsen, Lene: “From user to character – an investigation into user-
descriptions in scenarios”, http://portal.acm.org/citation.cfm?
id=778729&dl=acm&coll=&CFID=15151515&CFTOKEN=6184618
Bertelsen, O. W. (2004). Activity Walkthrough: an Expert Review Method
Based on Activity Theory. In Proceedings of NordiCHI 2004. (short paper)
http://portal.acm.org/citation.cfm?id=1028052
tirsdag den 20. oktober 2009
4. Usability - Jordan
“how easy a product is to use”
“user-friendliness of products”
“the effectiveness, efficiency and satisfaction with which specified users can
achieve specified goals in particular environments”
Jordan, Patrick W.: An Introduction to Usability, Taylor & Francis Ltd, 1998,
pp. 5-23.
tirsdag den 20. oktober 2009
5. Activity Walkthrough
• Cognitive walkthrough + activtity theory
• Olav W. Bertelsen and Susanne Bødker: “Activity Theory” in Carroll , J.M.
(ed.). HCI Models, Theories, and Frameworks: Toward an Interdisciplinary
Science. Morgan Kaufman Publishers, 2003.
tirsdag den 20. oktober 2009
6. Cognitive Walkthrough
0. The user starts with a rough plan of what he or she wants to
achieve – a task to be performed
1. The user explores the system, via the user interface, looking for
actions that might contribute to performing the task
2. The user selects the action whose description or appearance
most closely matches what he or she is trying to do
3. The user then interprets the system’s response and assesses
whether progress has been made towards completing the task
tirsdag den 20. oktober 2009
7. Cognitive Walkthrough
Konkret foretages analysen ved at stille følgende spørgsmål:
Spørgsmål til identificering af opgaven
0. Hvad ønsker brugeren at opnå?
Vil brugeren forsøge at opnå den korrekte effekt?
Walkthrough
1. Vil brugeren opdage, at den korrekte handling er mulig?
2. Vil brugeren associere den korrekte handling med opgavens formål?
3. Vil brugeren vide, om den valgte handling er korrekt eller forkert ud fra
systemets respons?
tirsdag den 20. oktober 2009
8. Activity theory
Menneskelige aktiviteter (virksomheder (menneskeligt virke)) som et
komplekst, socialt situeret fænomen
Den skandinaviske usability skole
tirsdag den 20. oktober 2009
9. Activity Walkthrough
• Mere kompleks end CW
• For kompleks eller blot omstændelig?
• Indrømmet problem med utålmodige, rodede testpersoner
tirsdag den 20. oktober 2009
10. Contextualization
• motivation
• identificer alle handlinger der bidrager...
• historiske generationer
• andre medieringer
• erfaringer
tirsdag den 20. oktober 2009
11. Contextualization
• overordnet: Web of activities
• mediator: web of activities
• historical development of the web of activities
tirsdag den 20. oktober 2009
12. Activity Walkthrough
• Er tasks, actions, handlinger, opgaver og ‘virksomheder’ altid målrettede?
• http://cult.diesel.com/
• http://www.bonaparte.dk/
• Kan artefakter/websites have andre mål end en løsning af opgaven?
• http://www.youtube.com/watch?v=o2KBo6dy8FY
tirsdag den 20. oktober 2009
15. Hvad er personas?
• Persona-begrebet er udviklet i 1999 af den amerikanske
systemudvikler og interaktionsdesigner Alan Cooper
14
tirsdag den 20. oktober 2009
16. Hvad er personas?
• Persona-begrebet er udviklet i 1999 af den amerikanske
systemudvikler og interaktionsdesigner Alan Cooper
• Begrænset mængde forskning og litteratur om emnet
14
tirsdag den 20. oktober 2009
17. Hvad er personas?
• Persona-begrebet er udviklet i 1999 af den amerikanske
systemudvikler og interaktionsdesigner Alan Cooper
• Begrænset mængde forskning og litteratur om emnet
• Cooper: “hypotetiske arketyper af virkelige brugere”
14
tirsdag den 20. oktober 2009
18. Hvad er personas?
• Persona-begrebet er udviklet i 1999 af den amerikanske
systemudvikler og interaktionsdesigner Alan Cooper
• Begrænset mængde forskning og litteratur om emnet
• Cooper: “hypotetiske arketyper af virkelige brugere”
• En persona er en konstrueret og udfoldet stereotyp, som i
kraft af sin "gennemsnitlighed" fungerer som stand-in for
virkelige brugere i udviklingen og evalueringen af fx websites
14
tirsdag den 20. oktober 2009
20. Motivation for personas
• Samme argument som for andre brugertests, usability-
metoder mv.: udvikler ≠ bruger
15
tirsdag den 20. oktober 2009
21. Motivation for personas
• Samme argument som for andre brugertests, usability-
metoder mv.: udvikler ≠ bruger
• Fordel med ekspliciteret bruger
15
tirsdag den 20. oktober 2009
22. Motivation for personas
• Samme argument som for andre brugertests, usability-
metoder mv.: udvikler ≠ bruger
• Fordel med ekspliciteret bruger
• Specielt for personas:
• Nemt at identificere sig med (da personas ~ virkelige mennesker)
• Fælles referenceramme for udviklingsteam.
15
tirsdag den 20. oktober 2009
24. Eksempel
Emma Aragon:
http://www.webwritingthatworks.com/FRantPROBE01.htm0
Bob:
http://www.steptwo.com.au/papers/kmc_personas
Joe Sixpack
http://www.cooper.com/journal/2008/10/joe_six_pack_is_not_a_persona.html
17
tirsdag den 20. oktober 2009
28. Umiddelbare fordele ved personas
• Fokus på brugere og anvendelsessammenhæng
20
tirsdag den 20. oktober 2009
29. Umiddelbare fordele ved personas
• Fokus på brugere og anvendelsessammenhæng
• Ekspliciterer antagelser (og eventuelle fordomme) om målgruppen
20
tirsdag den 20. oktober 2009
30. Umiddelbare fordele ved personas
• Fokus på brugere og anvendelsessammenhæng
• Ekspliciterer antagelser (og eventuelle fordomme) om målgruppen
• Kommunikationsmedie
20
tirsdag den 20. oktober 2009
31. Umiddelbare fordele ved personas
• Fokus på brugere og anvendelsessammenhæng
• Ekspliciterer antagelser (og eventuelle fordomme) om målgruppen
• Kommunikationsmedie
• Konsensus om:
• slutmål for anvendelsen
• nødvendig funktionalitet og information
• passende (ikke laveste) fællesnævner
20
tirsdag den 20. oktober 2009
32. Designproces
personas
Behovsafklaring Analyse Design Implementering
Prototype
21
tirsdag den 20. oktober 2009
34. Andre fordele…
• Behov fremfor ønsker (faktisk anvendelse)
22
tirsdag den 20. oktober 2009
35. Andre fordele…
• Behov fremfor ønsker (faktisk anvendelse)
• Prioritering af udviklingsopgaver
22
tirsdag den 20. oktober 2009
36. Andre fordele…
• Behov fremfor ønsker (faktisk anvendelse)
• Prioritering af udviklingsopgaver
• Kan anvendes løbende i designprocessen
22
tirsdag den 20. oktober 2009
37. Andre fordele…
• Behov fremfor ønsker (faktisk anvendelse)
• Prioritering af udviklingsopgaver
• Kan anvendes løbende i designprocessen
• Kan anvendes tidligt i processen (evt. uden en prototype)
22
tirsdag den 20. oktober 2009
46. Konstruktion af personas
1. Konstruer en persona pr. målgruppe/forskellig bruger
(mange, typisk > 10 personas)
24
tirsdag den 20. oktober 2009
47. Konstruktion af personas
1. Konstruer en persona pr. målgruppe/forskellig bruger
(mange, typisk > 10 personas)
2. Reducer antallet ved at sammenflette personas med
fælles mål samt ekskludere ubetydelige/sjældne
personas.
(fx 5-10 personas)
24
tirsdag den 20. oktober 2009
48. Konstruktion af personas
1. Konstruer en persona pr. målgruppe/forskellig bruger
(mange, typisk > 10 personas)
2. Reducer antallet ved at sammenflette personas med
fælles mål samt ekskludere ubetydelige/sjældne
personas.
(fx 5-10 personas)
3. Identificer centrale (primære) personas
(typisk 1 – måske 2/3)
24
tirsdag den 20. oktober 2009
50. Persona-typer
Coopers inddeling:
25
tirsdag den 20. oktober 2009
51. Persona-typer
Coopers inddeling:
• Primære personas
Dem vi skal designe til.
25
tirsdag den 20. oktober 2009
52. Persona-typer
Coopers inddeling:
• Primære personas
Dem vi skal designe til.
• Sekundære personas
Dem vi bør designe til.
25
tirsdag den 20. oktober 2009
53. Persona-typer
Coopers inddeling:
• Primære personas
Dem vi skal designe til.
• Sekundære personas
Dem vi bør designe til.
• Negative personas
Dem vi ikke designer til.
25
tirsdag den 20. oktober 2009
55. Forskellige persona-typer
• Focal – Primary users of the product who are its main focus. We will optimize
design for them. At least one persona must be a focal persona.
26
tirsdag den 20. oktober 2009
56. Forskellige persona-typer
• Focal – Primary users of the product who are its main focus. We will optimize
design for them. At least one persona must be a focal persona.
• Secondary – Also use the product. We will satisfy them when we can.
26
tirsdag den 20. oktober 2009
57. Forskellige persona-typer
• Focal – Primary users of the product who are its main focus. We will optimize
design for them. At least one persona must be a focal persona.
• Secondary – Also use the product. We will satisfy them when we can.
• Unimportant – Low-priority users, including infrequent, unauthorized or
unskilled users, as well as those who misuse the product.
26
tirsdag den 20. oktober 2009
58. Forskellige persona-typer
• Focal – Primary users of the product who are its main focus. We will optimize
design for them. At least one persona must be a focal persona.
• Secondary – Also use the product. We will satisfy them when we can.
• Unimportant – Low-priority users, including infrequent, unauthorized or
unskilled users, as well as those who misuse the product.
•
Affected – They don’t use the product themselves, but are affected by it (for
example, someone who gets reports from a user of a application, or the
spouse of someone using a travel Website to plan a trip).
26
tirsdag den 20. oktober 2009
59. Forskellige persona-typer
• Focal – Primary users of the product who are its main focus. We will optimize
design for them. At least one persona must be a focal persona.
• Secondary – Also use the product. We will satisfy them when we can.
• Unimportant – Low-priority users, including infrequent, unauthorized or
unskilled users, as well as those who misuse the product.
•
Affected – They don’t use the product themselves, but are affected by it (for
example, someone who gets reports from a user of a application, or the
spouse of someone using a travel Website to plan a trip).
•
Exclusionary – Someone we’re not designing for. It’s often useful to specify this
to prevent nonusers from creeping back into product development
discussions.
http://www.boxesandarrows.com/view/
making_personas_more_powerful_details_to_drive_strategic_and_tactic 26
tirsdag den 20. oktober 2009
62. Coopers persona-begreb
• Personas defineres af deres mål
• og målene defineres af personaen
27
tirsdag den 20. oktober 2009
63. Coopers persona-begreb
• Personas defineres af deres mål
• og målene defineres af personaen
• iterativ proces
27
tirsdag den 20. oktober 2009
64. Coopers persona-begreb
• Mål:
• Praktiske - løse opgaven
• Personlige - tilfredsstillelse, bekræftelse, (undgå at kede sig og føle sig
dum osv.
• Corporate – i relation til arbejdspladsen; overordnede, mere vage eller
abstrakte end praktiske. Fx arbejdspladsens økonomi, markedsandele osv.
• Falske – fokus på midler - gerne tekniske/udformningsmæssige detaljer i
stedet for mål.
28
tirsdag den 20. oktober 2009
65. Et rimeligt udbytte…
The Principle of Commensurate effort
• Gensidighed i forholdet mellem artefakt og bruger. Hvis artefaktet giver
brugeren en bekræftelse på brugerens evner (udbyttet står mål med
indsatsen), vil brugeren investere mere engagement, tid, energi i artefaktet.
Det er altså vigtigt at brugerens personlige mål aldrig bliver krænket.
• emotive relationship
29
tirsdag den 20. oktober 2009
69. Typer i flg. Cooper
33
tirsdag den 20. oktober 2009
70. Typer i flg. Cooper
• Daily Use Scenarios
33
tirsdag den 20. oktober 2009
71. Typer i flg. Cooper
• Daily Use Scenarios
• Necessary Use Scenarios
33
tirsdag den 20. oktober 2009
72. Typer i flg. Cooper
• Daily Use Scenarios
• Necessary Use Scenarios
• Edge Case Scenarios
33
tirsdag den 20. oktober 2009
73. Typer i flg. Cooper
• Daily Use Scenarios
• Necessary Use Scenarios
• Edge Case Scenarios
• Eksempel: http://www.dr.dk/nyheder/vejret/
33
tirsdag den 20. oktober 2009
75. Scenarier
• Scenarier som en videreudvikling af personaer
34
tirsdag den 20. oktober 2009
76. Scenarier
• Scenarier som en videreudvikling af personaer
• Scenariet som
• Brugssituation
• Miljøbeskrivelse
• Arbejdsbetingelser
• Interviews med brugere
34
tirsdag den 20. oktober 2009
78. Finpudsning (v. Goodwin)
• Personas repræsenterer adfærdsmønstre – ikke
jobbeskrivelser!
35
tirsdag den 20. oktober 2009
79. Finpudsning (v. Goodwin)
• Personas repræsenterer adfærdsmønstre – ikke
jobbeskrivelser!
• Minimer antallet af personas
35
tirsdag den 20. oktober 2009
80. Finpudsning (v. Goodwin)
• Personas repræsenterer adfærdsmønstre – ikke
jobbeskrivelser!
• Minimer antallet af personas
• Måske er målgruppe ≠ personas?
35
tirsdag den 20. oktober 2009
81. Finpudsning (v. Goodwin)
• Personas repræsenterer adfærdsmønstre – ikke
jobbeskrivelser!
• Minimer antallet af personas
• Måske er målgruppe ≠ personas?
• Tilføj livagtighed/karaktertræk
35
tirsdag den 20. oktober 2009
82. Finpudsning (v. Goodwin)
• Personas repræsenterer adfærdsmønstre – ikke
jobbeskrivelser!
• Minimer antallet af personas
• Måske er målgruppe ≠ personas?
• Tilføj livagtighed/karaktertræk
• Ha’ 3-4 mål pr. persona – og fortrinsvis ”end
goals” (”anvendelsesresultatmål”). I modsætning til
”experience goals” (brugeroplevelsesmål) og især ”life
35
tirsdag den 20. oktober 2009
84. Andre (gode) råd
• Brugere er ikke elastiske – det er softwaren, der skal være elastisk!
36
tirsdag den 20. oktober 2009
85. Andre (gode) råd
• Brugere er ikke elastiske – det er softwaren, der skal være elastisk!
• Hellere 10 % ”ekstatiske” brugere end 50 % nogenlunde tilfredse.
- Større succes i at designe til én bruger end en (alt for) bred målgruppe
36
tirsdag den 20. oktober 2009
86. Andre (gode) råd
• Brugere er ikke elastiske – det er softwaren, der skal være elastisk!
• Hellere 10 % ”ekstatiske” brugere end 50 % nogenlunde tilfredse.
- Større succes i at designe til én bruger end en (alt for) bred målgruppe
• Gælder det for websites?
36
tirsdag den 20. oktober 2009
