Inlämnad Kursansvarig: Staffan Björk Hanna Landén. Författare: Annica Löfving it3loan

Relevanta dokument
REFLEKTION PÅ STARGATE-PROJEKTET

DH2622 MDI-fk Introduktion till kursen & ämnet. MDI på KTH. Kursen i sitt sammanhang

Uppsats i MDI En reflektion över designarbetet i tidigare inlämningsuppgift

Personas -En metod inom Participatory Design

Föreläsning 4 Identifiera krav och behov. Att läsa: Kapitel 10 i Rogers et al.: Interaction design

Mönster. Ulf Cederling Växjö University Slide 1

Föreläsning 8, Design

1IK430 Brukarorienterad design

Människa-Datorinteraktion

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Tänka-högt metoden versus Enkätundersökning

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till?

Projekt: Utveckling av ett användargränssnitt

Föreläsning 10: Introduktion till utvärdering. Rogers et al. Kapitel 12

Att fastställa krav. Annakarin Nyberg

Fastställa mål. Daniel Bosk. goals.tex :33:45Z danbos

Föreläsning 3: Mer om utvärdering, Inspektionsmetoder kan man utvärdera utan användare?

DIGITALISERING FÖR MERVÄRDE EN ILLUSTRERAD GUIDE FÖR SOCIALTJÄNSTEN I SUNDSVALL

Nätkurs Design & konstruktion av användargränssnitt 1MD113 Sid 1 (5) Lektion 11 Användare, uppgifter och krav del

Design för användbarhet Designexempel, hur tänkte man vid designen?

Participatory Design III

Datainsamling. Daniel Bosk. data.tex :33:45Z danbos

Fältstudier och analys

Föreläsning 5: Fastställa krav varför, vad och hur

Användbarhet och Webbutveckling för mobila enheter. Behovsanalys

Redigeringsteknik och postproduktion

Kravställande/kravhantering

DESIGNMET MINA REFLEKTIONER KRING DESIGNARBETET I IBRUSH-PROJEKTET INVOLVERING AV ANVÄNDARE HUR ÄR DET ATT HA BARN SOM MÅLGRUPP?

MDI-fk 2D1622 introduktion till kursen & ämnet. MDI-gruppen på KTH. Kursen i sitt sammanhang

RUP är en omfattande process, ett processramverk. RUP bör införas stegvis. RUP måste anpassas. till organisationen till projektet

Projekt: Utveckling av ett användargränssnitt

Introduktion till människa datorinteraktion och interaktionsdesign

3/30/12. Föreläsning 2: Datainsamling - Observation, enkät, intervju. Stjärnmodellen. Översikt. Analys. Prototyper Krav. Design

IC1007 Människa-dator interaktion: Principer och Design 7,5 hp

Konverteringsskola Del 3: Vad är användbarhet?

Reflektioner kring designprocessen av Intellitic

Föreläsning 3 Användare, uppgift och omgivning. Kapitel 3-4 i Stone et al.

Föreläsning 2: Datainsamling - Observation, enkät, intervju. Att läsa: Kapitel 7 i Rogers et al.: Interaction design

Individuell inlämningsuppgift del 1: Kognitiv design.

Chaos om IT-projekt..

Prototyping - faser, typer och potentiell problematik

Intro utvärdering

Användbarhet. Datorbaserade verktyg används till att. Aspekter på användbarhet. uppfylla behov eller lösa problem! Användbarhet.

Här ges en överblick över de delar som ingår i projektarbetet och beskriver kraven och bedömningskriterierna.

Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp

Föreläsning 12 Inspektionsmetoder. Rogers et al. Kapitel 15

Användarcentrerad Systemutveckling

Från extern till intern på tre dagar Erfarenheter från externa lärares pedagogiska kompetensutveckling

Concept Selection Chaper 7

Chaos om datorprojekt..

Process- och metodreflektion Grupp 5

Människa-datorinteraktion 1MD016, hösten 2011 Användarcentrerad systemdesign september 2011

Summering: Workshop 14/3-19

Datavetenskap. Beteendevetenskap MDI. Design

Användarcentrerad systemdesign introduktion till begrepp, processer och arbetssätt

Vad vi pratade om förra gången. Fast med andra ord

Computer Science and Engineering Chalmers University of Technology and Göteborg University Design Methods 3 p

PRESENTATION. Anders Wasserman, 34 år. Fästmö och en son. Arbetat i Hammarby IF FF i sju säsonger i U11 - U19. UEFA Youth Elite Diploma

