Jonas Lundberg

LiU > ITN > MIT> Jonas Lundberg > Web Design (2006)> Aktivitetsanalys

Optimera for användarens aktivitet

När du ska optimera för användarens aktivitet bör du både söka efter övergripande mål, och hur de uppnås i olika aktiviteter. Det finns ett flertal metoder för att optimera för användarens aktivitet. Relaterat till design-nivåer hör de övergripande målen hör till nivån övergripande krav. Aktiviteterna, det vill säga hur aktiviteter utförs steg gör steg, hör till konceptdesignen. Du kan beskriva aktiviteter som scenarier, till exempel som functional flows. Den risk du tar om du hoppar över det här steget är att din tjänst stödjer fel aktiviteter. Till exempel kan du råka ut för att:

Det kanske går snabbare att utföra aktiviteten för hand.
Det kanske tar för lång tid att utföra aktiviteten, för att den överhuvudtaget ska vara värd att göras.
Konkurrentens uppgiftsvägar kanske är bättre.
Det kanske behövs mycket arbete bredvid din produkt, för att komma åt funktionalitet man verkligen behöver för att nå sitt mål.
Olika aktiviteter som utförs parallellt kanske krockar i din produkt, istället för att fungera samtidigt.
Onödig interaktion kan även orsaka arbetsskador.

Du riskerar också att stödja aktiviteten på ett klumpigt och ineffektivt sätt.

Metoder för upppgiftsanalys

Varje metod kan användas för mer än ett syfte. Jag har angett den engelska rubriken inom parentes så att du enklare kan hitta metoden på de sajter som är länkade nedan. Här ger jag bara en kort översikt över metoderna, som är beskrivna i mer detalj i de fem sajter som är länkade nedan. Det är alltså meningen att du ska läsa vidare där.

För detaljer i interaktion kan du använda notationen functional flows. övergripande mål, problem, och aktiviteter får du notera på annat sätt.

När du utformar en tjänst för webben, så har du två sidor att utforma. För det första, har du kundens vy(er). För det andra har du tjänsteproducentens vy(er). Tjänsteproducenten kan mycket väl ha en mer traditionell applikation att arbeta med. Även om du fokuserar på den ena av dessa två sidor, så måste du tänka på båda. En bra tjänst som inte går att producera, på grund av ett ineffektivt verktyg, kan inte heller presenteras för en kund. Uppdateringar av en sajt är överhuvudtaget något du bör fundera över, ifall den inte ska vara helt statisk. Du har därför minst två användare att tänka på. Den som ska producera / uppdatera tjänsten, och den som ska använda den producerade tjänsten.

Det finns nästan alltid användare att intervjua och observera. Även helt nya webbtjänster har en tänkt målgrupp, och en tänkt användning. Man kan alltid ta reda på vad dom gör nu, istället för att använda tjänsten. Man kan också ta reda på deras inställning till den tänkta tjänsten. Om det finns en konkurrerande tjänst, så kan man undersöka användningen av den. Längre fram i processen kan man använda en storyboard eller en prototyp, som visar upp funktionalitet, utan att vara helt klar. Du kan i vissa fall vilja ta fram en fungerande prototyp bara för att kunna göra realistiska tester och observationer. I andra fall vill du veta hur lovande din ide är lite tidigare i processen.

Många tjänster kan användas på allmänna platser, medan andra är tänkta att användas i hemmiljö. Om du anser att det blir för besvärligt att ordna tillgång till framtida användare, så drabbas du av de problem som listas ovan. Du kan också göra användbarhetstester, men de löser inte samma problem som aktivitetsanalysen.

Intervju (interview)

I en intervju kan du få veta bakgrunden till det arbete som utförs. Du kan få veta ungefär varför det utförs, och du kan få veta hur det borde utföras. Däremot får du inte veta exakt hur det utförs. Det beror på att människor har väldigt svårt att komma ihåg exakt hur saker görs. Det beror också på att man kanske inte jobbar exakt på det sätt som är föreskrivet. I en intervju kan du nå personer som inte jobbar direkt med din produkt. Till exempel, om du gör ett nytt verktyg för orderhantering, så kan du få ledningens syn på det systemet. Om det till exempel är en ny tjänst för hemsjukvård kan du få anhörigas syn på systemet.

Fokusgrupp (Focus Group)

