Projektreflektion

OBS: Notera att detta inlägg är gemensamt, dvs. alla i gruppen har hjälpt till att skriva det.

Problemet

Vi i gruppen har arbetat med hur man skulle kunna erbjuda turister en bättre upplevelse av deras besök i Stockholm. Det första vi behövde göra i arbetet var att identifiera ett problem som vi skulle lösa. Att utveckla en produkt som löser ett problem utan att veta om problemet ens existerar är inte en bra idé. Vi visste att det skulle finnas problem och svårigheter för en turist här, men å andra sidan kan det vara svårt att identifiera dessa problem eftersom Stockholm är en relativt turistvänlig och mångkulturell stad med tydliga skyltningar och lättillgängliga sevärdheter att besöka. För att komma igång med arbetet valde vi att definiera några tänkbara målgrupper och vilka problem vi trodde att de skulle kunna ha som turister i Stockholm. Kapitel två i boken behandlar den här delen av utvecklingsprocessen. I kap. 2.2 säger boken att “Identifying usability and user experience goals is a prerequisite to understand the problem space.” Vi inledde utvecklingsprocessen med att skriva ner våra antaganden och idéer för att senare få reda på om de gick att stödja på något vis och för att få en bild av situationen.

Utifrån de målgrupper vi hade definierat spånade vi på produktidéer som vi i gruppen ansåg skulle kunna lösa problem som målgruppen hade. En tänkbar idé som togs upp var en applikation för mathandel till smartphones. Prisinformation och dylikt finns oftast bara tillgängligt på svenska, vilket gör det betydligt svårare för utländska turister att handla sina matvaror här i Stockholm. Därför kan problemet lösas i vår applikation genom att bidra med matinformationen på ett annat språk, t.ex. på engelska, genom att skanna in streckkoden på varan.
En annan idé som kom fram var en webbaserad reseplanerare som skulle tillhandahålla information om aktiviteter i Stockholm. Aktiviteterna rekommenderas baserat på intressen angivna av användaren. En aktivitet ska kunna röstas på av användarna.

Intervjuer, målgrupp, personas, scenarier

Intervjuer

Vi satte sedan igång med informationsinsamligen för att undersöka vilka svårigheter turisterna i Stockholm har och kontrollera ifall våra produktidéer går att lösa något av problemen. För att intervjuerna skulle ge oss bra svar på bägge frågor valde vi att genomföra så kallade semi-strukturerade intervjuer (7.4.3 i kursboken) där vi ställde frågor som till exempel “Har du funnit svårigheter med att handla mat i Stockholm?”. På det sättet kunde vi ta reda på om våra förutspådda problem faktiskt existerade. Vi intervjuade egna kontakter och främlingar via e-post, på internet och ute på plats. Intervjuerna gav blandade resultat. I vissa fall insåg vi att intervjuerna inte gav några belägg för våra förutspådda problem; många talar tillräckligt bra engelska och fick den hjälp de behövde för att anse sig själva vara nöjda med sin Stockholmsvistelse. Dock gav några intervuer väldigt intressanta resultat.

Dock gav några intervjuer väldigt intressanta resultat. En intervju med ett tyskt par påvisade att det fanns ett problem som var aktuellt och som var värd att undersöka vidare. De hade tagit sig hit till Stockholm i februari för att vistas här i en vecka. De hade besökt hemsidan visitstockholm.se, som är en av de främsta turistportalerna för de som planerar en resa till Stockholm. Där hade det målats upp en bild av ett aktivt och levande turist-Stockholm som verkligen såg lockande ut för de tyska turisterna vi intervjuade. Men väl på plats insåg de att det mesta hade stängts för säsongen, bl.a. Stockholms stadshus, vilket var en stor besvikelse för dem. Detta påverkade givetvis deras upplevelse.

