Notera att deltagande i denna workshop är obligatoriskt. Om du av någon anledning inte kan delta ska du ta kontakt med kursansvarig (se också instruktioner längst ned på denna sida).
Tid och plats
För campusstudenter: Onsdagen den 20 maj 09:15-12:00. Vi samlas i Ny109 och fördelar sedan ut oss bland rummen Ny106, Ny107, Ny108, Ny109 för gruppövningarna.
För distansstudenter: Onsdagen den 20 maj 13:15-16:00 via Adobe Connect:
Syftet med workshopen
Syftet med dagens workshop är att göra en grundlig utvärdering av hur gränssnittet presenterar din applikations funktionalitet för användaren och den resulterande användarupplevelsen det ger. Nu börjar vi närma oss slutet på kursen och applikationerna och gränssnitten börjar således sakta men säkert (förhoppningsvis 
Kom ihåg att vi i gränssnittskursen är intresserade framförallt av gränssnittet. Bakomliggande funktionalitet och programmeringstekniska detaljer och diskussioner kring sådant tillhör mjukvaruutvecklingskursen.
Mål för workshopen
- Att få insikt i nyttan med att använda användarscenarier för att beskriva och analysera de handlingssekvenser som användaren utför
- Att få insikt vikten av ett bra interaktionsflöde för att ge en god användarupplevelse
- Att identifiera förbättringspunkter för gränsnittet vad gäller interaktionsflöde och användarupplevelse
- Att få praktisk erfarenhet av användartestning
Dokumentation/redovisning
Användarscenariobeskrivningar, identifierade förbättringspunkter och sammanfattning av reflektion ska läggas ut på sidan för slutuppgiften senast 1 vecka efter workshopen – se instruktioner nedan.
Användarscenarier – kort beskrivning
Användarscenarier beskriver typiska uppgifter och handledningssekvenser som användare utför när de interagerar med applikationen. Användarscenarier beskrivs alltid ur användarens perspektiv. Användarscenariet ska ha en rubrik som tydligt (och kortfattat) beskriver vilken uppgift som det handlar om, en sammanfattning som i en eller två meningar beskriver scenariot, en beskrivning av startläget (vilka förutsättningar som behöver vara uppfyllda innan scenariot kan äga rum) och måltillståndet (vad som behöver vara uppfyllt för att scenariot ska gå at betrakta som framgångsrikt genomfört) samt en sekvensiell beskrivning av de steg som utförs för att fullgöra uppgiften som scenariot handlar om.
Det finns inga absoluta regler för hur begränsade/omfattande ett användarscenario ska vara, men en bra grundregel är att om man märker att beskrivningen av start- och måltillstånd blir lite långrandiga så är det en signal för att man ska fundera på att dela upp sitt scenario i mindre delar.
Användarscenarier används för att beskriva handlingarna som användare utför i ett gränssnitt. De kan användas som ett analysredskap för att identifiera logiska luckor eller onödigt besvärliga tillvägagångssätt (ur användarens synvinkel) i sekvenser av handlingar. När man skriver ned beskrivningar över handlingssekvenser och “provkör” dem så upptäcker man saker som man inte tänkt på (luckor) och saker som är onödigt krångliga (förbättringspunkter). Användarscenarier kan också användas som underlag till systemering och programmering, instruktioner/manualer/hjälpfunktion och som underlag för användartestning. Det är för det sistnämnda ändamålet som vi ska använda dem i denna workshop.
Användartestning – kort beskrivning
Användartestning används för att pröva gränssnittet på användaren. Genom att använda sig av utvecklingstekniker, riktlinjer, checklistor och personas så skapar vi bättre gränssnitt än vi gör utan dem och vi kommer fram till en “bättre gissning” om vad som kommer att funka. Det är dock alltid testet med riktiga (eller åtminstone representativa) användare som avgör om “gissningen” är bra nog eller om man behöver tänka om någon del.
Det finns många olika typer av användartestning. Ibland styr man användaren genom att ge denne särskilda uppgifter som han/hon ska utföra, ibland får användaren testa sig fram. Ibland testar man på en stor grupp användare, ibland bara på en eller ett fåtal. Ibland går man på djupet, ibland testar man mer ytligt. Allt beror på syftet med testet och i vilken fas av utvecklingen av gränssnittet man är. Oavsett syfte så bör användartestning bör vara ett återkommande inslag i utvecklingen av en applikation. Tidigt i utvecklingen så söker man input för att skapa en bra grunddesign. I senare delar av utvecklingen så söker man feedback på föreslagna lösningar så att man kan justera/modifiera lösningen. Efter lansering så söker man feedback hur applikationen fungerar skarpt läge och input kring hur den kan förbättras.
I denna workshop, som då är i den senare delen av utvecklingen så är vi ute efter feedback för att justera/modifiera designen av gränssnittet för att ge en bättre användarupplevelse. Vi har inte tillgång till “riktiga” användare, så vi får simulera användaren genom att återvända till våra personasbeskrivningar.
Har inte kommit så långt…
Den här workshopen, liksom övriga workshopar på kursen, har ett dubbel syfte. De är till för att 1) få prova på praktiska tekniker för gränssnittsutveckling och 2) att utveckla det gränssnitt som ni arbetar med genom att identifiera förbättringspunkter. Tidigare har vi arbetat med skisser och skärmbilder. Till dagens övning så ska ni använda er av era applikationer. Det innebär inte att de behöver vara helt färdiga. Ni använder er helt enkelt av den senaste versionen av er applikation eller gränssnittsprototyp och om det sedan innebär att man behöver fylla i luckorna vid användningstestningen för de delar av funktionaliteten som inte är färdig, så får man göra det, t ex genom fejkad funktionalitet eller genom att man berättar muntligt vad som är tänkt ska ske.
Arbete individuellt/arbete i grupp
I de stegvisa instruktionerna nedan är det angivet att vissa moment ska göras individuellt och andra i grupp. Det innebär inte att ni inte får diskutera och samarbete även i de individuella övningarna. Tvärt om – det är bara positivt att ni gör så i samtliga övningar. Skillnaden mellan momenten som är uppmärkta som individuellt respektive grupp är att för de individuella momenten är fokus på att producera något och i gruppmomenten så är fokus på diskussion.
Instruktioner
Inledning 10 minuter – i helklass
Syfte: Beskriva upplägg och syfte för dagens workshop.
Upplägg: Efter inledningen så delas klassen in i grupper. Vi använder samma grupper som ni har i mjukvaruutvecklingskursen (för er som inte läser denna kurs parallellt så delas ni in i en egen grupp eller placeras i en av dessa befintliga grupper). Sedan följer man instruktionerna nedan för de olika övningarna. Lärare kommer att förflytta sig mellan grupperna och observera, svara på frågor och delta. För den här workshopen kommer läraren att ha en mer aktiv roll och kommer att titta på varje gränssnitt var för sig för att ge synpunkter.
Användarscenarier
Steg 1.1 Användarscenarier – Skapa användarscenarier 20 minuter – individuellt
Syfte: Konkretisera vad användaren kan använda din applikation till.
- Skapa ett “lagom antal” användarscenarier för din applikation. Se till att hålla fokus på användarens perspektiv så att varje del av beskrivningen och sekvensen av handlingar beskrivs med relevanta termer för användaren. Använd gärna persona-beskrivningarna från tidigare workshop för att sätta dig in i användarens perpektiv. Senare i denna workshop kommer användarscenarierna användas som instruktionsunderlag för personas, så formulera dig gärna som att du riktar dig direkt till aktuell persona.
Fokusera på de typiska (vanliga) saker som användaren kommer att använda din applikation till eller om det är någon del av funktionaliteten som är särskilt viktig (kritisk) för att applikationen ska fullgöra den uppgift den används till. Undvik att beskriva vad som händer “bakom kulisserna” programmeringsmässigt. Ta bara med sådant som användaren behöver känna till för att utföra aktuell uppgift. Använd mallen nedan för att beskriva varje användarscenario.
Antalet scenarier beror på typ av applikation och hur omfattande varje användarscenario är. Du ska dock skapa minst två olika användarscenarier (gärna fler). Lägg inte för mycket tid på formuleringar och detaljerna. Det viktiga för aktuell övning är att få ned översiktliga beskrivningar för de typiska saker som användarna ska använda din applikation till. Passa på att notera de logiska luckar, inkonsekvenser eller onödigt krångliga handlingssekvenser som du upptäcker under denna övning.
Steg 1.2 Användarscenarier – presentation och diskussion kring användarscenarier 20 minuter – i grupp
Syfte: Få förståelse för vad användarscenarior kan användas till och vad de bör innehålla samt hur de bör formateras (fokus och omfattning) för att vara användbara.
- Diskutera i tur och ordning era beskrivningar av användarscenarior. Diskutera innehåll och format. Innehåll handlar om uppgifterna som användarscenarierna beskriver och som användarna ska utföra. Format handlar om hur de presenteras i beskrivningen av användarscenariot. Kom ihåg att beskrivningen ska utgå ifrån användarens perspektiv och handla om dennes interaktion med gränssnittet. Passa på att notera förändringsförslag till dina användningsscenarior. I nästa övnings första steg så ges möjlighet att revidera beskrivningarna.
Användartestning
Steg 2.1 Användartestning – förberedelse till testning genom revidering av personas och scenariobeskrivningar 10 minuter – individuellt
Syfte: Förbereda scenarier till att fungera som underlag för användartestning.
- Plocka fram personasbeskrivningarna från första workshopen. Uppdatera dig på innehållet i denna och gör smärre förändringar om det är något som inte stämmer längre.
- Utgå ifrån användarens perspektiv genom att använda din/dina persona/personas och gå igenom scenariobeskrivningarna för att säkerställa att de är beskrivna från användarens perspektiv. När de används i nästa steg så ska de beskrivas för användaren som uppgifter som ska utföras – “vad” som ska utföras, hellre än “hur”. Passa också på att förändra beskrivningen utifrån de kommentarer som du fick från föregående övning när scenariobeskrivningarna diskuterades i grupp. Målet här är att förbereda scenariobeskrivningarna så att de ska kunna användas som underlag för användartestningen i nästa steg.
- Om du har fler scenariobeskrivning än du tror att man hinner gå igenom på de c:a 20-30 minuter (de sista 10 minuterna är reserverade för analys av fokuspunkter) som är avsatt för testningen, så skapa en prioriteringslista bland användarscenariorna (med den “viktigaste” först).
Steg 2.2 Användartestning – Testning med hjälp av personas och användarscenarier 30-40 minuter per applikation – i grupp
Syfte: Att identifiera förbättringspunkter för gränssnittet som helhet med fokus på interaktionsflöde och användarupplevelse samt att få insikt i på vilket sätt interaktionsflödet bidrar till användarupplevelsen.
Genomför användartestningen för varje applikation i tur och ordning. Är ni få i gruppen så kan ni ägna mer tid till varje applikation är ni fler så får ni fördela tiden jämt mellan applikationerna. Ägna dock minst 30 minuter per applikation. Är ni många i gruppen så kan gruppen delas upp i mindre grupper i detta steg med 2 eller 3 personer i varje subgrupp. Ni ska ha tid att gå på djupet i analysen av respektive applikation.
- Plocka fram personabeskrivningarna på nytt. Utse någon i gruppen att spela den roll som personan beskriver. Har du mer än en persona som du vill testa, så kan ytterligare en persona-roll tilldelas till någon annan i gruppen (förutsatt att gruppen består av minst tre personer – samma person bör inte spela mer än en roll). Begränsa er till max två personas. Ge personen/personerna någon minut att sätta sig in i persona-rollen.
- Använd scenariobeskrivningarna för att genomföra användartestet. För varje scenario, börja med bara använda rubriken för att se om det räcker för att användaren ska kunna utföra den anvisade uppgiften. Behövs mer information, använd den korta beskrivning och beskrivningen av start- och måltillstånd. Undvik dock att beskriva uppgiften i form av instruktioner av typen “klicka på menyalternativ A, klicka sedan på köp-knappen för objekt B”. Med sådan typ av beskrivning så mäter man inte användarens förmåga att förstå och använda gränssnittets funktionalitet, utan deras förmåga att följa instruktioner. Bättre då är att fokusera på uppgiften, alltså “vad” som ska göras istället för “hur”. Applikationsägaren antar rollen som operatör – den som leder användartestet och svarar på användarens frågor. Operatören är också den som fyller i detaljer för delar av funktionaliteten som inte är implementerade ännu eller delvis implementerade. Användaren ska tänka högt under hela övningen, dvs att beskriva vad han/hon tänker i varje steg när han/hon utför scenariet. Det är en viktig del av övningen att användaren använder den så kallade talk-aloud tekniken. Det är en vanlig metod för att analysera gränssnitt under testning och ger insikt i användarens (annars osynliga och omätbara) inre tankeprocesser.
- Använd de sista 10 minuterna för att analysera och reflektera kring övningen utifrån de nedan angivna fokuspunkterna. Syftet är att förbättra er förståelse för på vilket sätt interaktionsflöde bidrar till användarupplevelsen och för att identifiera förbättringspunkter för applikationen. Applikationsägaren noterar förbättringspunkterna som tas upp. (Tänk på att ni kan ta upp identifierade men ej åtgärdade förbättringspunkter i slutrapporten och således få kredit för att ha identifierat/tänkt på dem även om ni inte hunnit eller kunnat implementera dem).
- Interaktionsflöde - Är det tydligt för användaren vilka möjliga val han/hon har i varje läge? Är det bra flow i användandet av applikationen – kan användaren fokusera på uppgiften som ska utföras utan att behöva lägga onödigt mycket energi på detaljerna i hur användargränssnittets knappar och komponenter fungerar? Känner användaren att han/hon kontrollerar vad som händer? Är den feedback som användaren får tillräcklig och ges i rätt tid? Är det lätt att göra rätt och svårt att göra fel?
- Användarupplevelse - Är applikationen väl anpassad till målgruppen och de uppgifter som applikationen hjälper användaren att utföra? Presenteras funktionerna på ett lättförståeligt och ändamålsenligt sätt för användaren? Hur kan användarupplevelsen beskrivas (kul, stimulerande, effektiv, förtroendeingivande, lättlärt, lättanvänt)? Vilken användarupplevelse ville man ge användaren hur väl har man lyckats med detta? Är helhetintrycket bra från användarens perspektiv?
- Tillgänglighet - Riktar man sig till allmänna populationen (vemsomhelst) med sin applikation kan man räkna med att minst 10% av användarna har någon typ av funktionsnedsättning (syn, färgseende, hörsel, kognitiv funktion). Kan man ta någon särskild hänsyn till dessa grupper, behöver eller bör man göra det? Hur kan man i designen av applikationen och dess gränssnitt visa sådan hänsyn och vad innebär det om man inte gör det?
Reflektion
Steg 3.1 Reflektion avslutande 15 minuter – i grupp
Syfte: Reflektera över hur användarscenarior och användartestning som metoder är användbara vid gränssnittsutveckling.
- Diskutera nyttan av och användningsområden för metoden användarscenarior vid gränssnittsutveckling (fokusera på utvecklingen av just gränssnittet)
- Diskutera nyttan av och användningsområden för användartestning vid olika faser i ett applikationsutvecklingsprojekt
- Vilka förbättringspunkter identifierade du för din applikation? – Vilken typ av förbättringspunkter handlade det om? Handlade de om att förbättra interaktionsflödet – och är interaktionsflöde som begrepp ett nyttigt “redskap” just för att identifiera förbättringspunkter i ett gränssnitt?
Dokumentation/redovisning på sidan för slutuppgiften
Syfte: Att presentera produkterna från workshopen.
På sidan för slutuppgiften ska följande presenteras:
- Användarscenariobeskrivningarna
- Identifierade förbättringspunkter
- Sammanfattning av reflektionssteget (kortfattat – punktvis eller i löpande text)
- Om förändringar gjorts i persona-beskrivningarna, uppdatera i så fall också gärna dessa på sidan för slutuppgiften
Obs! Dokumentationen ska finnas på kurssidan senast 1 vecka efter workshopen.
Särskilda instruktioner för distansstudenter
Workshop i Adobe Connect med break out groups
För distansstudenter så kommer denna övning att genomföras med hjälp av Adobe Connect. Vi kommer att använda oss av funktionen break-out groups för att dela in er i grupper (samma indelning i grupper används som för mjukvaruutvecklingskursen – och för er som inte läser den kursen parallellt så kommer ni att placeras i en grupp).
Ljud i Adobe Connect för gruppövningarna
Det finns stöd för ljud (audio) och video (webcam) i Adobe Connect. Video är frivilligt, men ni ska använda er av ljudkommunikation för att prata med varandra. Läraren kommer att gå mellan de olika rummen och hjälpa till, svara på frågor och delta i övningarna och för att det ska fungera behöver ni använda er av kommunikationsfunktionerna i Adobe Connect (i motsats t ex att använda er av Skype för ljudet). Om ni inte får ljudet att fungera så kan Skype eller chatten användas, men det är bara i undantagsfall.Headset rekommenderas för bästa ljud in och ut. Om du inte har tillgång till headset så rekommenderas du att stänga av din mikrofon när du inte pratar för att undvika ekon och missljud.
Uppladdning av dokument och Whiteboard-funktioner
Ni kommer att behöva dela med er av era användarscenariobeskrivningar och personasbeskrivningar. Ladda upp dessa på samma sätt som tidigare dokument. Lämpligt format är pdf. Detta gör man genom att använda delningsfunktionen – Sharing pod. För att ladda upp dokument till sharing-podden gör man så här:
- Klicka på drop down-knappen i sharing-podden (den där det står Share My Screen)
- Välj Share document
- Ladda upp dokumentet
Genom att klicka på Draw-knappen i övre listen på sharing-podden så aktiverar man whiteboard-funktionerna som gör att man kan rita och skriva ovanpå bilden som laddas upp.
Skärmdelning för användartestning
För användartestningen så ska ni använda er av skärmdelning. Applikationsägaren initierar skärmdelningen genom att välja att dela ut sin skärm: Share my screen. Man kan här välja att dela ut hela skärmen, en monitor (om man har mer än en monitor kopplad till sin dator) eller en applikation. Välj lämpligt alternativ här.
Personen i användarrollen får sedan begära att få kontroll över markören för att kunna fjärrstyra applikationsägarens dator/applikation. Det gör man genom att klicka på knappen med etiketten: Request Control som man hittar uppe till höger i Sharing podden. Applikationsägaren klickar för att acceptera begäran och användaren kan nu fjärrstyra applikationen. Notera att det kan vara lite segt att fjärrstyra datorn på det här sättet och det kan därför ta någon sekund eller två innan det händer något när man klickar på en knapp. Ta hänsyn till detta när ni bedömer interaktionsflöde och feedback i applikationen vid testningen.
Instruktioner för dig som inte kunnat delta i den obligatoriska workshopen
Notera: Deltagande i workshop är obligatorisk och giltig anledning ska finnas om man inte deltar. Ta kontakt med kursansvarig om du inte kan delta. Saknas giltig anledning kommer detta att påverka betygsbedömningen för slutuppgiften.
Instruktioner: För dig som inte kunnat vara med på workshopen så ska workshopen genomföras på egen hand. När det gäller användartestningen så gäller det att du anstränger dig särskilt för att leva dig in i rollen som din persona och att glömma bort allt du vet om hur applikationen är tänkt att fungera. Försök gå utanför dig själv för att se på din applikation med med fräscha ögon. Dokumentation för dina framtagna användarscenariobeskrivningar och identifierade förbättringspunkter ska läggas upp på sidan för slutuppgiften. Du ska dessutom skriva en förlängd reflektionsdel motsvarande c:a en A4-sida text som också läggs upp på sidan för slutuppgiften.