I en fokusgrupp samlar du en grupp som får diskutera relativt fritt om ett ämne. Du kan använda fokusgruppen för att få veta till exempel vilka problem man ser sig ha just nu, eller vilka dom övergripande målen med produkten är. Du kan få veta saker som alla dina tänkta användare tycker är helt självklara, som till exempel att din idé är olaglig. Det vill du gärna veta innan du utvecklar din produkt eller tjänst. Fördelen med en fokusgrupp är att du får mer än en persons syn på det som diskuteras. För att få den fördelen måste du se till att alla kommer till tals. Precis som vid en intervju kan du inte få veta exakt hur en uppgift utförs i en fokusgrupp. I fokusgrupper kan du nå personer som inte jobbar direkt med din produkt, precis som i en intervju. I en intervju kan du få veta bakgrunden till det arbete som utförs. Du kan få veta ungefär varför det utförs, och du kan få veta hur det borde utföras. Däremot får du inte veta exakt hur det utförs. Det beror på att människor har väldigt svårt att komma ihåg exakt hur saker görs. Det beror också på att man kanske inte jobbar exakt på det sätt som är föreskrivet. I en intervju kan du nå personer som inte jobbar direkt med din produkt. Till exempel, om du gör ett nytt verktyg för orderhantering, så kan du få ledningens syn på det systemet. Om det till exempel är en ny tjänst för hemsjukvård kan du få anhörigas syn på systemet.

Framtidsverkstad (Future Workshop)

En framtidsverkstad är uppdelad i faser, som går ut på att först identifiera problem, sedan hitta möjliga lösningar, och sist utvärdera lösningarna och ta fram en plan för att genomföra någon av dem. Inte heller här kan du få veta exakt hur uppgifter utförs. Du kan använda olika metoder i de olika faserna, till exempel brainstorming i idéfasen, och prototyper eller scenarier för att hitta möjliga lösningar. I en framtidsverkstad kan du nå personer som inte jobbar direkt med din produkt, precis som i en intervju. Mer om framtidsverkstäder hittar du i min avhandling, på linköping university press.

Fältstudie (Ethnographic Study / Field Observation)

I en fältstudie kan du få veta vilka uppgifter som utförs, och hur dom faktiskt utförs. Det får du veta genom att observera aktiviteter. För att få en förklaring om varför de utförs, och varför de utförs på just det sätt de görs, måste du komplettera med en intervju eller fokusgrupp. Eftersom du kan observera problem när dom uppstår så behöver du inte förlita dig på att någon ska komma ihåg dem, som du måste göra vid en intervju.

Kontextuell undersökning (Contextual Inquiry)

En kontextuell undersökning blandar observation och intervju. Du försöker observera vad som görs, och samtidigt be användaren inflika förklaringar av det som görs. Idén bakom en kontextuell undersökning är både att få veta exakt hur aktiviteter utförs, varför dom utförs som dom gör, och hur miljön formar aktiviteten.

Enkät (Questionnaire)

Med en enkät kan du nå många användare, och fånga upp deras attityder, och de vanor de vill berätta om. Det kan hända att de beskriver de vanor de anser att de "borde" ha, snarare än de vanor de faktiskt har. Du kan nå många, men du får en ganska otydlig och opålitlig bild av skeendet. Om du gör en riktigt bra enkät med ett riktigt bra urval av respondenter kommer du runt en del av problemet. Men precis som vid intervjuer kan du inte få veta exakt hur saker görs.

Konkurrentanalys

Genom en konkurrentanalys kan du få veta vilka användningsområden dina konkurrenter tycks se, och vilka uppgifter dom ser ut att prioritera. Du kan testa, och se exakt hur olika uppgifter utförs. Du får däremot inte veta vilka mål dina kunder faktiskt har, genom att själv studera produkten. Om dina kunder använder produkten kan du komplettera med observation och intervju. Annars kan du jämföra de behov du funnit i intervjuer och observationer av din kunds aktiviteter, med konkurrentens produkt. Du kan jämföra din produkt eller tjänst med konkurrenter redan från din första kravbild, fram till ditt slutgiltiga test av din produkt. Men tänk på att konkurrenten mycket väl kan utveckla sin produkt eller tjänst, medan du utvecklar din. Även om du ser ut att "vinna" mot den nuvarande produkten, så kanske du inte "vinner" mot nästa version.