Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
110 Cards in this Set
- Front
- Back
|
Beskriv användbarhet
|
Finns en del mål som bör uppnås avseende användbarhet/usability, dessa är:
Effectiviness/effektivitet: hur bra gör systemet det den ska göra. Efficiency/effektivitet: hur bra gör användarna det de vill att systemet ska göra, dvs hur lätt är det att utföra uppgifterna. Safety/säkerhet: hur säker är den att använda/robushet det går inte åt skogen när man använder den. Learnablity/lättlärd: enkelt att lära Lät att minnas/memorability: lätt att komma ihåg hur man använder |
|
|
vad är användarens förväntan av ett system?
|
Det bör vara:
• Tillfredställande • Roligt • Underhållande • Motiverande • Estetics • Ge hjälp till kreativitet • Belönande |
|
|
Användbarhetsprinciper (kort)
|
ungefär som design principer. dock mer lämplig som bas vid utvärdering av system.
|
|
|
Användbarhetsprinciper (lång 9 punkter)
|
systemets Status är SYNLIG
Analogier mellan verkliga värden och systemets användaren har kontroll och frihet systemet är konsistent följer standards hjälper användaren komma ur fel hindrar att fel uppstår flexibelt och lätt att se hur det ska användas estetisk och minimalisk design bra hjälp och dokumentation |
|
|
Skillnad mellan designprinciper och användbarhetsprinsiper
|
användbarhetsprinciper: ett steg framåt, och nu. hjälpa användare komma ur fel
lättare att ställa frågor till |
|
|
Design principer: (6 punkter)
|
Synbarhet.
Återkoppling/feedback begränsningar matchning konsistens igenkänning |
|
|
DP: Synbarhet
|
Hur synlig informationen är, att det är enkelt och tydlig ser vad funktionen är till för och i vilken ordning man ska göra det.
|
|
|
DP: Återkoppling/feedback
|
hur lätt man ser i vilket tillstånd man befinner sig i, samt får information om ad som händer. Utan information känner man sig hjälplös (trycker och trycker väntar på att något ska hända). Skickar tillbaka information om vad som har hänt (ljud, visuellt, verbalt, kroppspråk)
|
|
|
DP: begränsningar
|
Hindrar användaren från att göra saker den inte ska kunna göra för tillfället. Fysiska (CD & DVD skiva inte kan stoppas in på vilket sätt som helst) Logiska (relationer mellan vardagslivet och utformning av interface. Vissa kulturella (symboler) olika färg på kontakt till mus/tangentbord. Minskar effekten av att användaren gör ett felaktigt val.
|
|
|
DP: matchning
|
relationer mellan kontroller bör motsvara dess verkliga relationer (piltangenter, bandspelare) dessa leder oftast till igenkänning
|
|
|
Konsistens/consistency:
|
Gör saker på samma sätt överallt, alltid använder vänster musknapp för att markera något. Det blir lättare att komma ihåg vad man ska göra vilket leder till att gränssnittet blir lättare att använda.
|
|
|
igenkänning/affordance
|
ser hur man ska använda interfacet (scrollbars, iconer)
|
|
|
användbarhet: Effectiviness/effektivitet:
(efficiency, safety, enkelt att lära, enkelt att komma ihåg) |
hur bra gör systemet det den ska göra
|
|
|
användbarhet: Efficiency/effektivitet:
|
hur bra gör användarna det de vill att systemet ska göra, dvs hur lätt är det att utföra uppgifterna.
|
|
|
användbarhet: Safety/säkerhet
|
hur säker är den att använda/robushet det går inte åt skogen när man använder den.
|
|
|
användbarhet: Learnablity/lättlärd:
|
enkelt att lära
|
|
|
användbarhet: Lätt att minnas/memorability:
|
lätt att komma ihåg hur man använder
|
|
|
Kognitiva aspekter (5 punkter)
|
attention, fokus
perception & recognition, perception & igenkännande memory, minne reading, speaking & listening, läsa, tala och lyssnande problemlösning, planering resonerande, beslutstagande & lärande |
|
|
3 viktigaste inom kognitiva aspekter
|
attention (fokus), perception (perception) och memory (minne)
|
|
|
KA: attention, fokus (vad hur, beror på)
|
ska vara på det viktigaste bland massa val. titta på det som intresserar oss. gränsnittet strukturerat så att det väcker användarens fokus på det viktigaste (fönster, färger, ljud & blinkningar)
vad beror på mål, kan bero på hur vi presenterar informationen. hur vi sorterar informationen |
|
|
KA: fokus (med design)
|
utmärk det som är viktigt att användaren ser (sortering och färger)
ändra fokus med understurkningar ljus och färger. enkla animeringar som väcker fokus när det behövs (ej interface fulla med färger blinkningar och animeringar) |
|
|
KA: perception
|
process om hur information tas från omgivningen och omvandlas till gestalnitning av objekt händelser smak osv.
seende viktigaste, följt av hörande och känsel. |
|
|
KA: problemlösning, planering, resonering och beslutstagande
|
Man funderar över vad man skall göra, vilka val man har, och vilka konsekvenser ett val får. Medvetna processer.
|
|
|
KA perception (och design)
|
viktigt att iconer och dylikt är lött utskiljbara ser vad som tillhör vad.
ljud måste man förstå vad det är kopplat till text måste vara lätt utskiljbart från bakgrunden |
|
|
KA: (Synen)
|
Ljus: vid mörker tar stavarna över och vi ser bättre utanför fokus. Med mer ljus ökar skärpan. Men mer ljus ger flimmer, framförallt vid vinkel
Färg: färg (våglängd) intensitet (ljusstyrka) mättnad (andelen vitt) Vi kan se 7 miljoner färger, men avgöra skillnader mellan 10 Vi har tre typer av koner som känner av röd, grön och blå färg. Människan är väldigt bra på att fylla information i det vissuella. Vi ser figurer som inte helt finns där. Samtidigt är det väldigt lätt att bli lurad och se synvillor beroende på hur man presenterar inför. |
|
|
KA: Perception (Hörseln)
|
Är undervärderat
Vi är bra på positions avgörande och hörseln kan användas som komplement till synen (övergångsställen, rätt och fel) |
|
|
KA: (Känsel)
|
Används lite idag
Används med fördel t.ex. vid knapptryckningar för att få feedback om de är tryckta Används även i VR och vibratorer i kontroller till TVspel |
|
|
KA: Minne
(attention/fokus, perception & recogranation, memory, reading speaking and listering, problemlösning, planering, resonareande och besluttagande samt lärande) |
Involverar att komma ihåg olika typer av kunskaper
Vi kommer bara inte ihåg allt utan vi filtrerar Kontext eller omgivning är viktigt hur vi kommer ihåg kunskap Vi känner igen saker bättre än vad vi kommer ihåg Vi har ett bra visuellt minne och kommer lättare ihåg bilder än ord. Sensoriskt minne: är en storts minne i et sensoriska systemet, temporär lagring. Hörsel, syn, ljudsignal. Kotrttids minne: korttids eller arbetsminne. Kan hålla reda på 7+-2(5-9= saker i korttidsminnet samtidigt. Säger inte så mycket om design Långtidsminne: det är mer permament minne. Strukturerar organiserat. |
|
|
KA: Minne (och design)
|
Ge inte för komplicerade funktioner med många steg som gör det svårt att kommer ihåg
Föredra igenkännande framför ihågkommande. Ikoner osv. |
|
|
Mentala modeller (ramverk för kongnitiva aspekter)
|
Mentala modeller är interna konstruktioner om hur världen ser som gör det möjligt att förutse
Innefattar både medvetna och icke medvetna processer Man skiljer på djupa och grunda modeller (ex. vet hur en bil fungerar vs köra bil) Dock kan dessa modeller bli helt fel Om du ska värma upp ugnen till 200 grader sätter du tempel på 300 då för att hoppas på det går snabbare vilket det inte gör Hur många gånger trycker man på en hissknapp även fast den lyser Det är alltså viktigt att anv. får en korrekt mental modell om systemet/interfacet Dock är många tveksamma till att studera manualer och dokumentation Det är alltså viktigt med bra feedback Lättförståeliga interface Bra online hjälp och tutorials |
|
|
KA: reading, speaking and listening
|
Alla sätt att använda språk. Vissa har lättare att hantera vissa sorter.
|
|
|
KA: problemlösning, planering, resonerande, beslutstagande & lärande --> LÄRANDE
|
Kan tänkas kring i två aspekter: Hur man använder en applikation eller användandet av en datorbaserad applikation för att förstå ett ämne. Interaktivitet underlättar lärandet.
|
|
|
KA: problemlösning, planering, resonerande, beslutstagande & lärande --> Förstå problemet
|
vad vill du skapa vad är dina antaganden om anvädnarna, kommer systemet att klara dina krav?
|
|
|
Donald normans modell (6 punkter)
|
användaren skaffar sig ett mål,
formulerar intentioner (vad de ska få ut av systmet, specificierar hur de ska ager i gränssnittet för att nå fram till sina mål. De agerar, och uppfattar den information de får. För att sedan tolka den. Utvärderar sist systemets status utifrån målet. |
|
|
Donald normans modell (kort)
|
Sammankopping mellan design, system och användare
Process från användaren får ett mål tills dess har utvärderat systemets status utifrån målet |
|
|
Gulf of execution - Aggerandeklyfta
|
beskriver skillnaden mellan en användares mål för åtgärder och medel för att genomföra dessa.
Bidrar systemet till att användaren kan utföra handlingar som stämmer med hennes/hans intentioner? I så fall är glappet (the gulf) litet. Det ska (helst) inte behövas extra ansträngning för detta |
|
|
gulf of evaluation - utvärderingsklyfta
|
beskriver skillnaden mellan användarens förväntningar på ett systen och hur det faktiskt presenteras.
Bidrar systemet med en fysisk representation som gör att användaren direkt och enkelt kan förstå det tillstånd systemet befinner sig i? Om svaret är ja så är glappet litet |
|
|
hur hänger gulf of execution och gulf of evaluation ihop?
|
Man strävar alltså efter överensstämmelse mellan användarens intentioner och systemets organisation, representation och koncept
|
|
|
Förklara Abowd and Beale interaction framework
|
utökning av Norman.
innehåller 4 delar: input, output, user, system input och output skapar gränsnittet mellan användare och system. Varje del har sitt eget språk. interaktion = översättning av språk (formulerad för inputens gränser). problem med interkation = översättningsproblem |
|
|
Abowd och Beale interaction framwork (förklara användande processen 5 steg)
|
användandes intentioner, översätts till aggerande i gränssnittet, översätts till förändringar i systemets tillstånd detta visas i output/skärm, som sist tolkas av användaren
|
|
|
Förklara konceptuella modeller.
|
beskriver vad en produkt skall göra, hur den ser ut, och hur den uppför sig. måste förstå problemområdet för att gå vidare till design (veta vad vi ska göra) bör ha en konceptuell modell klar för sig innan man för design. Vad man kan göra med produkten, vad som behövs för att man kan förstå vad man kan göra med den.
|
|
|
Konceptuell modell svarar på minst tre frågor:
|
• Vilka gränssnittsmetaforer skulle vara lämpliga för att hjälpa användaren förstå produkten?
• Vilka interaktionstyper kommer bäst stödja användarens aktiviteter? (instructing, conversing, manipulating, exploring. Olika typer kan användas i ett program.) • Vilka gränssnittstyper är lämpliga? (WIMP/GUI, delbart, tangible – flytta objekt etc, advanced graphical interface – multimedia, VR, interaktiva animationer.) • Det finns också andra saker att ta hänsyn till: Vilka funktioner skall produkten utföra? Hur skall funktionerna vara relaterade till varandra? Vilken information behöver vara tillgänglig? |
|
|
Konceptuell modell baserad på objekt
|
oftast baserat på något som finns i verkliga livet. bör vara objekt som liknar eller tillhör det område som systemet ska ha funktionalitet inom.
ex. kalkylblad, ritverktyg, simulator |
|
|
Konceptuell modell baserad på aktiviteter (4 punkter)(samt övergripande)
|
diskuterar hur man interagerar med gränssnittet. Kan vara via tal, GUI, fysisk
Ge instruktioner Konversation Manipulering och Navigering Browsing och undersökande |
|
|
KMA: ge instruktioner
(konversation, manipulering och navigering, browsning och undersökande) |
annvändaren talar hela tiden om vad systemet ska göra. han är alltid boss. ex. ordbehandling, video, kaffe automat
ger snabbt och effektivt sätt att interager (speciellt bra vid många monotoma uppgifter) |
|
|
KMA: konversation
(manipulering och navigering, browning och undersökande, ge instruktioner) |
konversation mellan två människor. allt ifrån enkel taligenkänning och enkla menysystem till avancerade med normalt talgränssnitt.
ex. telefonsystem, gemet (i word), chattprogram? |
|
|
KMA: konversation: fördelar och nackdelar
|
Fördelar: nya användare kan enkelt konversera med systemet, känns bekvämt och igenkännande
Nackdelar: frustation när systemet inte lyckas tolka, begränsad dialog (kan irritera), kan missleda användaren att tro att det är ett avancerare system än vad de är. |
|
|
KMA: Navigering och manipulering
|
involverar dra&drop, selektering, öppnande, stängande, zooming osv. bygger mycket på hur användaren ör sig och agerar i verkliga livet (WYSIWYG, DM)
|
|
|
KMA: Browsing och navigerande
(konversation, manipulering och navigerande, ge instruktioner) |
liknar hur bi letar och undersöker i tidningar och bibliotek. flexibel och strukturerad information som man kan leta bland ich fp varierad möngd av information om. (ex. browsers)
|
|
|
uttrycksfulla interface:
(vänliga interface) |
Interface som förmedlar ett emotionellt tillstånd
Färg, ikoner, ljud och grafiska element är alla använda för att tillsammans ge en ’look and feel’ för att gränssnittet ska vara tilltalande. Detta kan ge negativa aspekter på användbarheten som dock anv. kan tänkas leva med (schysst grafik mot nedladdningstid) |
|
|
Vänliga interface;
|
få användaren att jkänna sig så hemma som möjligt, även den teknikrädda. 3d mretaforer från bekanta patser. agenter kan vara sällskapsdjur eller välkända vänliga figurer. allt för att känna oss hemma.
|
|
|
Fel meddelande: scheidermans guideline
|
Undvik termer som FATAL, INVALID, BAD
Undvik VERSALER och långa nummer Felmeddelande ska vara precisa och inte vaga Fördöm inte användarna utan istället bör meddelanden vara förlåtande och indikera hur anv. ska se till att det går rätt till Ljudmeddelanden ska kunna stängas av Det ska vara möjligt att få mer utförlig hjäl |
|
|
en användarcentrerade process ska: (3 nyckelegenskaper)
|
Fokusera på användaren:
Redan från allra första början och genom hela processen. Användaren ska vara i fokus. Användbarhets och användarens upplevelse mål ska specificeras: det hjälper vid framtagning av design och vid design av val Iterera: En design bör iterera fram dör man provar tills man hittar den rätta. (utvärdera produkten kontinuerligt) |
|
|
Användar centrerad process: (4 viktiga aktiviteter)
|
Hitta behov och ta fram krav(-specifikation):
Ta fram alternativ design: Bygg interaktiva versioner av din design: utvärdera designen |
|
|
Anv. c. process: ta fram behov och krav(specikation)
(ta fram alternativ design, bygg interaktiva versioner av designen, utvärdera designen) |
Målgrupp måste definieras och vad de har för behov.
En fundamental aktivitet i användarcentrerad systemutveckling |
|
|
Anv. c. process: ta fram alternativ design
|
Innehåller att fram en konceptuell design (dvs. en modell över hur produkten ska bete och se ut)
Även fysisk design (färg, ljud, bilder, menyer osv.) I detta steg ska man hel tiden försöka vara öppna för alternativ. |
|
|
Anv. c. process: bygga interaktiva versioner av din design
|
Användaren måste kunna interagera med våran interaktiva design
För detta så krävs en interaktiv version av designen Kan vara i pappersform eller enkel digital prototyp Dock ska användaren få känslan |
|
|
Anv. c. process: utvärdera designen
(hitta behov och ta framkrav(spec.), ta fram alternativ design, bygg interaktiva versioner av din design) |
Utvärdera användarbarhet och mottagande av produkten
Kan vara utvärdering av: antalet del anv. gör, hur väl den matchar förväntningar, hur tilltalande den är. är du inte nöjd så gå tillbaka några steg. |
|
|
Tre kategorier på användare;
|
Primära: dvs de som använder produkten dagligen
Sekundära: använder produkten då och då eller via någon annan Triära: påverkas av at den inför eller står för stålarna. |
|
|
Vad är ett behov/krav?
|
Användare vet sällan vad som går att göra
Användare har svårt att säga vad de behöver för att nå sina mål Istället bör man titta på: vad det är för information de behöver för sina aktiviteter, vilka som måste samarbeta för att nå målen, varför de idag agerar som de gör Viktigt att förstå användaren handlingmönster, därigenom kan vi försöka att ge ett bättre stöd än idag. Dock bör de ha substans i dagens beteende, beteende ändras succesivt inte snabbt. |
|
|
Scenarios:(4 olika typer)
|
user stories
conceptual scenarios concrete scenarios use cases |
|
|
Scenarios: user stories
|
först hur man gör och hur man vill ha det
en berätelse om hur man agerar och hur man övergripnde använder systemet. gärna personlig prägel för att få liv i berättelse. Vill förstå hur man använder gränssnitet men även i vilken miljö och under vilka villkor. |
|
|
Scenarios: conceptual scenarios
|
Används för att generera idéer och specificera krav
Är mer abstrakta ta bort kontext ifrån berättelse och fokusera kring användandet av systemet Bra att generera idéer kring hur man ska använda systemet |
|
|
scenarios: concrete scenarios
|
Används för att göra prototyper och utvärdering
Ett dokument, som beskriver när en användare utför en situation. Precisa och förståeliga |
|
|
scenarios: use cases
(user stories, conceptual scenario, concrete scenarios, use cases) |
Användarfall
Beskrivning av uttömmande beskrivning av funktionaliteten av systemet Ingenting om hur uppgifterna presenteras för användaren eller hur dessa prioriteras. Användas i de senare stadier för validering av konstruktionen |
|
|
Task analyse
|
Är en analys av vilka handlingar som anv. utför.
Vanligast är HTA, hierkisk handlingsanalys Bryt ner varje handling till del handlingar Fokuserar på fysisk observerande handlingar (inte inte mentala) Startar med ett mål, användarens mål Ex. kaffe maskinen |
|
|
Kognitiva modeller: (modellerar 4 aspekter på användaren)
|
Förståelse
Kunskap Intentioner Hur man processar |
|
|
Kognitiva modeller vad är det?
|
mentalt bearberning fr de olika stegen. devide and conquer, söndra och härska, försöka se användarens mål
|
|
|
Olika typer av kognitiva modeller:
|
GOMS,
Cognitive complexity, theory (CCT) Hierachical Task analysis (HTA) |
|
|
Kognitiva modeller: GOMS:
|
Selection (rules) – Regler för vilken metod man väljer om det finns flera att välja på. samt hur man väljer
Görs inga egentliga mätningar, utan grejerna skrivs bara upp. |
|
|
Kognitiva modeller: Cognitive complexity theory
|
innehåller regler liknande if, condition, then, action.
Ge mer förutsägbarhet till hur användaren agerar. liknar lisp kod, detta är för lång tidsminnet, en annan modell för arbets/kortttidsminnet. |
|
|
Cognitiva modeller: Hierachical task analysis (HTA)
|
, Från linjearbete till systemövervakning, Tar hänsyn till sammanhanget, Komplexa uppgifter, handlar om mål och operationer där operationer är det användaren gör för att komma närmare målet. komplexa uppgifter, i sammanhang
– Hittar problem – Idéer för omdesign – Systematisk genomgång av syste |
|
|
Task analys:
|
beskriva vilket agerande användaren använder
strukturerar dem i agerande och under agerande. även i vilken ording ageranden utförs. fokus ligger på användare, externa handlingar och hela arbetet. |
|
|
Vad är en prototyp?
|
En begränsad representation av en design som tillåter användare att interagera med den och utforska dess lämplighet”. Prototyper har många fördelar, man tvingas tänka kring designen. En småskalig modell.
|
|
|
Olika typer av prototyp inom datorvärlden (6 stycken)
|
- En serie skissar
- Storyboards - En slideshow - En fysisk utskuren replika - En video som visar gränssnittet - en applikation med begränsad funktionalitet |
|
|
Varför prototyp?
|
Naturligtvis för att testa och utvärdera. Centralt för HCI och ID
De hjälper för att prova dina idéer De är också en hjälp när du behöver välja mellan olika alternativ och inte minst hjälp till reflektion över design Kunden kan se och interagera med en prototyp, vilket hjälper dem i deras tankegångar snabbt skall kunna utvärdera någon typ av funktionalitet |
|
|
vad gör man prototyp om? (3 punkter om tekniska delajer som måste utvärderas)
|
Arbetsflödet eller ”task analyze”, dvs. se hur bra arbetsflödet är i programmet.
Skärm layout och hur information presenteras. Nya, annorlunda, svåra eller kritiska delar av systemet som verkligen måste utvärderas |
|
|
Low fidelity prototyp
|
Är väldigt olik den färdiga produkten
Utmärkande är att den: Går snabbt att göra Är billig Är lätt att ändra. Kan fokusera på att exempelvis bara visa var vissa element ska ligga och inte lägga så stor fokus på designen. Pappersprototyper ex. storyboards, skisser, index-card, wizard of oz (människa leker dator) |
|
|
LFP: Storyboards:
|
Används oftast tillsammans med scenarion, eller snarare för att visualisera scenarion.
Är en serie av skisser som visar på hur en användare är tänkt att använda gränssnittet/produkten. Lite som en serietidning Används oftast väldigt tidigt i designprocessen |
|
|
LFP: Skisser
|
Skisser är väldigt viktigt överhuvudtaget
Utan en skiss är det svårt att få en bra uppfattning om detaljer Man behöver inte vara konstnär för att få en användbar skiss |
|
|
LFP: Index-card
|
Små kort där varje kort representerar en skärm sida.
Går snabbt och enkelt att byta sida. Bra att använda i webbutveckling. |
|
|
Prototyp: High fidelity
|
Använder material som mer liknar slutprodukten.
Den liknar överhuvudtaget mycket mer slutprodukten. I datorvärlden används oftast prototypverktyg som: macromedia director, smalltalk, visal basic. Systemet ser äkta ut, men är det inte |
|
|
Prototyp: High fidelity (negativt)
|
De som utvärderar tenderar att fokusera på ytliga saker istället för innehåll.
Utvecklare vill inte ändra på något de lagt ner mkt tid på Mjukvara kan sätta förväntningarna högt / En bugg kan stoppa testet. tar längre tid att göra (kostar mer) testare tittar på det bristande innehåller än interfacet. |
|
|
Kompromiser med prototyper.
Stora: |
tid/pengar kontra hur mycket man vill få ut
|
|
|
Kompromisser med prototyper: Horisontal och vertikal:
|
Horistontal – ger många funktioner, men få detaljer
Vertikal – ger många detaljer med få funktioner |
|
|
Olika typer av prototyper: utifrån va de undersöker
|
Undersökande: undersöker någonting som man undrar över, slängs sedan.
Evolverande: är en typ av prototyp som ska växa och evolvera fram till slutprodukten. |
|
|
Olika typer av prototyper: utgångspunkt
|
Beteende: fokuserar på ett visst beteende som man vill undersöka
Strukturell: tittar på struktur, arkitektur eller teknisk plattform |
|
|
Olika typer av prototyper (2 huvud delar med 2 under varje)
|
utifrån vad de undersöker: evolverande, underskande
utgångspunkt: beteende, strukturell |
|
|
Vilka tekniker finns det att använda vid datainsamling? (5 olika typ av "observationer")
|
Observera användarna
Fråga användarna om deras synpunkter Fråga experter om deras synpunkter Testa användarnas utförande Modellera användarnas utförande |
|
|
Tekniker: observera användarna: (vad är viktigt att beakta) 5 punkter
|
Mål och frågor
Hur man samlar in data Vilken utrustning som behövs Hur man ska behandla känslig data Hur data ska analyserar |
|
|
Observera användare: som en utomstående:
|
Användbarhetstest
Mera objektivt än medverkande observation (allt är på plats i en labb, allt spelar in och dokumenteras, måste akta sig för att drunkna i data) Analys kan både göras grovt och i väldigt fina detaljer Videoklipp kan vara väldigt talande. |
|
|
Observera användare: medverkande observation
|
Är nyckeln i etnografisk undersökning (undersökning inom mänskligt beteende)
Användarna måste dock medverka, går ej annars Dataanalys görs kontinuerligt Frågeställningen blir bättre och bättre |
|
|
Datainsamlingstekniker (för att ha kvar data) (5 punkter)
|
Anteckningar och stillbildskamera
Ljud och stillbildskamera Video Dagböcker/logg Loggning i detalj |
|
|
Upplägg av intervju:
|
Introduktion: presentera dig, mål med intervju osv.
Uppvärmning: gör de första frågorna väldigt lätta och okontroversiella Huvuddelen: presentera frågorna i logisk ordning Avkylning: avsluta även med lätta okontroversiella frågor Avslut: tacka osv. |
|
|
Analys av intervju:
|
Strukturerade intervjuer behandlas som frågeformulerar
Ostrukturerade intervjuer ger data som liknar deltagande observationer. Dessa är bäst att analysera så snabbt som möjligt |
|
|
fråga experter
|
Kan vara formella eller informella rapporter.
Heuristic evaluation är en metod liksom HOMERUN Design guidelines är i sig en form av fråga experter utvärdering Empiristisk data visar att 5 expert utvärdering hittar 75-80& användbarhets problem |
|
|
Heuristiska punkter (10 punkter)
|
Systemets status är synligt (håll användaren informerad om vad som händer)
Verkliga livet bör motsvaras i systemet (bör använda användarnas språk och konventioner) Användarkontroll och frihet (man ska få göra fel och enkelt att komma vidare) Konsekvent och följa standarder (man ska lätt förstå) Förhindra fel: (bättre än bra felmeddelande är att hindra att dessa förekommer) Igenkännande snarare än ihågkommande(man ska inte behöva komma ihåg saker) Flexibelt och effektivt (låt den avancerade anv. ha möjlighet att effektivisera jobbet) Estetiskt och minimaliskt design (irrelevant info bör tas bort) Hjälp anv. hitta och rätta till fel (felmeddelanden bör tala om hur man ska åtgärda felet) Hjälp och dokumentation (bra hjälp som är lätt att hitta i) |
|
|
Heuristisk utvärdering
|
Användbarhetskriterier definieras/identifieras
Experter undersöker utifrån dessa kriterier Ex. Systemet är förutsägbart, systemet är konsistent i sitt beteende, feedback ges. |
|
|
Kognitiv genomgång
|
Experter spelar användare. Tar tyvärr ej hänsyn till estetiska egenskaper eller fysisk interaktion. Fokuserar på hur lätt ett system är att lära sig. Man samlar kunskap om användarna, designers och utvärderare möts, utvärderarna går igenom sekvenser för uppgiften, man noterar problem, åtgärdar problem. undersöker hur användarna hjälps till att lära sig agera i systemet.hur påverkas användarna? vilka kognitiva processer behövs? vilket inlärsningsproblem kan uppstå? Bra för att studera en liten del av systemet.
|
|
|
Steg vid kognitiv genomgång
|
Typiska användare identifieras och deras agerande mot systemet dokumenteras
Varje agerande genomförs i en prototyp (förstår anv. vad som ska göras? Kan man se att man har gjort rätt? Kan användaren utläsa och förstå om man har gjort rätt?) Genomgången görs av utomstående experter, INTE designen själv. |
|
|
Fråga experter: fördelar nackdelar
|
Fördelar:
Färre etiska och praktiska saker att fundera på Svårt hitta lämpliga experter (och dyrt) Nackdelar: Viktiga problem kanske man inte hittar Triviala saker kanske man missar |
|
|
3 sätt att testa och modellera användare
|
experiment
användartester användbarhetstesning |
|
|
3 sätt att testa och modellera användare: experiment
|
testar en hypotes för att få nu kunskap om relationer mellan två saker/variabler
Försök förutse relationer mellan två celler eller variabler Beroende variabler beror på de oberoende Oberoende variabler manipuleras av undersökaren Experiment har oftast 1 eller 2 oberoende variabler Detta kan ge: alla användare får alla möjliga villkor, olika användare får olika villkor, användare matchas i par efter kategorisering |
|
|
3 sätt att testa och modellera användare: användartester
(experiment, användbarhetstestning) |
används för att testa om systemet är användbart för den tänkta användargruppen när de ska utföra sin uppgift.
Utföres i ett användbarhetslabb eller väl kontrollerad miljö Utför inte testet längre än 30 min Villkoren ska vara lika för alla användare Du mäter: - tid at utföra en viss uppgift (ny uppgift och gammal) - antal fel per uppgift - antal fel per tidsenhet - antal gånger en användare för ett visst fel - antal anv. som lyckas göra en uppgift |
|
|
3 sätt att testa och modellera användare/fyra paradigmer: användbarhetstestning
(användartester, experiment) |
inkluderar en kombination av tekniker, inkluderande användartestning och frågeformulär om hur nöjda användarna är.
Mål och frågor fokuserar på hur bra användarna kan utföra sina uppgifter Jämförelse mellan olika produkter och prototyper är vanligt. Fokus är att testa tiden det tar att utföra en viss uppgift, antal och typ av fel man gör Video och loggning är vanligt Hur nöjda användarna är kompletteras med frågeformulär.Utförande tid, felste och missförstånd hittas lätt. Spelar in användaren i en väl kontrollerad miljö. |
|
|
Utvärderingsparadigm
|
All utvärdering styrs av en mängd tankar om testerna
Egentligen handlar det om hur man ser på utvärdering Dessa består oftast av olika metoder och tekniker |
|
|
Fyra paradigmer:
|
Quick&dry
användbarhetstestning fältstudier förutsägande utvärdering |
|
|
Fyra paradigmer: quick and dry
(användbarhetstester, fältstudier, förutsägande utvärdering) |
Är en metod där designers på ett informellt sätt får feedback från användare eller för den delen konsulter
Detta för att få bekräftelse för designernas tankar hos användarna Dessa utvärderingar görs lite då och då Snabb feedback in i design processen snarare än väl dokumenterad studie. |
|
|
Fyra paradigmer: fältstudier
(quick&dry, användbarhetstestning, fältstudier, förutsägande utvärdering) |
Undersöka ett fält med fokus på händelser, relationer,
erfarenheter eller processer Inga variabler kontrolleras Genomförs i fältet som undersök Dessa görs i den naturliga miljön. Målet är att förstå vad användarna för i en naturlig miljö och hur den nya teknologin påverkar dem Kan användas för: hitta möjliga nya produkter, ta fram krav, utvärdera befintlig teknologi |
|
|
Fyra paradigmer: förutsägande utvärdering
(quick&dry, användbarhetstestning, fältstudier) |
Innebär att experter försöker genom sin kunskap förutse problem som användarna kan råka ut för.
Kan helt baseras på empiristisk data och erfarenhet eller mer teoretiska modeller av anv. Snabb och billig ”utvärdering” Användarna behöver inte vara närvarande. |
