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.