Vi tyckte att det här var ett ganska stort problem, som faktiskt gick att lösa med en välutformad reseplanerare. Vi fick alltså belägg för vår tidigare framtagna produktidé: en webbaserad reseplanerare. Därför valde vi att gå vidare med denna tjänst. Det här sättet att analysera våra intervjuer på, vår data, kallas för kvalitativ datainsamling. Med kvalitativ menas det att man mäter sådant som inte har med siffror att göra (antal, åldrar etc.) utan försöker istället fokusera på mer specifika saker såsom känslomässiga uttryck (frustration i det här fallet). Boken tar upp detta i kapitel åtta (främst 8.2), där vi även fick mer ingående information om hur vi skulle analysera informationen som samlats in. Vi försökte se mönster i resultatet av insamlingen och jämföra behoven med målgruppens. Även gjorde vi en think-aloud övning som innebär att man låter en testperson, någon utomstående, utföra en given uppgift och därefter behandlar man i gruppen insamlad data. I vårt fall lät vi en person utföra en viss uppgift på Stockholm stads hemsida. Därefter kunde vi analysera informationen mer ingående, vilket senare skulle ge oss belägg för våra idéer.

Tyskarna nämnde även att det vore bra med enbart en sökfunktion som söker och returnerar aktivitetsinformation med aktuella tider.

Målgrupp

Vår reseplanerare skulle rikta sig till turister från både Sverige och utlandet och personer som befann sig i Stockholm av en annan anledning än att turista, men ville hitta på något där på plats. Målgruppen har användning av vår reseplanerare i olika situationer, allt från under semestern till helgutflykten. Vi tänkte att samtliga i målgruppen också har användning av den mer generella sökfunktionen på hemsidan som på ett smidigt sätt returnerar relevanta aktiviteter med utförlig tidsinformation. Speciellt dessa personer som inte hade planerat sin Stockholmsresa i förväg.

Personas och feedback

Genom att undersöka våra målgrupper och intervjuer kunde vi ta fram två stycken personas vars personligheter representerade våra användare. Dessa personas var Susan Michaels och Freddi Hofmann, och mer information om dem finns här.

Under projektets gång insåg vi gång på gång hur användbara våra personas var. Flera gånger då vi hade problem med något kunde vi tänka på vad som skulle passa Susan (vårt primärpersona) bäst och vi känner att det har hjälpt oss väldigt mycket. Den viktigaste användningen vi fick av våra personas var dock möjligheten att motivera nästan varenda funktion på hela tjänsten i vår funktionslista. Man kan läsa mer om funktionslistor, funktionsbeskrivningar och personas i kursboken kapitel 10.

Efter att vi presenterat vårt projekt för grupp C5 fick vi viss feedback. C5 tyckte att vi hade en för bred målgrupp och att vår tjänst hade ett otydligt ändamål. Vi tog emot kritiken och insåg att vår separata aktivitetssökaren riktar sig till en målgrupp som inte vill planera resor, detta blir inkonsekvent i våra designbeslut då vissa funktioner anses vara överflödiga för ena målgruppen men essentiella för den andra. För att ge programmet mer effektivitet beslutade vi oss för att endast fokusera på reseplaneraren och fokusera på målgruppen turister som vill planera resor. Vi minskade alltså tjänstens funktionalitet. Därmed utgjorde personat Freddi Hofmann ingen större nytta för vår fortsatta tjänstutveckling. Vi bytte ut Freddi mot Alexei Dragunov, en 30-årig egenföretagare i webbdesign från Ryssland. Han är väldigt duktig med datorer och är intresserad av att besöka muséer och konstutställningar. Han har dessutom en flickvän.

Alexei har mycket tid till att resa eftersom han är en egenföretagare som disponerar sin egen arbetstid. Detta innebär t.ex. att han kan resa till Stockholm under lågsäsong, vilket inte är av intresse för primärpersonat Susan. Då han har en flickvän som möjlig resekamrat, kan det också vara intressant för Alexei att kunna planera flera resor samtidigt. Eftersom Alexei finner ett intresse i att besöka Stockholm under vinterhalvåret, representerar han den delen av vår målgrupp väl. Det tyska paret som vi intervjuade tidigare hör till samma målgrupp som Alexei och hans flickvän.

