Vi presenterar här återigen de scenarion vi tidigare använt, den här gången med vår digitala prototyp som verktyg för att utforska dem.
Fig. 23 Kartan i digitala
prototypen. Fig. 24 Inrapporteringen där användaren kan ta en bild eller endast lämna
kommentar i digitala prototypen.
Fig. 25 Förhandsvisningen av en inrapportering i digitala prototypen.
Fig. 26 Kartan med en automatiserad bekräftelse på inskickad rapport i digitala prototypen.
Frank är på väg hem från skolan, den sista sträckan är som vanligt mörk eftersom lamporna är trasiga. Vanligtvis rullar Frank vidare eftersom han vet att han nästan är hemma men det stör honom (fig. 23).
Idag tänker Frank däremot att det kanske är dags att se till att kommunen äntligen fixar
lamporna så han tar fram sin
mobiltelefon, tar en bild för att sedan skicka den till kommunen (fig. 24).
Eftersom han är frustrerad på att det inte har fixats tidigare så
kommenterar han på att de har varit trasiga i två månader nu, “när ska de ta sig ut och fixa det” (fig. 25)?
Efter att han skickat iväg meddelandet noterar han en automatiserad bekräftelse på sin rapport (fig. 26).
Fig. 30 Karta i den digitala prototypen
Fig. 28 Kartan med legenden utdragen och pumpstationfiltret aktiverat i digitala prototypen.
Fig. 29 Inzoomad vy av kartan i digitala prototypen.
Fig. 30 Vägvisning till närmsta pump i den digitala prototypen.
På väg hem from jobbet upptäcker Daisy att hon inte har någon luft kvar i bakdäcket. (fig. 27)
Hon minns att det ska finnas en funktion för att visa pumpstationerna i Malmö. (fig. 28)
Hon zoomar in kartan och markerar den närmsta
pumpstationen. (fig. 29)
Daisy leder cykeln till den närmsta pumpen, fyller upp däcket och cyklar hem. (fig. 30)
Diskussion
I detta kapitel kommer vi att försöka besvara våra forskningsfrågor genom att presentera och diskutera våra resultat.
Vi har försökt besvara två frågor: “Hur kan man med hjälp av digitala hjälpmedel uppmuntra cyklister till att rapportera in störningar på cykelvägnätet?” och följdfrågan “Hur kan det digitala hjälpmedlet utformas för att ge ett pålitligt intryck med
lättillgängliga interaktioner?”. För att svara på dessa frågor har vi använt oss av litteraturstudier, intervjuer, användartester och protototyper.
Vi påbörjade projektet med en önskan att utforska hur rapporter om problem på Malmö cykelvägar kunde förbättras och effektiviseras. Detta gjordes till en början med utgångspunkt i en app som endast skötte inrapportering. Redan under brainstormingen breddades konceptet mot en app med fler funktioner. Från början strävade vi efter ett minimalistiskt uttryckssätt med få funktioner och en ren design. Allteftersom processen fortskred valde vi att lägga till fler funktioner, varför diskuteras mer ingående nedan. De funktioner vi valde att inkludera i vår app var nyheter, karta och inrapportering:
Innehåll
Nyhetsflödet fungerar som kommunens ansikte mot cyklisterna, enligt principen om styrande e-förvaltning (Chadwick och May 2003). Nyhetsflödet var begränsat till att hantera enbart nyheter från kommunen som kretsar kring vad som påverkar cyklister i Malmö eftersom det är appens användningsområde. Akadogan (2010)
argumenterar att medborgare saknar förtroende för kommunala hemsidor då de upplever att kommunal information sällan uppdateras. Vi kan se att en liknande problemtik med förtroendet finns i nyhetsflödet.
Akadogans förslag är att se till att information på kommunala hemsidor är
uppdaterade och att de senaste ändringarna är daterade så att besökare ser att det händer saker. Om kommunen uppdaterar långsamt tror vi däremot att Akadogans förslag kan ha motsatt effekt, då förstärks intrycket av långsamma uppdateringar vilket gör nyhetsflödet ointressant. Det innebär att för att en funktion som
nyhetsflödet skall fungera måste kommunen kontinuerligt ha nya artiklar och information som är intressanta för cyklister, annars kan nyhetsflödet ha en negativ effekt på appen som helhet. Kartfunktionen var också specifikt skapad för att underlätta för cyklister.
Inrapporteringen, projektets huvudfokus, upplevdes som sekundär för användarna när appen väl testades. Detta väcker frågor om huruvida användarna faktiskt skulle rapportera in om de visste hur de skulle göra. Det är tydligt bland de vi talat med att de använder primärt cykeln som fortskaffningsmedel, man vill därmed nå sin
destination så fort som möjligt. Även om de uppskattar möjligheten att rapportera till kommunen och vet om att det är i deras eget intresse att hjälpa till så är det möjligt att de avstår för att komma fram snabbare.
För dessa användare var appen bra om den hjälpte dem i trafiken men i övrigt mindre intressant. Detta visar på en konflikt mellan cyklisters långsiktiga intresse av väl underhållna vägar och deras kortsiktiga intresse av att nå sin destination.
Något som återkom under projektets gång var värdet av att inte tvingas lämna ut någon privat information. Samtidigt kunde majoriteten av användarna tänka sig att lämna ut privat information till kommunen så länge tvånget försvann. Det berodde på att de upplevde kommunen som pålitilig och dessutom var angelägna om att deras rapporter skulle leda till åtgärder.
En annan möjlighet till att de inte hade några problem med att lämna ut sina kontaktuppgifter i prototyperna kan vara att det var enkelt för dem då det bara innebar ett knapptryck, istället för att under en intervju överväga huruvida de var villiga att lämna ut sina kontaktuppgifter. Samtidigt tror vi det ändå är viktigt med valfrihet och transparens, det vill säga visa både vad som skickas men även hur det kommer att användas, i de uppgifter som lämnas vid en inrapportering.
Vi upplevde att fler funktioner skulle ge en större användarbas samtidigt som vi såg ett behov av att begränsa användningsområdet för att bevara intresset för appen bland cyklister. Samtidigt som cykeln är ett fortskaffningsmedel och cyklisterna är intresserade av vad som pågår runt omkring dem befarade vi att om vi breddade appen för mycket skulle det leda till urvattning av syftet med projektet. Det skulle alternativt innebära att vad som skulle kunna vara en funktionell app blev för bred och därmed otymplig och svårtillgänglig. En respons bland testanvändare var att de uppskattade att vår prototyp var avskalad. Testanvändarnas respons följer samtidigt Löwgren och Stoltermans (2004) argument om att användare med relativt enkla behov inte har någon användning av för komplicerade verktyg.
Prototyper
Att använda pappersprototyper gav oss feedback på utformandet av det grafiska gränssnittet innan vi började programmera. Det underlättade skapandet av den digitala prototypen eftersom det fanns en mall för layouten.
Greenberg (2012) menar att man kan skapa pappersprototyper digitalt så länge de ser skissade ut. Samtidigt upplevde vi genom tekniska problem att vi fick oväntad respons då våra utskrifter inte haft samma färger som de digitala kopiorna. Det gav oss bättre kritik kring symboliken då den var mer otydlig än vad vi ämnat. Det skapar frågor om att göra pappersprototyper medvetet vaga för att locka ut kritik och förslag på exempelvis hur formspråket skulle kunna se ut.
Att testa pappersprotoperna var till stora delar en tidskrävande process; det kunde ta lång tid att byta skärmar, framförallt vid skiften mellan scenarion. Tidsfördröjningen ledde till att det var svårt att upprätthålla fokus på testandet samtidigt som det under tiden kom kritik på layout eller koncept mitt i användartesten när ingenting hände på skärmen. Avsaknaden av tydliga klick- och dragbara knappar och menyer resulterade att några användare inte såg vissa interaktioner och därför hade svårt att följa med i gränssnittet. Däremot gav pappersprototypen rikligt med data kring hur konceptet kunde utvecklas och hur gränssnittet kunde förbättras för att bli tydligare.
De resultat som kom från den digitala prototypen handlade till stora delar om utforskning av hur de interaktioner som vi skapat fungerade i en mer slutgiltig prototyp. Legendens genvägar var baserade på bland annat fritids och
utomhusaktiviteter under sommaren, exempelvis badplatser. Genom att vissa var säsongsberoende skulle man genom att uppdatera legenden baserat på säsong eller events i Malmö kunna bidra till att appen känns uppdaterad.
För att vidare utveckla interaktioner och “touch and feel” i prototypen hade fler iterationer av den digitala prototypen krävts, samtidigt som det vi fick ut ifrån våra tester räckte för att bekräfta många av de slutsatser vi dragit från
pappersprototyperna.
Genom tester och intervjuer var det möjligt att ge ett svar på de forskningsfrågor vi ställt samtidigt som det krävs en lånsiktig drift av en motsvarande app för att bekräfta de slutsatser vi kunnat dra från våra resultat.
Sharp et al. (2007) varnar för att skapa Hi-Fi prototypen för tidigt vilket ledde till att vi skapade den digitala prototypen sent i processen. För att förbättra interaktionerna i appen kunde den skapats tidigare men skulle då ha skett på bekostnad av mindre arbete med pappersprototypen och utveckling av designprocessen.
Användartester
Analysen av målgruppen mynnade ut i ett fokus på survivors; dels var de en majoritet och dessutom kunde de lätt avskräckas från att använda en produkt om den var för komplicerad.
Under testerna var det samtidigt värt att notera att de som oftast klassas som apologister när det gäller tekniska lösningar gav den mest användbara kritiken på prototyperna. Detta har troligtvis att göra med att de genom att ha ett öppet sinne, testar olika lösningar, vet vad de upplever som stökigt eller omständligt och även står ut med att använda sådana lösningar när det inte finns bättre alternativ.
Kritik från de erfarna användarna blev snabbt reflekterande över hur appen kunde förbättras för att bli snabbare eller mer lättanvänd i sina funktioner. Det väckte frågor kring hur erfarna användare, s.k. apologister var behjälpliga i att utveckla prototypen till fördel för de mindre tekniskt kunniga användarna. Detta stämmer inte med vår tolkning av hur Cooper (2004) beskriver apologister och survivors.
Det finns samtidigt en konflikt mellan de två användargrupperna i antalet funktioner de vill ha med. Apologisterna uttryckte ofta att de vill själva kunna anpassa
användargränsnittet utifrån deras egna behov. I dessa fall har det varit viktigt att reflektera över vad som blir enklast snarare än vad som genererar mest
funktionalitet.
Att vi testade i miljöer som användarna var förhållandevis familjära med kan ha påverkat hur de såg och reagerade på appen. Exempelvis visste de redan var de flesta platser som visades i appen låg. Detta skulle kunna innebära att de såg mindre nytta i en vägvisarfunktion. Malmö är samtidigt inte en stor stad och det är osannolikt att det huvudsakliga användandet av appen kommer att ske på obekanta platser för brukarna.
En del av de användare som deltog när vi testade prototyperna hade deltagit i tidigare intervju eller tester och var därför redan bekanta med projektet. Detta kan ha påverkat deras svar och reflektioner och gjort att de haft större möjlighet att fundera över sina behov. Vi var nyfikna på att se om detta gjorde att de betedde sig mer som apologister och därmed ha fler tankar kring hur appen skulle kunna förbättras. Detta var inte fallet.
De användare som deltog antingen var bekanta med oss sedan tidigare eller var studenter på högskolan. Sannolikt är utbildningsnivån och teknikintresset bland dessa högre än hos de flesta Malmöbor. Detta kan vara ett problem vid skapande av en app för en bredare massa. Samtidigt vet vi inte hur utbildningsnivån ser ut bland cyklister i Malmö. Vad vårt urval tyckte var viktigt i appen kan därför skilja sig från de tänkta användarna. Samtidigt har urvalet inneburit en avslappnad testmiljö där det varit lätt att kommunicera idéer och tankar åt bägge håll.
Slutsatser
Utifrån den data som samlats ihop under projektet genom intervjuer och
användartester med cyklister i Malmö har vi bildat oss en uppfattning av hur digitala verktyg kan användas för att underlätta interaktionen mellan användarbas och aktör och fungera som touch-point för kommunens tjänster.
För att lyckas med en inrapporteringsapp bedömer vi att det är viktigt att de verktyg som utformas är lättillgängliga och synliga för en bred allmänhet också utanför den specifika intressegrupp aktören vänder sig till, även om appen fortsatt är
specialiserad för, som i det här fallet, cyklister.
Vi har därför dragit slutsatsen att för att nå den grupp man vill rikta sig till,
exempelvis inrapporterande cyklister, är en bred app riktad till alla stadens cyklister en möjlig lösning som skulle sätta verktyget i händerna på fler användare. Genom att fler individer i intressegruppen har tillgång till verktyget tror vi också att antalet
rapporter skulle öka under förutsättning att användarna upplever att deras rapporter värderas av aktören.
Vikten av att användarna vill känna sig uppskattade speglas även i hur gränssnittet kan utformas. Om nyheter eller kartor inte blir uppdaterade så kommer användarna att uppleva att appen också är förlegad och övergiven, vilket i sin tur leder till att de tappar intresset. Vidare är det viktigt att gränssnittet upplevs som lättanvänt, i vår forskning fick vi god respons för att gränssnittet upplevs som avskalat och att när det gällde att exempelvis skicka in en rapport så lotsas användaren tydligt igenom de steg som krävs.
Slutligen tror vi att transparens är viktigt i utformandet så att cyklisterna har
förtroende för att deras personliga information inte missbrukas och de vet precis vad det är de faktiskt delar med sig av då det ofta fanns en viss osäkerhet kring personlig integritet.