Föreläsning 2: Datainsamling - Observation, enkät, intervju. Att läsa: Kapitel 7 i Rogers et al.: Interaction design

Att läsa: Sharp, Helen, Rogers, Yvonne & Preece, Jenny E. (2007) Interaction design. Wiley. Kapitel 11.

Föreläsning 2: Introduktion till utvärdering varför ska vi utvärdera?

Bruksanvisning och formalia för proben

Mina målsättningar för 2015

Tjänsteprototypning. Föreläsning i kursen TDDD51 Linköpings universitet den 21 februari Johan Blomkvist

Frågetekniker. Föreläsning 3, Utvärderingstekniker MDI, Lena Palmquist 1. Än en gång: JEdit (Py Kollberg) Loggning. Tolkande dataanalys

Forskningsperspektiv inom MDI Vetenskap, mångvetenskap och tvärvetenskap Vad är forskning inom MDI?

Steg för steg-guide för. Medarbetarundersökning

När m an betraktar begreppet användbarhet m åste m an ta hänsyn till två viktiga faktorer. Dessa är:

Utvärdering. Användbarhet. + beställarperspektivet! Innehåll. Varför?

Att arbeta metodiskt under designprocessen Anna Olvenmyr

Interaktionsdesign och användbarhet Personas. Paper prototyping. » Metod för representation av användaren. » Metod för konceptutveckling

Deltagande design Ett projekt med hjälp av och med fokus på användaren Grupp F

DESIGNSTUDIO SPEL TEAM TONTOY. Patrik Lundin : : XXXX HÖGSKOLAN I HALMSTAD Digital Design och Innovation

Föreläsning 2: Introduktion till utvärdering varför ska vi utvärdera?

Campuskurs Distanskurs Annan. Examinator Remigijus Gustas

Användaranalys och användbarhetskrav

Linköpings universitet 1 TDP029. Systemutveckling. Systemutveckling. Vanliga faser. Fler faser. Systemutvecklingsmetod

Interaktionsdesign, grundkurs (7,5 HP)

We cannot solve our problems with the same kind of thinking we used when we created them

Individuell inlämningsuppgift del 1: Kognitiv design.

Individuell inlämningsuppgift TEK210

Projektsteg: Detaljdesign. Måldriven design. I praktiken? Vattenfallsmetoder. Designdriven utveckling. Agila metoder

S.O.C. Hör du mig. 25 mars S.O.C. Hör du mig?

Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg

Allmänna frågor om kursen: 1. Vilket är ditt allmänna omdöme om kursen? Antal svar: 25 Medelvärde: 4.3

Utveckla resonemang om musicerande

Användarcentrerad systemdesign

Design för användbarhet Användarcentrerad utvecklingsprocess

Marbäcks förskolas plan mot diskriminering och kränkande behandling

Systemering med användarfokus

Företagsekonomi C-uppsats, HT-13. Gabriel Gimdal & Max Johnson. Titel: Hur Påverkar Gerillamarknadsföring Generation Y?

Seniorer lär seniorer IT

Interaktionsdesign som profession. Föreläsning Del 2

Verktygslåda för mental träning

Olika syften. TDDD60 användbarhetstest. När passar vilken typ? Med eller utan användare

Barns och ungdomars engagemang

Föreläsning 7: Kognition & perception

Fråga 1 Skriv in vilken kravnivå kravet tillhör i rutan under varje krav.

Föreläsning 4, Användbarhet, prototyper

Spelutveckling - Gameplay. Design och produktion

Transkript:

Uppsat s i k ursen Designm et odik ht 2003: Sc enarios oc h personas i användarc ent rerad ut vec k ling Inlämnad 2004-01-09 Kursansvarig: Staffan Björk Hanna Landén Författare: Annica Löfving it3loan