Designbeslut och prototyp

När vi hade fastställt en målgrupp och personas för vår produkt började vi undersöka vilka funktioner en webbaserad reseplanerare med aktivitetssökare bör ha. Vi använde oss bland annat av funktionstabeller, personas och scenarier för att evaluera idéerna, dvs. att vi jämförde varje funktion mot bägge personas behov. Efter framställd funktionslista genomgick även alla funktioner våra scenarier och nyskapade use-cases för att upptäcka svagheter eller problem med dem. Detta kunde vara problem som att det i vissa steg i tjänstens användning var otydligt var som hände. Denna metod skrevs det om i kapitel 10 och 11 i kursboken och det var en praktiskt metod då den ganska snabbt gav oss en överblick över vilka delar av prototypen som skulle vara känsliga för dålig design.

Under designprocessens gång tog vi i första hand hänsyn till hur användarna kommer att använda produkten. Med andra ord var vår designprocess till största delen aktivitetscentrerad, men vi tog även mycket hänsyn till användarnas behov, vilket kallas för användarcentrerad design. Anledningen till att vi i första hand valde att fokusera på användarnas handlingar var att det var mycket viktigt att planeringsprocessen var så enkel som möjligt, med få eller inga element som kunde förvirra användarna.

Då vi designade applikationen kände vi att det var viktigt att hemsidans utseende förblev detsamma då användaren navigerade mellan olika sidor. Ett exempel på detta är menylisten som visas längst upp på varje sida. Dessutom var det viktigt att den fungerade och såg likadan ut i alla de vanligaste webbläsarna också. Ett av våra mål var att användaren skulle kunna komma åt de funktioner som fanns i menylisten oavsett om de var på förstasidan, höll på att planera en resa eller befann sig någon annanstans på sidan. Detta kallas för consistency, och behandlas i bokens första kapitel. Syftet är att användaren lätt ska känna igen sig överallt och veta vad alla funktioner gör, istället för att behöva lära sig något nytt på varje sida.

Det var även consistency vi hade i åtanke när vi bestämde oss för att använda pop-up rutor på flera ställen och även designa dem likadant överallt på sidan. Att använda pop-up rutor är ett enkelt och intuitivt sätt att visa stora mängder information på ett översiktligt sätt och det är lätt att lära sig att använda dem. Detta skrivs det om i kursboken i kapitel 3.2.

För att undvika att användarna känner sig tvingade att följa aktiviteternas öppettider då de utformar sitt schema valde vi att endast visa en enkel varning om en aktivitet ligger utanför dess öppettider. Varningen var endast tänkt att fånga användarens uppmärksamhet i de fall då placeringen inte var medveten. Om användaren med flit hade lagt en aktivitet utanför dess öppettider, t.ex. för att de visste att de kunde komma in trots att den var stängd, kunde de lätt ignorera varningen. Anledningen till att vi valde att göra på detta sätt var för att undvika att användaren upplever frustration på grund av för många oklara felmeddelanden.

Tidigt i designprocessen pratade vi om att använda enfärgade ikoner för att signalera till användaren att en aktivitet t.ex. var barnvänlig eller handikappsanpassad. Vi insåg dock snabbt att det kunde leda till problem för användare som var färgblinda eller hade någon annan sorts synnedsättning. I linje med bokens lärdomar om tillgänglighet valde vi därför att använda bilder, t.ex. en barnvagn, som ikoner.

Vårt första utkast på applikationens design hade ett ganska rörigt flöde. Det innebär att användaren fick gå från vänster till höger och tillbaka flera gånger då de lade till aktiviteter, vilket inte var optimalt. Vi valde därför att ändra designen så att den riktar användarens fokus naturligt från vänster till höger, likt figuren på sida 185 i boken, men vi valde dock att ändra designen något så att den bättre passade vår produkt.

