Designmetodik. Användarcentrerad systemutveckling. 2 oktober 2002

Transkript

1 Designmetodik Användarcentrerad systemutveckling 2 oktober 2002

2 Dagens föreläsning Användarcentrerad systemutveckling Inlämningsuppgift Projekt Obs! Ingen övning i eftermiddag! Japaner...

3 Varför en metodik? Användbara system uppkommer inte av en slump eller genom någon trollformel. Resultat av kunskap, erfarenhet och metodiskt arbete.

4 Framgångsfaktorer att arbeta metodiskt, t ex med användarcentrerad systemutveckling utvärdera under utvecklingen att ha förståelse för och erfarenhet av mänskligt beteende, förmågor och begränsningar kommunikation och interaktion allmänna designprinciper och deras tillämpande möjliga designlösningar andra system systemutveckling, projektarbete

5 Varför en metodik/ramverk? Ger stöd för att arbeta strukturerat att organisera arbetet både vad gäller Aktiviteter Resultat ( leverabler ) tidsplanering och projektering tanken kommunikationen

6 Användarcentrerad systemutveckling Analysera användare, användningssituation och uppgift Testa och utvärdera designförslag med användare OK? Skapa och kommunicera designförslag (prototyper m.m.) Specificera krav på användande

7 Användarcentrerad designmetodik - Preece Identify needs/ establish requirements (Re)design Evaluate Build an interactive version

8 Samma (5!) huvudmoment 1 1 och och 4 fokuserar på leverabler 1. Analys 2. Kravställande 3. Design 4. Prototyp 5. Utvärdering 4 fokuserar på designaktivitet

9 och samma 3 huvudprinciper 1. Användaren är i fokus under hela utvecklingen 2. Användbarhetskrav och upplevelsemål identifieras i början av projektet och säkerställs genom tester 3. Iterativ process dvs. momenten upprepas och förbättras utifrån feedback

10 Iteration genom hela projektet Koncept Funktionalitet Interaktion Kontaktyta

11 Användarcentrerad systemutveckling Analysera användare, användningssituation och uppgift Testa och utvärdera designförslag med användare OK? Skapa och kommunicera designförslag (prototyper m.m.) Specificera krav på användande

12 Analysera användare Syfte identifiera olika målgrupper med gemensamma behov bakgrund, kunskapsnivå, arbetsuppgifter och vanor krav och önskemål, speciella behov attityd till systemet, teknik och förändringar identifiera olika användningssituationer plats (hemma, mobilt, på jobbet) miljö (ljus- och ljudförhållanden, arbetsställning, begränsningar) relation till systemet (användningsfrekvens, motivation, inflytande) kognitiv belastning, övriga aktiviteter

13 Analysera användare, forts Resultat ett analysdokument med användarprofiler motiveringar till användbarhetskraven idéer till designförslag

14 Analysera uppgiften/aktiviteten Syfte att förstå uppgiften/aktiviteten som systemet ska stödja struktur, delmoment vilka moment som är svåra, tidskrävande, inte finns rimliga lösningar till vilka lösningar som används idag identifiera för- och nackdelar med dagens tillvägagångsätt

15 Analysera uppgift - forts Resultat analysdokument med beskrivning av uppgiften/aktiviteten tänkta mervärden med ett nytt system motiveringar till funktionalitetsskraven idéer till designförslag

16 Analysresultaten - kravspec Analyserna leder till krav i kravspecifikationen: Användaranalys användbarhetskrav Krav på användandet av systemet Mätbara/avgörbara Uppgiftsanalys funktionalitetskrav Krav på vilka funktioner som systemet ska tillhandahålla Motiverade utifrån användarens behov

17 Exempel på användbarhetskrav Exempel: Biljettautomat: usability user experience usability user experience 8 av 10 testpersoner skall ta sig igenom köpprocessen med mindre än två felaktiga val första testomgången. 75% av testpersonerna skall uppge att de upplevde biljettautomaten som ett tidsbesparande alternativ, jämfört med kassaförsäljning. Professionellt bokföringsprogram: Efter 2 veckors träning, skall 9 av 10 testpersoner utföra sina rutinuppdrag (se spec.) på kortare tid än med det gamla systemet. Efter 3 månaders användande, skall 80% av användarna anse att det nya systemet är mer tillfredställande än det gamla. Tänk på kravspecifikationen som ett kontrakt!