Sammanfattning De traditionella användarcentrerade designstrategierna har utvecklats mycket de senaste åren och det finns ett antal av dessa designtekniker som kan vara effektiva i interna eller kundanpassade utvecklingsprojekt. Tyvärr har dessa tekniker visat sig vara mindre effektiva i utvecklingen av produkter med en stor, diversifierad användargrupp. Men det finns metoder som kan användas som ett komplement till de traditionella strategierna. Designers har länge använt scenarios som en teknik för att för att organisera, belysa och kommunicera idéer om hur och vad som skall designas. Ett scenario konstruerat av information som är empiriskt säkerställd är ett kraftfullt verktyg. Erfarenheter har dock visat att användandet av scenarion i många fall inte används som det skall vilket innebär stora problem och risker. Skapandet och användandet av uppdiktade användare, konkreta representationer av användare, så kallade personas, är en relativt ny teknik för interaktionsdesign. Den är inte helt utan problem och kan användas där den inte borde, men baserad på erfarenhet och analys så har den stor potential, både som fristående metod och i kombination med scenarios. Inledning De traditionella användarcentrerade designstrategierna har utvecklats mycket de senaste åren och det finns ett antal av dessa designtekniker som kan vara effektiva i interna eller kundanpassade utvecklingsprojekt. Tyvärr har dessa tekniker visat sig vara mindre effektiva i utvecklingen av produkter med kommersiellt syfte [9] eller produkter som skall komma att användas av en stor, diversifierad användargrupp. I en del tidigare utvecklingsprojekt som jag medverkat i har jag använt mig av traditionella metoder som används för att öka användarnas medverkan i designutvecklingen. Exempel på sådana strategier och metoder har varit storyboarding och prototyping [6], återkommande uppföljningsmöten med användarrepresentanter, onsite besök och observationer samt Use Case-workshops [5]. Dessa metoder fokuserar på att höja nivån av användarnas medverkan i designutvecklingen men de tenderar att misslyckas på ett antal punkter: Designers och användare är inte helt fokuserade på utvecklingsprocessen utan tenderar att ha uppgifter och agendor vid sidan om utvecklingsarbetet. Sociala och politiska aspekter av designbeslut tas inte i beaktande utan fokuseringen sker istället på att producera funktioner. Komplexitet i olika problemställningar och arbetssituationer är svåra att identifiera och porträttera. Fokuseringen på användaren och användarsituationen tenderar att förlora fokus ju längre utvecklingsprocessen fortlöper. I denna uppsats vill jag belysa två andra metoder som jag anser vara de mest användbara verktyg som man kan använda sig av i designarbetet av en produkt eller ett system. Dessa metoder är scenarios och personas. Båda metoderna är tänkt att användas för att fokusera användarnas påverkan på utvecklingen av designen. Jag har själv en viss erfarenhet av 2

användning av de två metoderna, men har under kursens gång fått en djupare insikt i hur de olika metoderna kan användas och kombineras. Jag vill även belysa mina erfarenheter som jag har av de olika metoderna samt hur jag anser att de bör användas. Scenarios Designers har länge använt scenarios som en teknik för att för att organisera, klargöra och kommunicera idéer men dessa har oftast inte involverar användare [1]. På senare tid har dock forskningen inom användarcentrerad utveckling och HCI pekat på fördelarna med att använda scenarios som en teknik för att både engagera användare och utvecklare i designarbetet [3]. Kort kan man beskriva scenarios som en berättelse där man målar upp en bild av specifika händelser eller scener. De har en miljö, agenter eller aktörer som har olika mål eller uppgifter, samt en handling, eller en sekvens av handlingar och händelser. Ofta skapas scenarios för att belysa specifika funktioner eller teknologier i den produkt som skall designas. Nedan följer ett exempel på ett scenario hämtat ur projektbeskrivningen till Sul.musicprojektet [7]: Linda är 7 år och tycker det är ganska roligt med musik. Hon spelar inget instrument, men har sagt till sin mamma att hon skulle vilja lära sig spela piano. Till sin födelsedag har Linda önskat sig ett par musikskor. Några av hennes kompisar har sådana, men Linda har aldrig provat några förut. Hon tycker de verkar kul och hon känner sig lite utanför när hennes kompisar spelar tillsammans. Lindas födelsedag har kommit. Hon öppnar paketet från sina föräldrar och blir jätteglad när hon upptäcker att hon fått sina efterlängtade musikskor. Hon tar genast på dem för att prova. Hennes pappa får hjälpa till att sätta på musikfunktionen eftersom Linda inte kan hitta knappen med en gång. Linda tar några steg för att prova och upptäcker att hon kan framkalla olika toner genom att alternativt stödja på tån och hälen. Höger- och vänsterskon ger också ifrån sig olika toner. Hon väger lite fram och bakåt på skorna, och provar sedan att vagga lite från sida till sida. I kartongen med skorna följde det med ett litet häfte med tips om hur man spelar olika melodier. Linda tittar i häftet och försöker spela Blinka lilla stjärna. Det är svårt och det tar en stund innan hon har lyckats koordinera ihop rätt rörelser med bägge fötterna. Linda tycker att de nya skorna är jättekul och hon håller på att leka med dom hela dagen tillsammans med sina kompisar Det finns dock vissa risker med att använda scenarios. En av de erfarenheter som jag har är att när man skapar scenarios så är det är ofta lite, eller ingen, diskussion kring det data som scenariot är baserat på. Ett scenario konstruerat av information som är empiriskt säkerställd genom olika typer av etnografisk analys, såsom information från intervjuer och analyser, observationer av användbarhets studier eller kombinationer av ovanstående, är ett kraftfullt verktyg. Men mer ofta så används scenarios istället för riktig data eftersom man inte anser sig ha tid att göra den grundliga undersökning som krävs. Man hittar helt enkelt på olika scenarios som uppfyller de mål som man själv sätter upp för 3