För att ytterligare utöka användarvänligheten i vår prototyp gjorde vi också ett medvetet val i att fokusera på manipulativ interaktion. Det går att läsa om i kursboken kapitel 2.5, men sammanfattningsvis handlar det om att användaren interagerar med prototypen likt ett fysiskt objekt. Det gäller inte överallt på hemsidan, men på planeringssidan kan man se exempel på det i hur man lägger till aktiviteter i schemat. För att göra detta så tar man tag i och drar den valda aktiviteten. Vi valde denna interaktionstyp för att vi kände att den är naturlig och även underhållande att använda, och det passar vårt primärpersona som inte är jätteduktig på datorer.

Det är även värt att nämna att själva schemat är en så kallat interface metaphor (kursboken kapitel 2.4). Med det menas att det är en digital representation av ett vardagligt fysiskt objekt - i det här fallet en kalender. Det låter självklart, men det är en viktig del av designen och vi har märkt flera gånger under projektets gång att de viktigaste designvalen ofta är de mest självklara.

Efter att ha gjort ett antal designskisser som illustrerade ett tänkbart utseende för applikationen gick vi vidare med att göra en prototyp. Vi valde att göra en så kallad high-fidelity prototype för att kunna demonstrera våra funktioner på ett så bra sätt som möjligt. Med en low-fidelity prototype kunde det bli svårt att få med alla funktioner som vi ville utan att prototypen skulle bli rörig och invecklad. Med den typen av prototyp vi valde att utveckla kunde vi lätt lägga till nya funktioner allt eftersom att prototypens utveckling fortskred.

Första design-utkasten

Idag satte vi i gruppen oss och började fila lite på designen för vår produkt. Det var väldigt givande och efter mycket diskussion lyckades vi komma fram till några idéer och skisser som vi ska försöka arbeta vidare på i framtiden.

Startsida:

 Den viktigaste aspekten hos startsidan är att det ska vara relativt lite information, och att det ska vara enkelt att förstå vad det är man kan göra. Detta har vi tyckt sedan vi först kom på idén. Därför har vi i skissen endast en huvudmeny med länkar till olika sidor på hemsidan (About Us, Contact etc.) och en ruta med väldigt kort information om tjänsten. Under rutan har vi en lista på populära resor som andra användare har delat med sig av. Man kan sortera den här listan efter betyg, tid osv.

Knappar som det står "Begin" på (detta kommer antagligen att ändras till något mer passande senare) ska vara konsistenta och alltid leda till sidan där man planerar sin resa. Innan man kommer dit får man dock göra ett val: i skissen syns ett pop-up-fönster där skillnaderna mellan att vara registrerad eller inte beskrivs. Vi har tyckt sedan början att det är viktigt att man ska kunna använda sig av tjänsten utan att behöva registrera sig, men vi vill gärna att användarna gör det ändå, så vi erbjuder några "perks" som att man kan spara resor eller rösta på aktiviteter osv. Under informationen kan man sedan välja mellan att registrera sig, att logga in eller att planera resa utan att registrera sig. Väljer man att registrera sig så får man ett bekräftningsmail, sedan kan man gå vidare!
_________________________________________________________________________________

Planering av resa v1:

Skissen ovan är vår första idé för hur sidan där man planerar sin resa ska se ut. Vi gillar upplägget, och det liknar den senare versionen, men vi insåg att det fanns några problem med v1.

En viktig del av vår tjänst är att hela resan planeras på ett och samma ställe. Vi märkte på andra sidor att det är vanligt att man först söker på en aktivitet, sen går man in på aktivitetens hemsida osv. Vi vill att all nödvändig information ska vara samlad på en sida, så att man slipper flytta runt sig så mycket på hemsidan. Därför är designen väldigt dynamisk och ändras mycket beroende på hur man använder tjänsten.