18 Exempel på funktionalitetskrav Rangordna i prioritetsordning Exempel (från ett heminredningssystem) 1. nödvändiga funktioner: konstruera en 3D-modell av ett rum välja utseende på väggar, tak och golv placera ut möbelmodeller i rummet titta sig runt i det möblerade rummet 2. viktiga funktioner: kunna se två rum samtidigt (för jämförelse) 3. önskvärda funktioner skriva ut olika vyer av rummet...

19 Skapa designförslag/prototyper Syfte att skapa olika alternativa idéer och förslag till designlösningar att skapa en gemensam vision inom designteamet att kommunicera designförslag externt (för ledning, kund, testpersoner, kravställare etc att möjliggöra relevant feedback att skapa rimliga testsituationer Resultat skisser, idéer, prototyper designdokument

20 Prototyper, forts Tänk på att... olika prototyper visar olika aspekter. Vad är syftet? Vilken aspekt vill ni testa? Vad vill ni kommunicera?

21 Testa och utvärdera designförslag Syfte att jämföra alternativa designförslag verifiera krav att få objektiva omdömen och resultat Resultat en mer objektiv uppfattning om designförslagets potential indikation på om kraven är uppfyllda

22 Testa och utvärdera Tänk på att... prata igenom situationen internt innan, att utvärdera och sälja samtidigt är svårt!

23 Olika abstraktionsnivåer Viktiga designbeslut måste tas i rätt ordning för att få genomslag och undvika merarbete! Koncept Funktionalitet Interaktion Kontaktyta

24 Designnivåer Till vad skall systemet användas? Vilka skall använda det? Varför behövs det? Vilka funktioner behövs i systemet? Vilken struktur har systemet? Hur ska användaren interagera med systemet? Hur ska kontaktytan se ut? Koncept Funktionalitet Struktur Interaktion Kontaktyta tid

25 Exempel: Webbplats Vad ska webbplatsen förmedla? Vilka målgrupper? Vad kan de göra? Vilken information ska finnas? Vad vill målgrupperna få reda på/göra? Hur ska webbstrukturen se ut? Sidindelning? Hur ska man navigera? Val av menysystem m.m. Hur ska sidorna se ut? Grafisk profil och layout Koncept Funktionalitet Struktur/Metod Interaktion Kontaktyta tid

26 Samma moment på alla nivåer Analys dokument Kravspecifikation Prototyp & utvärdering OK? Koncept Funktionalitet Struktur/Metod Interaktion Kontaktyta OK? OK? OK? OK?

27 Exempel på konceptnivån Nytt varningssystem för bil bristande uppmärksamhet Analys: Målet är att minimera den tid som föraren brister i uppmärksamhet (och inte har blicken riktad mot körbanan). Krav: Varningen får inte distrahera föraren och öka den kognitiva belastningen. Designlösning: hemligt... Prototyp: Video som filmades under körning från förarplats på vilken varningen simulerades. Utvärdering (initial): Filmen visades för berörda personer.

28 Exempel på funktionalitetsnivån Citroën 2CV (TPV) [Utdrag från kravspec 1936] Analys: Målet var att designa en bil för Franska bönder. Deras behov ansågs 2-falt: 1. Att färdas till kyrkan om söndagen. 2. Att frakta ägg till marknaden. Krav: 1. En lång man med hatt skall kunna sitta bekvämt i TPV. 2. TPV skall kunna frakta en korg fylld med färska ägg över en plöjd åker utan att något av dessa krossas. Designlösning: 1. Avtagbart tak. 2. Hydraulik - Citroëns unika stötdämpning. Utvärdering: Den finns ju fortfarande...

29 Exempel på struktur/metod-nivån Analys: Målgrupper för webbplatsen är i prioritetsordning:... Krav: 1. Webb: 90% av testpersonerna skall hitta rätt menyingång för sin högst prioriterade information. 2. All högprioriterad information (rankad 1-3), skall vara nåbar inom 2 klick från huvudmenyn. Prototyp: Klickbar struktur. Utvärdering: Test med 2 personer/målgrupp Upplägg: enkät för rangordning av information; test med klickbar struktur

30 Exempel på interaktionsnivån Analys: Krav: Barn i åldern 4-6 har begränsad finmotorik, och kan ha svårt med dragand drop- teknik. Alla barn skall klara av att flytta ett objekt från en punkt till en annan (då de visats hur det skall göras). Designlösning: Prototyp: Ny flytta princip: hämta (klick) flytta (objektet fast vi musen) lämna av (klick). Enkel implementering av flytta objekt. Utvärdering: Testade prototypen med ca 10 förskolebarn.

31 Exempel på kontaktyte-nivån En bild som användes flitigt i ett företags presentationsmaterial. Analys: Företagsledningen hade en uppfattning om vad de trodde att bilden skulle symbolisera. Krav: Bilden skulle vara tilltalande och även ge ett visst budskap. Prototyp: En utskrift av bilden. Utvärdering: 1 tim test med ca 30 personer i möjlig kund kategori, vilka tillfrågades vad de fick för spontana associationer av bilden. Fotnot: Bilden försvann ur presentationsmaterialet.

32 När ska man sluta iterera? När skillnaden mellan målen/kraven och resultat av utvärdering blir tillräckligt liten!

33 Processen allt produkten inget? Hålla genomgående hög kvalitet Undvika black box -fenomenet Kommunicera Överlämna till andra Spårbarhet Trovärdighet Ta betalt...

34 Ett fungerande designteam måste kunna sätta sig in i och förstå uppgiften/aktiviteten systemet skall stödja sätta sig in i och förstå användningssituationen förstå människor förstå speciella behov hos användare samla information analysera generera idéer kommunicera idéer bygga prototyper fatta beslut utvärdera

35 Olika områden - olika perspektiv Olika människor olika tolkningar av vår omvärld

36 I vems värld... förekommer osynliga gif-bilder? (layout i html-dokument) finns inte dokumentet du har framför dig, innan du sparat det? (Word, mfl.) hamnar breven i en utkorg då du skickar dem? (Outlook) är det du som stängt av datorn på fel sätt, då datorn kraschar (och måste startas om på nytt)?

37 Var stänger man av datorn?

38 Under Start!

39 Designproblemets kärna: Design modell Designer? Mental modell Användare Dokumentation System System image

40 Litteratur Preece: Kap 6 Chrusch, M: Seven Great Myths of Usability

41 Inlämningsuppgiften Bra jobbat!! Uppgift A Utvärdera, observera/intervjua användare Funktions- och Uppgiftsanalys Beskriv problem Gör en ny design av systemet och motivera Uppgift B Kriterier för god design Beskriv valt system Motivera Presentation i rapport och redovisning

42 Projektet - innehåll Användar- och uppgiftsanalys Kravspecifikation Övergripande design av hela systemet Implementering av prototyp/-er Evaluering av prototypen/-erna Det system ni väljer att arbeta med är valfritt, men måste uppfylla kraven ovan.

43 Projektet innehåll Gruppen väljer själv vilket system man vill analysera och kravspecificera. Gruppen ta över någon annan grupps kravspecifikation. Vilken kravspecifikation gruppen får avgör kursansvariga.

44 Projektet hålltider Moment I Användar- och uppgiftsanalysen skall presenteras för kursansvariga vid ett projekthandledningstillfälle, och analyserna skall godkännas absolut senast 18/10. Analyserna ska resultera i en skriftlig kravspecifikation och den ska vara färdig senast 25/10.

45 Projektet hålltider Moment II Den 30/10 delar kursansvariga ut kravspecifikationerna till respektive grupp. Innan designen omsätts i en prototyp skall preliminär design och prototypverktyg också presenteras för kursansvariga absolut senast 6/11. Evalueringen av prototyperna presenteras för kursansvariga senast 22/11.

46 Projektet hålltider Moment III Det här momentet är en individuell uppgift. Du ska reflektera över designarbetet som utförts i projektet med utgångspunkt från de designmetoder som tagits upp på föreläsningarna. Uppgiften redovisas i en skriftlig rapport (3-4 sidor) och lämnas in senast tre dagar innan det muntliga förhöret.

47 Projektet rapporten Moment I En introduktion till projektet. En användaranalys enligt de riktlinjer som beskrivs i kursen (2-3 sidor). En uppgiftsanalys enligt de riktlinjer som beskrivs i kursen (2-3 sidor). En kravspecifikation där funktionalitets- och användbarhetskrav anges (1-2 sidor). Redovisning av personliga insatser i projektet (1 sida).

48 Projektet rapporten Moment II Granskning av kravspecifikationen (1 sida) Presentation och motivering av den övergripande designen i text och bild (3-5 sidor). Beskrivning och motivering av prototypen/-erna (2-3 sidor). Resultat och beskrivning av evaluering (2-3 sidor). Redovisning av personliga insatser i projektet (1 sida).

49 Projektet - rapporten Projektrapporten skall lämnas in i en preliminär version senast tre arbetsdagar innan det muntliga förhöret. Huvudansvaret för slutliga rapporten har den grupp som utför moment II. Observera att den individuella uppgiften (moment III) inte ingår i projektrapporten utan lämnas in separat, senast tre arbetsdagar innan det muntliga förhöret. Lycka till!