projektet. Efter att ha arbetat mycket med scenarios i analys och design så har jag insett att man måste hantera scenarios med stor försiktighet. Det finns även andra problem med scenarios. Även om de är baserade på information insamlad från användare måste man vara medveten om informationen kan vara vinklad eller inte helt objektiv. Människor kan ha svårt minnas, de kan vara påverkade av politiska eller sociala uppfattningar om omvärlden eller arbetsrutiner. De kan även vara påverkade av extrema upplevelser. Det är även svårt att porträttera arbetsuppgifter då användare tenderar att utföra sina arbetsuppgifter på olika sätt och med olika fokus. Man måste försöka skapa en generaliserad bild och beskrivning. Bødker[2] beskriver en innovativ användning av scenarios. Två detaljerade scenarios konstruerades runt användandet av samma föreslagna teknologi: en gladlynt utopisk vision samt en skräckvision. Genom denna ansats lyckades han att fokusera diskussionen på hur man skulle designa för att undvika icke önskvärda resultat samt att förstärka de positiva aspekterna av lösningen. Detta illustrerar indirekt svagheten av ett att använda sig av ett enda scenario för att beskriva en situation eller an funktion. Vidare så noterar Bødker att It gives a better effect to create scenarios that are caricatures it is much easier for users and whoever else is going to relate to the scenarios toassess things when they see full-blown consequences Not that they believe in the caricatures, indeed they do not, but it is much easier to use one s common sense judgment when confronted with a number of extremes than when judging based on some kind of middle ground. Personas Personas[8] är beskrivningar av uppdiktade personer. De har ett utseende, kläder, yrken, familjer, vänner, husdjur, ägodelar osv. De har ålder, kön, etnisk tillhörighet, utbildning och en ekonomisk status. De har en livshistoria, mål, och uppgifter. Min åsikt är att personas skapar ett starkt fokus på användare och arbetssituationer och metoden ger designern en möjlighet att fokusera uppmärksamheten på specifika användartyper eller målgrupper. Den hjälper till att etablera vem som det skall och vem det inte skall designas för. Man kan givetvis inte utveckla personas som täcker in alla tänkbara användare och användargrupper, men som jag ser det är detta bara en fördel. Det hjälper till att identifiera och fokusera på de olika typer av användare som är viktigast. Man kan säga att tekniken med personas utnyttjar vår möjlighet att extrapolera ej fullständig information och skapa en helhetsbild. Det ger även möjlighet att sätta in den tänkta användaren i nya miljöer och situationer som kanske inte är så uppenbara och som kan föra designen och utvecklingen av produkten vidare. Uppgiften att skapa personas hjälper även en designer att identifiera åsikter och uppfattningar som han har om den tänkta målgruppen. Och när de väl är skapade så hjälper de till att bibehålla de kriterier som ligger till grund för tidigare tagna designbeslut som t ex varför man bygger en viss funktion, eller varför bygger den på just detta sätt. Utan personas finns det en stor risk att utvecklare rutinmässigt tar beslut om utvecklingen 4