Menyn längst upp är samma som på startsidan (konsekvent).

Rutan i övre vänstra hörnet är den där man skriver in informationen man vet om sin resa: vilket datum är det och vad är dina intressen. Utefter att användaren fyller i sina intressen så ändras rutan till höger, där rekommenderade aktiviteter visas. Den listan går att sortera efter aktiviteternas namn, betyg, öppetider etc. Man kan även söka i listan om man letar efter någon specifik aktivitet.

Rutan med dina intressen är också dynamisk. För att kunna ge bättre rekommendationer har varje intresse flera sub-intressen. Till exempel kan du välja super-intresset "Djur", och sedan välja "Katter" som sub-intresse. Väljer du endast "Djur" så visas alla aktiviteter relaterat till det. Väljer du "Katter" visas endast aktiviteter rekommenderade för det.

Om man vill veta mer om en aktivitet kan man markera den genom att klicka på den. Då öppnas en ny ruta under intresserutan, där man får se mer exakta öppetider, läsa recensioner för aktiviteten osv.

Längst ner på sidan sitter schemat. Schemat är anpassat för att visa ungefär 7-10 dagar på samma sida, men man kan även scrolla i sidled om man ska vara borta längre än så. När man markerat en aktivitet så "lyser" de tidsluckor i schemat där aktiviteten passar in (med öppetider i åtanke) upp. Det här hjälper användaren se om hon kan gå på en viss aktivitet eller om den tyvärr inte passar in i hennes resa.

Det största problemet med denna design är rutan med extra information om aktiviteter. Vi tyckte att den inte var tillräckligt stor för att visa all den information som vi ville ha. Helst av allt vill vi att informationen ska vara tillgänglig även utan att man ska behöva scrolla ner, och om vi har flera recensioner kommer det vara svårt att uppnå. Därav v2:
_________________________________________________________________________________

Planera resa v2:

Den här versionen har mycket mer fokus på att visa mer information på ett bättre sätt än v1. Uteslutet från skissen är huvudmenyn som fortfarande ska ligga längst uppe på sidan och innehålla länkar till startsidan, kontaktinformation och så vidare.

Den största skillnaden mellan v2 och v1 är att vi i v2 har gjort aktivitetsfönstret mycket större. Intressefönstret ligger fortfarande åt vänster, eftersom vi kände att det är logiskt ur ett designperspektiv (man läser från vänster till höger, så man börjar med att välja intressen och får resultat i aktivitetsfönstret).

När man väljer en aktivitet i v2 får man istället för en liten ruta upp ett pop-up-fönster. Inte i ett nytt fönster i webbläsaren, utan som en sida som läggs "ovanpå" intressefönstret och aktivitetsfönstret och schemafönstret. Bakgrunden blir gråskalig för att man ska förstå att den är "avaktiverad". I pop-up-fönstret (som kan ses i skissen nedanför) får vi plats med mycket mer information, då vi kan utnyttja hela sidan istället för endast en bråkdel av den. Vi kan därmed visa fler recensioner.

En aspekt som vi inte riktigt lyckades enas över var ifall schemat skulle gömmas bakom pop-up-fönstret eller inte. En del av gruppen ansåg att man klickar på aktiviteter för att se information om dem, och inte för att lägga till i schemat (som förresten görs via att man drar i aktiviteten och släpper den i schemat, någonting som vi tyckte skulle vara svårt att implementera för när pop-up:en är uppe). En annan del av gruppen tyckte att schemat var den viktigaste delen av sidan och att den alltid skulle vara synlig så att användaren hela tiden vet vilka tider hon kan passa in aktiviteter i. Vi har inte kommit överrens om detta ännu, men bestämde oss för att designa v2 ur den första gruppens tanke.

Pop-up-sidan skulle se ut någonting likt denna skiss:

Vi kommer säkert att upptäcka fler fel i våra designs, men för nuvarande är vi väldigt nöjda med vår insats!