av funktioner och andra beslut runt implementationen utan att ta hänsyn till vem som skall använda produkten eller hur den kommer att användas. Enligt min erfarenhet finns det dock ett antal risker med att använda personas. Att hitta rätt persona, eller uppsättning personas, är en svårt. Personas bör enligt min åsikt tas fram för ett specifikt ändamål och inte för att möta allmänna krav, samt vara väl bearbetade och ha förankring i verkliga personkaraktärer. Det är även frestande att återanvända personas. Med den investering i utvecklingstid och resurser som det krävs för att ta fram bra personas är det lätt att falla för frestelsen att använda sig av redan existerande personas, när man egentligen borde överge en uppsättning karaktärer och ta fram en ny. Olika projekt och produkter har olika mål så man måste tänka över sina personas noggrant inför en användningssituation. Det är även lätt att falla för frestelsen att modifiera och tänja lite på redan uppsatta personaskaraktärer. Så länge som man kan hålla detta inom rimliga gränser och man inte avviker för mycket från ursprunglig data är det ok, men det kan komma att bli ett problem. Det kan bli en viss lockelse i att överanvända personas. I värsta fall kan de komma att användas istället för andra användarcentrerade metoder, insamlande av data samt produktutvärdering. Personas borde enligt min uppfattning användas för att komplettera redan existerande designprocesser samt för att förstärka fokus på användaren. Kombinera scenarios och personas Realistiska scenarier kan upplevas vara ett perfekt verktyg för design: de ger en bild av de arbetsrutiner och uppgifter som man hoppas stödja med sin design eller produkt. Deras största svaghet är att dock att de inte uppfattas som är tillräckligt engagerande och fullständiga. Scenarios är ofta svåra att komma ihåg samt få ett grepp om. Det är därför som Bødker argumenterade för karikatyrer, orealistiska extremer som är mer engagerande, mer minnesvärda. De extrema karaktärerna bidrar även, som tidigare nämnt, till att sätta fokus på scenariots gränser och begränsningar. Scenariot i sig saknar även en fokusering på användaren utan fokuseringen ligger istället på de situationer och händelser som beskrivs. I en designsituation där man önskar en användarcentrerad strategi är alltså inte scenarion i sig nog. Här kan man då kombinera de två metoderna genom att konstruera scenarios runt personas. För att utnyttja denna metod till max anser jag att man skall fokusera på personaskaraktärerna och se scenariot som ett sätt att komplettera beskrivningen av de olika personas. Personaskaraktärerna bör inte ses som aktörer i ett manus utan de är personer som man försöker beskriva genom att berätta om deras situationer ur deras arbets- eller vardagsliv. Genom att utnyttja dessa två metoder bör man som designer få en mer enhetlig om komplettare syn på den situation och de förutsättningar som designen skall stödja. Även synen på målgruppen samt hur de kommer att interagera och använda sig av den designade produkten eller systemet bör kännas mer enhetlig. Detta i och med att man får kombinationen av karaktären samt en beskrivning av den tänkta användningssituationen. 5

En kombination av de två metoderna anser jag vara ett bättre angreppssätt än att använda metoderna var för sig, men det bör naturligtvis vara något man beslutar inför varje designsituation. Slutsats Att använda scenarios som en fristående metod för att beskriva designsituationer är lockande men inte helt utan problem. De är enkla att missbruka och kräver en stor arbetsinsats samt noggrannhet för att vara användbara som underlag för ett designbeslut. De saknar även den fokusering på användaren som jag anser vara önskvärd i denna situation. Personas som fristående metod uppfyller bättre de kriterier jag har på ett användarfokuserat angreppssätt. Personas i sig är relativt enkla att använda och är ett kraftfullt verktyg när det gäller att designa för stora, diversifierade användargrupper. Men även tekniken med personas kräver en ganska stor arbetsinsats samt noggrannhet när de tas fram. Även personas bör användas med försiktighet. Jag har själv ingen erfarenhet av att använda personas i kombination med scenarios, men jag ser det som ett spännande och mer komplett sätt att använda de två olika metoderna. Jag har själv i ett flertal utvecklingsprojekt använt mig av personas eller scenarios som fristående metoder, och har upplevt en del av de nackdelar och problem som jag beskrivit tidigare. Genom att kombinera dessa två metoder får anser jag att man bättre kan utnyttja de positiva aspekterna med varje metod genom att man får en enhetligare och mer komplett bild över de situationer och målgrupper som man skall designa för. Referenser: [1] Burns, C., Dishman, E., Verplank, W. & Lassiter, B. (1994). Actors, hairdos & videotape Informance design. CHI 94 conference companion, 119-120. [2]. Bødker, S. (2000). Scenarios in user-centred design Setting the stage for reflection and action. [3]. Carroll, J. (Ed.) (1995). Scenario-based design. Wiley. [5] Jacobson (1992), Object-Oriented Software Engineering A Use Case Driven Approach, Addison-Wesley, ISBN 0-201-54435-0 [6] Preece, Rogers och Sharp (2002), Interaction Design beyond human-computer interaction, Wiley and sons, Inc. ISBN 0-471-49278-7 [7] Breneman, Friberg, Löfving, Malmberg och Stenberg(2003), Sul.music ett musikinstrument för barn, http://outrun.idc.cs.chalmers.se/~it3loan/ubicomp.htm 6

[8] Freydenson, E. (2002). Bringing your Personas to life in real life. http://boxesandarrows.com/archives/002343.php [9] Grudin och Pruitt (2002), Personas, Participatory Design and Product Development: An Infrastructure for Engagement, Proc. PDC 2002 7