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.

Prototyp

Så nu är vi i princip klara med hela projektet och allt som det innebär. De senaste veckorna har vi jobbat hårt på vår interaktiva prototyp som går att hitta här.

Se till att köra webbläsaren Chrome (och det verkar fungera bäst på Windows och Linux). Tack för att ni läst bloggen!

Mvh C4

Diskussion om feedback

Både under presentationen för grupp C5 den 27/2 och under presentationen inför hela klassen den 18/3 fick vi ta emot feedback om vårt projekt. Det här inlägget ämnar att lista och diskutera feedbacken och presentera vår respons.

Presentation inför grupp C5:

• För bred målgrupp
  
  C5 tyckte att vi hade riktat in oss på en för stor målgrupp och att vi borde minska denna för att ha en mer väldefinierad projektidé. Vi hade bestämt att våra målgrupper var Personer som vill planera resa till Stockholm och Personer som är i Stockholm och vill hitta saker att göra. Enligt C5 var detta två ganska skilda grupper och att rikta in sig på båda var lite konstigt. De tyckte att vi antingen borde ta bort en av dem eller omdefiniera dem så att de var mer relaterade till varandra (och därefter kunde produkten ändras så att den passade båda målgrupperna utan att vara oklar).
  
  Ingen av oss i gruppen hade tänkt på detta, så att få kritik på det kändes väldigt bra. Hade C5 inte påpekat problemet så hade vi nog fortsatt utveckla produkten och fått en sämre slutprodukt. Vi insåg att det är väldigt bra att få kritik utifrån, då man själv är åtminstone lite partisk efter att ha jobbat på projektet ett tag.
  
  För att angripa problemet började vi diskutera de olika alternativen. Vi kom fram till att det bästa vi kunde göra vore att ta bort en av målgrupperna. Vi förstod efter kritiken att vi faktiskt hade bestämt en ganska svår målgrupp - den var uppbyggd av två helt orelaterade sorters människor och hade vi behövt designa en tjänst som passade båda skulle den tjänsten bli svårförståelig. Vi bestämde oss för att ta bort Personer som är i Stockholm och vill hitta saker att göra då denna målgrupp både var tråkigare att utveckla en tjänst för och för att det redan finns många tjänster som är anpassade till dem.
  
  På grund av detta var vi även tvungna att göra oss av med en av våra personas, nämligen Freddi Hofmann då han till större delen var en representation av den andra målgruppen. Han skulle inte vara intresserad av vår slutgiltiga produkt, och fick på grund av det råka ut för en liten skidolycka... Den nya personan Alexei Dragunov, kan läsas om här.

• För mycket funktionalitet
  
  (Den här kritiken hör ihop med punkten ovan, men den förtjänar en egen förklaring.)
  
  En annan sak som C5 påpekade var att vi hade för mycket funktionalitet (utility) i vår tjänst. De ansåg att det skulle vara svårt för en ny användare att förstå både hur hon använder tjänsten och vad den egentligen är till för. Vi hade tänkt oss en hemsida med en reseplanerare, en aktivitetslista (med aktiviteter som finns att göra i Stockholm), några små sociala element som chat och forum, en lista över andra användares sparade resor som man skulle kunna åka på själv osv. De tyckte helt att vi hade alldeles för många funktioner och att vi borde korta ner listan för enkelhetens (simplicity) skull.
  
  Precis som i den förra punkten tyckte vi denna kritik var grundad i riktiga anledningar och vi tog emot den positivt. Vi hade kanske varit lite väl kreativa när vi designat projektet och hade inte riktigt förstått att det var minst lika viktigt att ta bort funktioner som det är att lägga till dem. Efter att vi bestämt hur vi skulle lösa kritiken på punkten ovan började vi alltså tänka på vilka funktioner som kunde förenklas eller tas bort helt och hållet.
  
  Eftersom vi redan bestämt att den andra målgruppen skulle tas bort kunde vi enkelt ta bort de funktioner som var designade med den i åtanke. Ett exempel på en sådan funktion var aktivitetslistan. Det var tänkt att den skulle kunna användas när man var i Stockholm och ville hitta information om vad som gick att göra där.
  
  Andra funktioner som vi tog bort var till exempel den sociala aspekten av sidan. Vi insåg både att den nog aldrig skulle användas (det finns redan mycket större sociala nätverk) och att den inte passade resten av produktidén (det finns ingen anledning att ha en social aspekt på en hemsida som endast är en reseplanerare).
  
  Efter att vi tagit bort dessa funktioner hade vi en mycket mer väldefinierad produkt med en lättare målgrupp, högre enkelhet och lagom mycket funktionalitet.

Presentation inför hela C:

• Vi förlitar oss för mycket på företagen
  
  Den här punkten är egentligen inte relaterad till kursen i sig, då den handlar mer om implementation än om design, men den är ändå intressant. Den hjälper till att förklara skillnaderna mellan att endast designa en produktidé och att designa en riktig produkt.
  
  Feebacken gavs av vår övningsledare Björn, som undrade om vi hade tänkt på hur vi skulle få tag på den information som vi tänkte förmedla på hemsidan. Alla de aktiviteter som finns att göra i Stockholm, uppdateringar när någonting ändras (som att en konsert ställs in), restider mellan aktiviteter osv. Hade vi funderat ut vem som skulle ta hand om allt detta och om det ens var möjligt?
  
  Vi hade faktiskt tänkt på det ganska mycket (vi har funderat mycket på implementation överhuvudtaget) och kommit fram till samma problem som Björn fann - det är väldigt mycket information som ska finnas på sidan. Vi hade kommit på flera alternativ som skulle kunna lösa problemet.
  
  Ett alternativ var att vi själva skulle lägga till informationen om aktiviteterna (öppetider, plats, pris osv.), men att "ägarna" av aktiviteten skulle ta hand om att notifiera användare om uppdateringar i deras schema (chefen på Globen uppdaterar informationen när en konsert har ställts in till exempel). Dock uppstod då problemet att vi inte kunde försäkra oss om att informationen var information som vi ville ge ut (Globens chef kanske glömmer bort att informera användarna och då får vi ta smällen när användarna blir arga). Det kanske skulle gå att lösa om vi hade kontrakt med ägaren som sade att de måste ge ut all information för att få finnas på vår hemsida, men då finns det risk att många ägare skulle välja att inte ha sina aktiviteter på vår sida.
  
  Ett annat alternativ var att vi själva (eller arbetare på vårt företag) skulle ta hand om att skicka ut informationen, och ta hand om att lägga till aktiviteter på sidan. Då finns dock fortfarande problemet med att aktiviteternas ägare måste ge oss informationen för att vi ska kunna förmedla den vidare.
  
  Det är där problemet ligger egentligen - och vi har fortfarande inte kommit på ett bra sätt att lösa det på. Det är dock en väldigt intressant fråga som föder ännu en intressant fråga: hur skulle vi ha gått till väga om slutpoängen var en riktig produkt?
  
  Vi tror att vi hade haft en helt annorlunda approach till projektet. Vi hade definitivt försökt lösa logistiken bakom sidan innan vi började planera hur allting skulle se ut. Gå till olika företag och fråga om de är intresserade av att visa sina aktiviteter på sidan för att ta reda på om idén skulle fungera. I den här kursen är ju poängen endast att vi ska lära oss om hur en bra produkt ser ut och känns, men vi har inte lärt oss om hur tekniska produkter fungerar (dvs. kod och sådant).
  
  Resten av feedbacken från presentationen inför hela C var positiv eller bestod av frågor som vi kunde besvara.

Tack vare all feedback har vi lyckats förbättra vår produkt markant. Det blir tydligare och tydligare för varje dag att den här typen av utvecklingsprocess fungerar väldigt bra. Produktidén och produktdesignen vi har nu ser helt annorlunda ut från de som vi hade i början av projektet (och de ser mycket bättre ut också).

Ny målgrupp

Målgruppen vi tidigare hade inriktat oss på var personer som planerade sin resa till Stockholm (i form av Susan) och personer som redan rest till Stockholm men ville hitta saker att göra (i form av Freddi).

Efter vår presentation fick vi kritik på att vår målgrupp var för bred och därför valde vi att smalna av denna, vilket motiveras här.

Vår nya målgrupp är engelsktalande turister som vill planera sin resa med ett eller flera scheman (flera scheman ger utrymme för en "lösare" planerad resa, se nya personas). Den målgrupp vi har tagit bort är icke-engelsktalande personer samt turister som vill hitta aktiviteter utan att spara dessa i ett schema.

Diskussion angående språkfunktion

Efter att vi hade uppdaterat vår produktidé började vi diskutera ifall målgruppen behöver ändras. Våra tidigare målgrupper innefattade icke-engelskspråkiga turister, vilket innebär att det vore nödvändigt med en språkfunktion som tillåter användaren att byta språk på hemsidan.

Ett argument för att vi skulle ha språkfunktionen är att det ger en bättre användarupplevelse (user experience) för icke-engelskspråkiga användare, samt eventuellt för användare som föredrar ett annat språk än engelska. Vi stötte dock på ett problem som vi inte tidigare hade tänkt på, nämligen att de som använder språkfunktionen antagligen även kommer att skriva recensioner på sitt egna språk. Detta leder till att vi får färre recensioner på engelska, och därmed en mindre databas som alla engelskspråkiga kan ta del av.

Eftersom att vi utifrån intervjuerna kom fram till att de flesta turister i Sverige kan tala en del engelska känner vi inte att det är nödvändigt att implementera en språkfunktion. Ifall reseplaneraren vore en riktig produkt så hade vi valt att avvakta medan användarna bygger upp en recension-databas och kanske senare utvecklat hemsidan med en språkfunktion ifall vi skulle anse att det behövs. Därför beslutade vi oss för att avgränsa målgruppen endast till engelskspråkiga turister, och slopa idén av en språkfunktion.

Uppdatering av scenarier

Efter att ha konstruerat vårt nya sekundärpersona måste vi även skapa två nya scenarier tillhörande honom.
Våran förra sekundärpersonas (Freddi Hofmanns) scenarier kan ses här.


För enkelhetens skull inkluderar vi även vårt primärpersonas scenarier i slutet av detta inlägg.

SEKUNDÄRPERSONA: ALEXEI DRAGUNOV

Scenario 1:

Alexei och hans flickvän ska planera en resa till Stockholm på hösten. Flickvännen registrerar sig på hemsidan och använder kontot för att skapa ett schema för resan. Alexei håller dock inte med om vissa aktivitetsval och skapar därför ett nytt alternativt schema. Schemat öppnas i en ny flik vilket gör att han lätt kan jämföra det med flickvännens alternativ och endast ändra på de partier som han inte håller med om. Till exempel är han inte intresserad av gå på spa utan väljer att ersätta den aktiviteten med en konstutställning.
Efter en mycket lyckad resa vill Alexei och hans flickvän gärna rösta på aktivteterna för att kunna hjälpa andra användare att hitta passande aktiviteter. Exempelvis gillade de Skansen och ogillade konstutställningen, så de gav dem ett positivt respektive ett negativt betyg.

Scenario 2:

Alexeis och hans flickvän har gjort slut. För att trösta sig planerar han en till resa till ett varmare klimat. Han väljer Stockholm i december. Han är inte intresserad av att spara sin resa så han skapar resan utan att registrera sig och använder en personlig länk istället, vilken han sparar bland sina bokmärken.
När han börjar planera sitt schema visar reseplaneraren att vissa av hans tänkta aktiviteter är stängda under hans vistelse. Han kan därför byta ut dem mot andra aktiviteter och undviker på så sätt att råka gå på en stängd aktivitet.

PRIMÄRPERSONA: SUSAN MICHAELS

Scenario 1:

Susan har fått semester från jobbet under sommaren och har bestämt sig för att åka till Stockholm, eftersom flygresan är kort och inte så påfrestande för barnen. Hon går in på reseplaneraren och väljer att logga in genom hennes Facebook-konto eftersom det är en enkel process som hon känner igen sedan tidigare. Hon fyller i familjens intressen och får en lista av rekommendationer för aktiviteter.

Hon väljer bland annat att inkludera Gröna Lund en heldag under resan. Dessutom berättar reseplaneraren att Tobbe Trollkarl har en föreställning just den dagen, vilket passar henne väldigt bra, då det låter henne sitta ned ett tag utan att barnen springer iväg.

Scenario 2:

Susan och hennes familj har nu varit i Stockholm i två dagar. I morgon har de planerat att gå på Skansen. Snart får dock Susan reda på att det förväntas regna just då Skansen är planerat. Hon har inte någon större lust att vandra runt i regnet och tror inte att barnen vill det heller, så hon använder reseplaneraren för att rekommendera en alternativ aktivitet som passar in i samma tidslucka. Susan slipper gnälliga barn!

Uppdaterad produktidé

Idag har vi diskuterat vår produktidé och hur vi vill att slutversionen ska se ut. Vi har kommit fram till flera ändringar som ska göras.

Efter presentationen av vårt projekt fick vi kritiken att det riktar sig mot en för stor målgrupp. Vi borde ta bort funktioner som endast används av en liten del av vår målgrupp. Många av de funktioner som vi fick kritik på var funktioner som endast användes av den ena personan. Till exempel fick vi kritik på att produkten fungerade både som en reseplanerare och som en aktivitetssökare och att vi på grund av det hade en för bred målgrupp.

Vi tog emot denna kritik och bestämde oss för att fila ner produkten så att den endast är en reseplanerare. Med en bred målgrupp fick vi för dålig ändamålsenlighet (effectiveness) på tjänsten och genom att ta bort den ena målgruppen så gav vi upp lite funktionalitet (utiliy) för att tjäna mer ändamålsenlighet. Vår designfilosofi har från början varit att produkten ska vara enkel och lättförståelig, så vi anser att ändamålsenligheten är viktigare än funktionaliteten.

Ytterligare en anledning till varför vi valde att endast utveckla en reseplanerare, istället för en aktivitetssökare är att det redan finns bra aktivitetssökare. Till exempel Visit Stockholm, som är en av våra konkurrenter, har en väldigt bra aktivitetssökare, men ingen reseplanerare och vi kan på så sätt urskilja oss från dem.

Vi har gjort flera inlägg med uppdateringar inom projektet. Länkar till dessa finns här under:

1. Uppdaterade personas
2. Uppdaterad funktionslista
3. Uppdaterade scenarier
4. Uppdaterad målgrupp

Uppdaterad funktionslista

Reseplaneraren

1. Förslag på aktiviteter som kan ersätta en inställd aktivitet

Aktiviteter

2. Sortera aktiviteter
3. Förslag på aktiviteter baserat på användarens intressen
4. Söka på aktiviteter
5. Rösta på olika aktiviteter
6. Skriva recension för aktiviteter 
7. Få detaljerad information om vald aktivitet
8. Se recensioner som andra användare har skrivit
9. Reseinformation (implementation/hänvisning till SL-reseplanerare)
10. Platsinformation (karta och adress)
11. Prislista med ungefärliga kostnader

Schema

12. Sätta ihop flera resor samtidigt
13. Visa passande tider för vald aktivitet
14. Spara schemat
15. Redigera schemat
16. Varning för knapp restid
17. Varning för inställd aktivitet
18. Få detaljerad information om vald aktivitet i schemat

Konto

19. Möjlighet att skapa resa utan registrering
20. Personlig länk
21. Skapa ett konto
22. Notifikationer via e-post

Övrigt

23. Hjälpsidor på huvudmenyn
24. Användaren ska alltid kunna komma till reseplaneraren på högst två klick
25. Möjlighet att ställa frågor via ett formulär

Funktion	Primärpersona Susan Michaels	Sekundärpersona Alexei Dragunov
Förslag på aktiviteter som kan ersätta en inställd aktivitet	4	3
Sortera aktiviteter	3	2
Förslag på aktiviteter baserat på användarens valda intressen	5	5
Söka på aktiviteter	3	4
Rösta på olika aktiviteter	1	2
Skriva recension för aktiviteter	1	2
Få detaljerad information om vald aktivitet	5	4
Se recensioner som andra användare har skrivit	4	3
Reseinformation (implementation/hänvisning till SL-reseplanerare)	5	4
Platsinformation (karta och adress)	4	4
Prislista med ungefärliga kostnader	4	3
Sätta ihop flera resor samtidigt	2	3
Visa passande tider för vald aktivitet	5	5
Spara schemat	5	4
Redigera schemat	3	2
Varning för knapp restid	4	2
Varning för inställd aktivitet	4	4
Få detaljerad information om vald aktivitet i schemat	4	3
Möjlighet att skapa resa utan registrering	2	4
Personlig länk	1	5
Skapa ett konto	5	3
Notifikationer via e-post	4	3
Hjälpsidor på huvudmenyn	4	1
Användaren ska alltid kunna komma till reseplaneraren på högst två klick	4	4
Möjlighet att ställa frågor via ett formulär	2	2

1. Förslag på aktiviteter som kan ersätta en inställd aktivitet

Beskrivning

Om användaren har en aktivitet som har blivit inställd får användaren ett förslag på andra aktiviteter som hör till samma intressen som den inställda aktiviteten och passar in på samma tid.

Motivering

Då Susan är bunden av semestertider är det viktigt för henne att hon kan utnyttja semestern optimalt. Då hon har barn är det även nödvändigt för henne att alltid ha någon aktivitet som barnen tycker om och därför är det bra att få en lista med liknande aktiviteter att ersätta den inställda med. Alexei har lite mer frihet att göra vad han känner för i stunden men kan även han vara intresserad av att se vilka alternativ det finns.

Funktionen kommer även att öka effektiviteten (efficiency) hos tjänsten då den ger en utökad möjlighet till planeringen av resan genom att direkt föreslå en ny aktivitet på samma sätt som den annars hade föreslagit en aktivitet genom betydligt fler steg: redigera resan, ange rätt intressen och hitta en aktivitet som passa in på rätt plats i schemat.

2. Sortera aktiviteter

Beskrivning

Möjlighet att i listan på föreslagna aktiviteter sortera efter betyg, pris, namn, relevans och popularitet. 

Motivering

Susan har barn som snabbt kommer att bli otåliga om de inte tycker att aktiviteten är rolig och därför är det en fördel för henne att kunna sortera listan efter betyg och popularitet. Hon kommer även ha en mer pressad budget för resan då hon reser med hela familjen och då kan det vara praktiskt att kunna sortera efter pris.

Alexei har större möjlighet att testa aktiviteter som han inte vet så mycket om och har därför inte lika stor nytta av att sortera efter betyg men kan ha desto mer nytta av att sortera efter relevans.

Denna funktion kommer att öka tjänstens effektivitet (efficiency) då det blir väldigt mycket lättare att hitta aktiviteter som passar användaren när man kan sortera aktiviteterna i den ibland ganska långa listan.

3. Förslag på aktiviteter baserat på användarens valda intressen

Beskrivning

Användaren ska ha möjlighet att ange intressen för att sedan få en genererad lista på aktiviteter som hör till de angivna intressena.

Motivering

Detta är en grundläggande funktion för produkten då det ökar effektiviteten (efficiency) hos tjänsten enormt. Då vi kan räkna med att ha ganska många aktiviteter i vår databas så är det inte rimligt att behöva söka igenom alla dessa för att hitta passande aktiviteter. Att istället kunna ange intressen för att filtrera aktiviteterna gör att man slipper söka igenom aktiviteter som hör till intressen som man inte passar in på.

4. Söka på aktiviteter

Beskrivning

Man ska i listan på aktiviteter kunna söka på en viss aktivitet. Man söker då endast bland de aktiviteter som genererats av de intressen man angivit. Om man inte har markerat några så räknas det som att man har markerat alla. 

Motivering

Chansen är ganska stor att man har fått tips om aktiviteter från olika håll och då kan det vara praktiskt att inte behöva gissa sig till vilka intressen den aktiviteten är länkade till utan istället kan söka på namnet i listan med alla aktiviteter. Alexei kommer nog ha störra nytta av detta då det är större chans att han letar efter aktiviteter som inte har höga betyg och därför kommer högt upp i listan ändå. 

5. Rösta på olika aktiviteter

Beskrivning

Man ska som registrerad användare ha möjligheten att kunna rösta på aktiviteter med ett "Bra" eller "Dåligt" system. Man kan bara ge en röst på varje aktivitet men man kan ändra rösten i efterhand. Under resans gång har man på schemasidan möjligheten att rösta på aktiviteter som har passerat och efter resan får man ett e-mail där man uppmuntras att rösta på de aktiviteter som man hade i sitt schema men som man ännu inte har röstat på. E-mailet innehåller då en länk till schemasidan där man nu kan rösta på alla aktiviteter.

Motivering

Denna funktion har mest ett passivt syfte då den ger möjlighet till sortering efter betyg och popularitet. Genom att göra processen för att rösta så enkel som möjligt så hoppas vi få ihop tillräckligt många röster för att kunna använda dessa till sortering. Då Alexei är en webbdesigner och därför antagligen har god erfarenhet av webben så är det mer troligt att han går in på aktiviteter i efterhand och röstar på dem. 

6. Skriva recension för aktiviteter

Beskrivning

Som registrerad användare ska man kunna skriva en recension per aktivitet. Man kan även här ändra sin recension i efterhand. Man ska även ha möjlighet att anmäla andras recensioner. I e-mailet man får efter avslutad resa (se funktion 5) kommer man att uppmuntras till att skriva en recension utöver att rösta på aktiviteter.

Motivering

Även detta kommer huvudsakligen att vara en passiv funktion då den kommer att nyttja de som planerar en resa mer än de som har avslutat en resa (se funktion 8). Av samma anledning som för funktion 5 så tror vi att det är mer troligt att den webb-vane Alexei skriver en recension i efterhand. Genom länken man får i e-mailet hoppas vi att det ska vara tillräckligt enkelt att skriva en kort recension.

7. Få detaljerad information om vald aktivitet

Beskrivning

Om man som användare hittar en aktivitet i listan över aktiviteter som passar angivna intressen och tycker att den aktiviteten ser intressant ut så ska man ha möjligheten att klicka på "Show more" för att få upp en pop-up-ruta med information om aktiviteten. Denna ruta ska innehålla öppettider, priser, recensioner och aktivitetens egna information. Man ska även kunna gå till nästa aktivitet i listan direkt via denna pop-up-ruta. 

Motivering

Genom att visa flera aktiviteter i listan på samma gång och även visa den viktigaste informationen direkt i listan så kan användare på ett enkelt sätt göra en grov bedömning över vilka aktiviteter som passar. Att sedan använda en pop-up-ruta för att visa informationen gör att man slipper lämna sidan och genom att visa sidan lite nedtonad bakom pop-up-rutan så vet användaren att man är kvar på samma sida och inte tappar någon information. Alla länkar i informationsrutan kommer även att öppnas i ett nytt fönster så att man slipper lämna sidan för att hitta mer information. 

Att hela tiden få vara kvar på samma sida ger bättre effektivitet (efficiency) för tjänsten då användaren hela tiden snabbt kan komma tillbaka till planeringen. 

8. Se recensioner som andra användare har skrivit

Beskrivning

Man ska i pop-up-rutan för en aktivitet kunna se recensioner som andra användare har skrivit. Man ska även ha möjligheten att anmäla andras recensioner ifall de är stötande, opassande eller inte handlar om aktiviteten. 

Motivering

För Susan är det väldigt användbart att kunna se vad andra användare har skrivit om en aktivitet för att kunna avgöra hur passande aktiviteten är för hennes barn. Funktionen ökar tjänstens ändamålsenlighet (effectiveness) då den hjälper till att göra resan mer lyckad genom att öka chansen att användaren väljer rätt aktiviteter. Som nämnt tidigare så kommer Alexei att vara mer benägen att testa aktiviteter efter egen vilja istälelt för att välja efter andra användares åsikter. 

9. Reseinformation

Beskrivning

Denna funktion avser att förse användaren med reseinformation till en vald aktivitet exempelvis med information om befintliga färdmedel till aktiviteten eller med en länk-hänvisning till Stockholm Lokaltrafiks reseplanerare.

Motivering

Vi valde att ha med reseinformation därför att funktionen är väldigt viktig både för Susan och Alexei då bägge personas är turister från utlandet och är inte vana vid transportmedel i Sverige. Att få reseinformation är ännu viktigare just för vår primärpersona Susan eftersom hon ansvarar för sina barn och vill se till att resan går bra.

10. Platsinformation

Beskrivning

Med platsinformation får användaren reda på aktivitetens adress samt se dess position på en karta.

Motivering

Liksom för reseinformation är denna funktion ämnad att informera användaren om hur man tar sig till aktiviteten. Detta är essentiellt för att användaren ska kunna planera sin resa och bidrar därför stort till produktens effektivitet (effectiveness).

11. Prislista med ungefärliga kostnader

Beskrivning

En prislista ger användaren möjlighet att göra en grov uppskattning av aktiviteternas kostnader. Detta kan framförallt vara viktigt ifall man har en striktare budget, eller om man vill unna sig något exklusivt.

Motivering

För våra personas är denna funktion viktig i olika utsträckningar. Susan är mer intresserad av prislistan eftersom hon är mer bunden till sin budget då hon måste ha sin familj i åtanke. Alexei lever däremot ungkarlslivet och kan tänka sig att betala lite extra för en bättre upplevelse.

12. Sätta ihop flera resor samtidigt

Beskrivning

Den här funktionen är en praktisk lösning ifall användaren skulle vilja sätta ihop flera scheman. Ett exempel på en sådan situattion är scenario 1 för Alexei. Vår produkt erbjuder flikar för att användaren ska kunna navigera mellan de aktuella scheman.

Motivering

Just denna funktion används inte så mycket av varken Susan eller Alexei, men vi valde att implementera den för att funktionen utbreder användarmöjligheterna (utility) utan att utgöra ett hinder för användarupplevelsen (user experience).

13. Visa passande tider i schemat för vald aktivitet

Beskrivning

Informerar användaren om var i schemat en vald aktivitet passar genom att passande tidsluckor markeras ut. Användaren kan sedan välja att flytta aktiviteten till de möjliga tidsintervallen.

Motivering

Detta är en nyckelfunktion för vårt interaktiva schema och bidrar till produktens ändamålsenlighet (effectiveness). De utmarkerade tidsintervallen ger även en signalering (affordance) till hur man använder funktionen.

14. Spara schemat

Beskrivning

Registrerade användare har möjligheten att spara sina scheman och kunna återgå till dem.

Motivering

Detta är en given funktion som är väldigt effektiv (efficient) för användaren då denne inte behöver skapa ett nytt schema vid varje nytt besök av reseplaneraren.

15. Redigera schemat i efterhand

Beskrivning

Efter att en registrerad användare har sparat sin resa kan han/hon i efterhand gå tillbaka och utföra ändringar i schemat.

Motivering

Susan har fler medresenärer än Alexei och är därför i större behov av att kunna redigera schemat i efterhand med tanke på att det blir flera som bestämmer hur resan ska fortskrida.

16. Varning för knapp restid

Beskrivning

Denna funktion är mycket lik funktionen "Varning för inställd aktivitet". Skillnaden är att denna funktion varnar för när användaren har placerat två aktiviteter för nära varandra. Till exempel kanske Susan väljer att lägga "Gröna Lund" endast tio minuter efter "Teknikmuséet". Funktionen kan med en approximerad restid (ganska oprecis, men tillräcklig) märka av att Susan inte kommer hinna ta sig emellan dessa två aktiviteter på endast 10 minuter. Då varnas Susan precis som i funktionen "Varning för inställd aktivitet".

Motivering

Vi kan inte räkna med att varje användare vet exakt hur Stockholm ser ut, och det är därför ganska självklart att det kommer hända att hon placerar två aktiviteter för nära varandra. Vi måste kunna känna av detta så att hon inte blir missnöjd när hon inser att hon inte kommer kunna hinna till nästa aktivitet.

Susan är mer intresserad av denna funktion, då hon är den personan som planerar mest utförligt. Hon vill veta när hennes planer ändras, så att hon kan forma om dem. Hennes barn påverkar hennes resande väldigt mycket, och eftersom de börjar gnälla när någonting inte fungerar så är hon väldigt medveten om att allting måste funka.

Alexei är mindre intresserad då han är mycket mer oberoende av andra när han reser. Han vill såklart inte missa aktiviteter för att han inte hann resa emellan dem, men han har samtidigt inte jättemycket emot att testa något annat ifall det händer.

17. Varning för inställd aktivitet

Beskrivning

När en aktivitet som en användare har planerat att gå på till exempel ställs in, visas denna information i schemat genom att aktiviteten i fråga lyser upp i en annan färg än den vanliga. Till exempel: Alexei har planerat att gå på en Metallica-konsert på en lördag. När han kollar på sitt sparade schema dagen innan så ser han att "Saturday" har en röd cirkel med ett utropstecken i under texten. Han klickar på denna ikon och får upp en liten ruta där det står någonting i stil med:

"The activity 'Metallica Consert' has been cancelled."

Användaren kan sedan välja mellan att byta ut aktiviteten mot någonting annat som passar in i samma tidslucka, eller så kan han ignorera varningen (varefter den försvinner för att det inte ska vara irriterande) och låta aktiviteten ligga kvar i schemat.

Motivering

Det är viktigt att användaren kan se om en aktivitet inte passar in i schemat längre, så att hon kan få chans att ändra på sina planer så att de stämmer överrens med schemat. Samtidigt är det viktigt att vi inte tvingar användaren att ändra på sina planer bara för att vi tycker aktiviteten inte passar in. Denna funktion är en bra kompromiss, då vi förmedlar informationen och tipsar på vad användaren kan göra istället, utan att tvinga användaren att ändra på sina planer. Det är till exempel möjligt att vårt system har gjort ett misstag, och tvingar vi då användaren att ta bort aktiviteten från sitt schema så gör vi ett stort fel. Detta kommer få användaren att inte vilja använda vår tjänst längre.

Både Susan och Alexei vill veta om en aktivitet som de planerat att gå på ställts in. Susan planerar väldigt utförligt och vill inte att hennes planer ska förstöras, eftersom hennes barn blir gnälliga då. Alexei vill ha denna information eftersom han tycker det är onödigt att åka till en aktivitet om det visar sig att den är inställd. Han vill ha möjligheten att snabbt göra en ändring eller åtminstone få informationen så att han kan strunta i aktiviteten.

18. Få detaljerad information om vald aktivitet i schemat

Beskrivning

När man planerar sin resa eller efter att man har sparat sin resa så har man tillgång till sitt schema. I schemat ligger de aktiviteter som man har valt. Klickar man på "show more"-knappen på en aktivitet öppnas en pop-up med information om aktiviteten. (Mer information om detta under funktionen "Få detaljerad information om aktivitet").

Motivering

Då en viss aktivitet kan ha väldigt mycket information kopplat till sig (kart-info, rese-info, pris, betyg, generell information, hemsida osv.) finns det ingen chans för all denna information att visas i aktivitetslistan, utan detta måste läggas någon annanstans. Det är dock viktigt att man alltid kan komma åt denna information, även efter att man sparat sin resa (och där med har gömt aktivitetsfönstret). Därför finns "Show more"-knappen även i schemat. 

Eftersom Susan är den persona som är mest intresserad av aktivitetsinformation, då hon planerar mycket mer utförligt än Alexei, är denna funktion till större delen designad med henne i åtanke. Hon vill gärna veta var en aktivitet ligger redan innan hon ska gå på den, eller få reda på priset långt i förväg så hon kan planera efter sin budget.

19. Möjlighet att skapa resa utan registrering

Beskrivning

När man för första gången använder tjänsten så får man välja mellan tre val av registreringstyp. Ett av alternativen är att inte registrera sig alls. Då tappar man några fördelar som man får om man registrerar sig. (Mer information om detta under funktionen "Skapa ett konto").

Motivering

I överensstämmelse med vår designfilosofi så ska det vara enkelt att använda vår produkt. Många användare är ovilliga att skapa profiler på hemsidor, då de är oroliga att deras information ska säljas vidare (eller så tycker de bara att processen är jobbig). Vi vill stödja dessa användare, eftersom vi förstår deras tankesätt. Det viktigaste med vår produkt är själva reseplaneringen, inte registreringsmöjligheterna.

Alexei är den persona som är mest benägen att använda sig av denna funktion, då han är mer insatt i datorvärlden och vet hur registrering fungerar. Han är mer oberoende i sin planering och behöver därför inte få all information om sin resa (han väljer att ta den lätta registreringsprocessen trots att informationen är sämre efteråt). 

Susan vill registrera sig, då det är en process som hon är van vid. Hon förstår inte konceptet av "personlig länk" osv.

20. Personlig länk

Beskrivning

Om en användare väljer att inte registrera ett konto på sidan så finns det inget sätt för henne att se sina sparade resor (eftersom de ligger sparade i profilen). Då kan hon istället få en personlig länk till sitt schema. Denna länk tar användaren direkt till hennes resa så att hon fortfarande kan se den och vad hon har planerat att göra. Dock syns inte ändringar som när aktiviteter ställs in.

Motivering

Susan är helt ointresserad av denna funktion. Hon vill ha all information relaterad till resan, så att hon kan göra ändringar i sina planer om någonting händer.

Alexei tycker dock om funktionen, eftersom han är mindre benägen att skapa ett konto. Han ogillar att registrera sin epost på en massa hemsidor, då han är medveten om att vissa hemsidor säljer informationen han anger (det gör inte vi!). Han tycker det är alldeles tillräckligt med information att veta vad han har planerat och var aktiviteterna ligger.

21. Skapa ett konto

Beskrivning

När en användare för första gången kommer till hemsidan och klickar på "Create Trip" får hon upp en ruta med information om inloggning. Det finns tre olika val:

1: Skapa en profil på hemsidan genom att ange epostadress och ett lösenord.

2: Logga in via OpenID/Facebook och slippa bekräftningsemail.

3: Gå direkt till reseplaneraren utan att logga in.

De tre olika valen har olika fördelar och nackdelar. Fördelarna med att skapa ett konto (val 1&2) är att man kan rösta och skriva recensioner på aktiviteter, redigera sin resa efter att man har sparat den, spara fler resor under samma profil och möjligheten att få epostnotifikationer om ändringar i sparade resor. Om man inte skapar en profil kan man endast spara en resa (och man kan inte redigera den efteråt, men det är mycket smidigare första gången då man slipper registreringsprocessen.

Motivering

Susan är den persona som kommer ha störst användning av denna funktion, då hon är mest benägen att skapa ett konto - det är en process som hon är van vid och hon ogillar att göra obekanta saker på sin dator. Dessutom är hon mer intresserad av alla "perks" som registrering erbjuder. Hon vill kunna spara sin resa och kunna redigera den om hennes barn till exempel säger att de inte vill gå på en viss aktivitet.

Alexei har viss användning av registrering, då han är mer benägen att skapa flera resor samtidigt än Susan när han reser med sina kompisar/flickvän (de är mer oberoende av varandra och kan tänka sig gå på olika aktiviteter). Han gillar dock att kunna slippa inloggningsprocessen då det är någonting han gått igenom så många gånger förut i sitt datoranvändande.

22. Notifikationer via e-post

Beskrivning

Om en användare har skapat ett konto på hemsidan (antingen via registrering eller inloggning via OpenID/Facebook) och hon har sparat sin planerade resa så kan hon välja att få notifikationer om en aktivitet ändras/ställs in osv (man kan även välja att slippa dessa notifikationer). På det här sättet förmedlas mer information om den planerade resan, vilket är viktigt. Produktens ändamålsenlighet (*effectiveness*) förhöjs, eftersom denna information kommer leda till att användaren på ett bättre sätt kan utforma sin resa.

Motivering

Susan kommer vara den personan som använder sig av funktionen mest, eftersom hon är den som planerar mest utförligt. Hon reser med sina barn och vill därför veta när någonting i resan ändras (som sett i ett av hennes scenarier). Alexei är mer oberoende när han reser och han har ingenting emot att hans planer ändras, utan han kan lika gärna lägga till en annan aktivitet istället.

Alexei är dessutom mindre benägen att skapa en profil på hemsidan, och eftersom det är ett krav för denna funktion så leder det till att han är mindre intresserad av den.

23. Hjälpsidor på huvudmenyn

Beskrivning

Huvudmenyn (menyn som är konsekvent och hela tiden ligger längst upp på sidan, oavsett var användaren befinner sig) har två stycken knappar som är menade att hjälpa användaren med att använda produkten. Första knappen är "Help". Help-knappen tar användaren till en guide med bilder och text som förklarar hur reseplaneraren fungerar. Den andra knappen är "F.A.Q" (Frequently Asked Questions) och där kan användaren få svar på vanliga frågor som inte täcks av guiden. Användaren kan även ställa frågor i vårt frågeformulär på denna sida.

Motivering

Båda knappar hjälper användaren att använda tjänsten, utan att vara störande eller inkräktande. Det är väldigt vanligt att hemsidor använder sig av dessa sorters knappar för att förmedla information som inte alla vill ta emot.

Susan är den som är mest intresserad av denna funktion, eftersom hon är mindre datorkunnig och vill ha mer hjälp. Hon kanske inte är säker på hur man använder produkten första gången så då hjälper "Help"-knappen henne, eller så har hon någon fråga utöver guiden som är besvarad i "F.A.Q". Alexei är ointresserad av funktionen eftersom han är mycket mer datorvan och oftast förstår hur en datortjänst fungerar första gången han använder den.

24. Användaren ska alltid kunna komma till reseplaneraren på högst två klick

Beskrivning

Oavsett var användaren befinner sig på hemsidan ska det alltid gå att komma till reseplaneraren på två klick. Exempelvis om användaren håller på att läsa om hur tjänsten fungerar så kan hon klicka på "Create Trip" och sedan välja att inte skapa en profil. Ofta går det att komma till reseplaneraren på ett klick, om man till exempel redan är inloggad, men det ska aldrig vara mer än två klick bort.

Motivering

Vi vill att vår design ska vara väldigt simpel och enkel att använda och denna funktion är något som vi sett i många andra tjänster som till exempel Amazon. Vi vill att användarna ska känna att de inte slösar tid när de använder vår tjänst. Denna funktion höjer produktens effektivitet (*efficiency*), eftersom användaren kan ta sig runt och på så sätt använda vår tjänst mer effektivt.

Både Susan och Alexei är intresserade av denna funktion, eftersom de är mänskliga och ogillar när saker tar onödigt lång tid. Susan har användning av funktionen då hon inte är jätteduktig på datorer och vill att det ska vara enkelt. Alexei har användning av den då han är väldigt duktig på datorer och tycker att det är en dålig hemsida om den är svår att använda.

25. Möjlighet att ställa frågor via ett formulär

Beskrivning

Om användaren har problem med att förstå en viss funktion på hemsidan och hon inte tycker att hjälpsidan förklarar tillräckligt väl eller om hon vill veta någonting annat angående tjänsten så kan hon kontakta oss och ställa sin fråga. Detta görs enkelt genom ett formulär. 

Motivering

Denna funktion är väldigt vanlig på hemsidor. De flesta har en någon sorts kundservice/FAQ. Vi vill förenkla processen eftersom vår filosofi är att tjänsten ska vara väldigt enkel. 

Både Susan och Alexei kan behöva tjänsten men de är inte totalt beroende av den (det finns mycket hälp på andra sidor). Susan vill kanske fråga om en viss aktivitet (finns en viss aktivitet) medan Alexei kanske vill lära sig att använda tjänsten mer effektivt (genom t.ex. kortkommandon). 

Uppdatering av personas

Till följd av de ändringar som vi har gjort för produktidén har vi kommit fram till att vi måste ersätta ett av våra persona, Freddi Hofmann, med ett mer passande.

Freddi i sin nuvarande inkarnation passar inte in i vår tänkta målgrupp, turister som planerar en resa till Stockholm. Han är mer spontan och eftersom att vår produkt är en reseplanerare så känns det som att han i princip inte skulle använda tjänsten, åtminstone inte på ett sådant sätt att vi kan utforma produkten utifrån honom.

Vi baserar det nya personat på Freddi men vi har åtgärdat de brister han har som persona.

NYTT SEKUNDÄRPERSONA:
Namn: Alexei Dragunov
Kön: Man
Hemland: Ryssland
Ålder: 30
Sysselsättning: Egenföretagare (Webbdesign)
Resekamrater: Ensam eller med flickvän
Reseintressen: Museum, konstutställningar, paraktiviteter
Datorvana: God
Datortyp: Stationär, laptop och smartphone
Intressen: Historia

Motivering: Alexei har mycket tid att resa eftersom att han är egenföretagare. Det innebär att han kan resa under lågsäsong vilket inte är fallet för det andra personat Susan Michaels. Han reser ofta tillsammans med sin flickvän och måste därför kunna planera flera resor samtidigt.
Efter våra intervjuer märkte vi att vissa turister kommer till Sverige även under vinterhalvåret och att det var svårt att få tag på information om aktiviteter under den perioden. Eftersom att Alexei ibland reser på vintern representerar han den delen av vår målgrupp väl. Dessutom intervjuade vi par som reser hit tillsammans precis som Alexei och hans flickvän.

Vi har även gjort vissa förändringar gällande vårt andra persona. Först och främst har vi bestämt att detta ska vara vårt primärpersona då vi anser att hon representerar den största delen av vår målgrupp.
Utöver det har vi även uppdaterat vår motivering för personat.

UPPDATERAT PRIMÄRPERSONA (TIDIGARE PERSONA 2):
Namn: Susan Michaels
Kön: Kvinna
Hemland: England
Ålder: 42
Sysselsättning: Jobb (kontorsjobb)
Resekamrater: 2 barn (5, 12 år), make
Reseintressen: Saker som passar barnen, äta på restaurang, ta det lugnt
Datorvana: Medel, använder för specifika uppgifter på jobbet
Datortyp: Laptop
Intressen: Familjen, väninnor

Motivering: En stor del av turister är barnfamiljer. Persona 2 är bunden av jobbet och har schemalagd semester som hon vill utnyttja. Här handlar det inte om att göra så mycket som möjligt under så kort tid som möjligt, utan snarare om att man bara vill komma bort från det dagliga livet ett tag. Persona 2 har ett större behov av planering, då det är svårt att göra impulsbeslut om man måste tänka på barnen hela tiden. Enligt Eurostat är de flesta turisterna inom EU mellan 25 och 44 år gamla med 45-64 tätt därpå och Susans ålder är därför ett bra mellanting.

Länk till uppdaterade scenarier här.

Första presentation

Imorgon är det tänkt att vår grupp ska framföra en presentation inför en annan projektgrupp. Presentationen ska bland annat handla om de grundläggande idéerna vi har, de intervjuer vi genomförde - som i sin tur gav upphov till en målgrupp, personas och designer.

Nedan har vi de huvudpunkter som presentationen består av. Vi diskuterade gemensamt vilken information som var allra viktigast att framföra och kom fram till denna struktur:


IDÉ

Vår idé är en webbaserad applikation som tillåter användare att skräddarsy en turistvistelse i Stockholm. Användarna kan planera sina resor och få rekommendationer för olika aktiviteter som passar deras intressen och personligheter.


INTERVJUER

Vi ville veta hur turister hade planerat sina resor till Stockholm och vilka problem de hade stött på då. Vi genomförde flera intervjuer och kom då fram till att det fanns flera problem:

• Det var svårt att veta var man som turist skulle börja med planeringen.
• Informationen kring aktiviteterna, t.ex. öppettiderna, var dålig och helt enkelt otillräcklig.

MÅLGRUPP

Med hjälp av intervjuerna bekräftade vi vår idé och kunde därefter definiera vår målgrupp. Målgruppen är blivande turister som avser att turista i Stockholm, och vill kunna planera sina resor dit i förväg på ett smidigt sätt.


PERSONAS

Målgruppen gav upphov till två personas med olika bakgrunder. Dessa två personas heter Freddi Hofmann och Susan Michaels. Båda personas har sina personliga egenskaper:

• Susan är en 42-årig kontorsarbetare från England. Hon är mamma till två yngre barn. Hon är dessutom huvudpersonan i vårt projekt. Susan vill komma bort från det vardagliga England och beslutar sig för att besöka Stockholm tillsammans med familjen. Hon är i stort behov av att kunna planera sin resa ordentligt i förväg. Stockholmsresan ska vara kul för både barnen och föräldrarna. Därför måste olika typer av aktiviteter kunna finnas tillgängliga.
• Freddi är en 23-årig konststudent från Tyskland som vill ta en paus from studierna och åka till Stockholm på en konstresa som involverar museibesök och utställningar. Han föredrar tidseffektiva alternativ och lägger inte särskilt mycket tid på sina reseplaner.

DESIGN

Det viktiga med vår design är själva sidportalen, där användarna planerar sina resor. Applikationen ska vara enkel, stilren och bidra med en tidseffektiv reseplanerare. Vi kommer att utgå från våra designprototyper för att enklast kunna framföra våra designidéer till den andra projektgruppen.

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!

Designdiskussion

Ikväll hamnade vi i en diskussion om hur en del funktioner som vi kommer inkludera i vår tjänst skulle kunna se ut. Vi diskuterade framförallt hur användaren skulle kunna utvärdera varje aktivitet efter resan, och vad användaren skulle kunna ange i en sådan recension. Man skulle kunna sammanfatta de alternativ vi kom fram till i följande punkter:

• Användaren ger ett betyg och en recension
• Användaren kan ge flera betyg för hur olika intressen passade aktiviteten
• Användaren ger bara ett betyg på aktiviteten
• Användaren ger ett betyg och föreslår intressen som passar aktiviteten
• Användaren kryssar i de intressen (som fördes in i profilen innan resan) som användaren tycker passar aktiviteten

Följande begränsningar diskuterades också:

• Man kan bara ge en recension per konto
• Man kan bara ge en recension per resa

Det handlade också en del om vad som ska finnas i en utvärdering kontra vad som kan kopplas till profilen för att ge framtida användare en bättre sökning, där kraften mot att sätta saker i en utvärdering blev att det inte ska vara för jobbigt för användaren att utvärdera aktiviteterna då det är frivilligt. Vi vill att folk ska vilja fylla i utvärderingar av aktiviteterna för att förbättra sökningen för framtida användare.

Funktionstabell

I detta inlägg finns produktens olika funktioner numrerade efter hur pass relevanta de är för våra olika personas. Se tidigare inlägg för våra personas definitioner.

Relevansen graderas från 1 till 5, enligt dessa kriterier:

Gradering	Innebörd
1	Helt irrelevant för personat i fråga
2	Funktionen påverkar användarupplevelsen positivt, men i mycket liten utsträckning
3	Funktionen uppskattas och förbättrar användarupplevelsen
4	Viktig funktion vars avsaknad skulle påverka användarupplevelsen negativt
5	Grundläggande funktion som krävs av personat i fråga

Nedan följer tabellen över funktioner och deras graderingar.

Funktion	Persona 1 Freddi Hofmann	Persona 2 Susan Michaels
Personlig länk	4	1
Notifikationer via e-post	3	4
Skapa ett konto	1	2
Logga in via OpenID/Facebook/etc.	1	4
Möjlighet att redigera schemat	4	5
Förslag på aktiviteter baserat på användarröster	3	4
Möjlighet att rösta på olika aktiviteter	4	1
Sätta ihop en resa själv	4	5
Välja en resa som någon annan har delat med sig av	1	3
Slumpa fram en resa baserat på rekommendationer	3	1
Slumpa fram en resa utan att ta hänsyn till rekommendationer	2	1
Möjlighet att enkelt få förslag på aktiviteter som kan ersätta en inställd aktivitet	3	4

Beskrivning av funktioner

Under diskussionen om scenarion dök det upp en del idéer om olika designlösningar.

Vad gäller att spara sin planerade resa kom vi på följande alternativ:

• En privat länk till sidan
• Ett e-postmeddelande 
• Genom registrering med e-post + lösenord eller facebook

Oavsett vilket alternativ användaren väljer kommer det vara möjligt att ändra på resplanen senare.

Om en planerad aktivitet av någon anledning inte längre skulle vara tillgänglig så skulle en
notifikation om det gå ut till användaren med förslag på andra aktiviteter, baserade på
personens angivna profil och vad andra som har varit intresserade av den inställda aktiviteten
har gjort.

Ett system för att rösta upp eller ner aktiviteter efter resan. Om man har registrerat sig så får man
ett meddelande efter resan där man får möjligheten att göra en utvärdering av sakerna man har gjort på sidan.
Ett system med stjärnor och alternativt kommentarer på aktiviteter används då för att utvärdera.

Det kommer att finnas olika alternativ för hur man kan sätta ihop sin resa, där man får förslag till aktiviteter om man har fyllt i en profil:

• Sätta ihop sin egen resa på egen hand
• Välja en färdig resa som någon annan har satt ihop
• Slumpa en resa baserat på andra användares rekommendationer
• Slumpa en resa utan hänsyn till rekommendationer

Scenarios

Idag har vi skapat två scenarios för båda våra personas.

Persona 1: Freddi Hofmann

Scenario 1:

Freddi har tillsammans med en kompis bestämt sig för att spendera sitt jullov i Stockholm. Han går in på reseplaneraren och väljer att inte skapa en profil, utan han fyller i sina intressen, datum och sin budget direkt. Därefter får han en lista av rekommendationer som passar intressena. Han är speciellt intresserad av en aktivitet - Nationalmuseum, och bestämmer sig för att boka in aktiviteten den 28 december. Reseplaneraren berättar att Nationalmuseum är stängd för renovation den dagen, men att det öppnar igen den 4 januari. Freddi bokar in Nationalmuseum då istället och väljer att boka in en konstutställning som reseplaneraren rekommenderade för den 28 december. 

Utan att behöva skapa en användare får Freddi nu en personlig länk till sin resa, som han kan använda till en vecka efter resans slut. Han väljer att ange sin mail-adress för att få notifikationer om ändringar i de olika aktiviteterna. Freddi är nöjd!

Scenario 2:

Freddi har varit i Stockholm i elva dagar och är hittills väldigt nöjd med sin resa. Idag gick han på en aktivitet som han i efterhand tyckte var tråkig och inte passande i relation till hans intressen. Han går in på reseplaneraren och skapar en profil genom att skriva in sin mail och ett lösenord. Därefter kan han ge ett betyg på aktiviteten. Han ger ett dåligt betyg, och tack vare det förstår reseplaneraren att aktiviteten kanske inte passar användare med samma intressen som Freddi. Tack Freddi!

Persona 2: Susan Michaels

Scenario 1:

Susan har fått semester från jobbet under sommaren och har bestämt sig för att åka till Stockholm, eftersom flygresan är kort och inte så påfrestande för barnen. Hon går in på reseplaneraren och väljer att logga in genom hennes Facebook-konto eftersom det är en enkel process som hon känner igen sedan tidigare. Hon fyller i familjens intressen och får en lista av rekommendationer för aktiviteter.

Hon väljer bland annat att inkludera Gröna Lund en heldag under resan. Dessutom berättar reseplaneraren att Tobbe Trollkarl har en föreställning just den dagen, vilket passar henne väldigt bra, då det låter henne sitta ned ett tag utan att barnen springer iväg.

Scenario 2:

Susan och hennes familj har nu varit i Stockholm i två dagar. I morgon har de planerat att gå på Skansen. Snart får dock Susan reda på att det förväntas regna just då Skansen är planerat. Hon har inte någon större lust att vandra runt i regnet och tror inte att barnen vill det heller, så hon använder reseplaneraren för att rekommendera en alternativ aktivitet som passar in i samma tidslucka. Susan slipper gnälliga barn!

Think aloud

Vi har nu fastställt målgruppen och produktidén för vårt arbete. För att få en större uppfattning om vad som är viktigt att tänka på när vi ska skapa vår produkt utförde vi en så kallad "think aloud"-utvärdering. Detta gjordes genom att vi observerade när andra använde den konkurrerande webbplatsen http://www.visitstockholm.com/ och vi noterade vad som gick bra och dåligt vid användningen.

Exempelvis gav Marwan sin mamma May i uppgift att hitta en skridskobana i Stockholm genom att använda webbplatsen. May är inte van med att använda datorer och uppskattade därför att designen gjorde det relativt enkelt att använda hemsidan och att den information som hon sökte efter gick lätt att hitta.

Från webbplatsen som vi undersökte fann vi en del smarta funktioner som vi kan använda i vår produkt, och utifrån resultaten från utvärderingen lärde vi oss att det för ovana datoranvändare framförallt är viktigt att webbplatsen har en enkel design. Vi får senare fundera vidare på vad en enkel design är och hur man utformar det.

Personas

Under övning #2 började vi arbeta på några personas:

Persona 1 (Student):

Namn: Freddi Hofmann

Kön: Man

Hemland: Tyskland

Ålder:23

Sysselsättning: Konststudent

Familj: Bor själv, reser med kompisar

Reseintressen: Fester, museum, konstutställningar

Datorvana: Stor, använder dator både i studie- och fritidslivet.

Datortyp: Laptop, smartphone

Intressen: Studentliv

Motivering: många av de som turistar är unga studenter som antingen vill lära sig mer eller vill ta en paus i studierna. Persona 1 vill ha en bra miljö för att kolla öppetider på diverse barer, museum, utställningar osv. Han är inte intresserad av att planera i förväg, utan tar saker som de kommer.

Persona 2 (Mamma):

Namn: Susan Michaels

Kön: Kvinna

Hemland: England

Ålder: 42

Sysselsättning: Jobb (kontorsjobb)

Familj: 2 barn (5, 12 år), make

Reseintressen: Saker som passar barnen, äta på restaurang, ta det lugnt

Datorvana: Medel, använder för specifika uppgifter på jobbet

Datortyp: Laptop

Intressen: Familjen, väninnor

Motivering: en annan stor grupp av turister är barnfamiljer. Persona 2 är bunden av jobbet och har schemalagd semester som hon vill utnyttja. Här handlar det inte om att göra så mycket som möjligt under så kort tid som möjligt, utan snarare om att man bara vill komma bort från det dagliga livet ett tag. Persona 2 har ett större behov av planering, då det är svårt att göra impulsbeslut om man måste tänka på barnen hela tiden.

Vi kommer säkert att uppdatera dessa personas och eventuellt skapa fler om vi märker att det behövs eller får mer data som visar att de är felaktiga. Vi har dessutom inte bestämt en huvudpersona eller skapat några scenarios ännu, så det är nästa steg.

Övning #2 - 13/2-2013

På dagens övning fick vi huvudsakligen lära oss om två saker: personas och scenarios.

Personas är användarbeskrivningar som man baserar på datan insamlad via fältstudier och intervjuer. Vi ska använda dem för att motivera funktioner i vår produkt och för att skapa scenarios.

Scenarios är helt enkelt specifika situationer där vi kan förklara hur en funktion fungerar, och varför den behövs.

Uppgiften inför nästa övning var att skapa två personas och några scenarios som vi sedan kan använda för att designa vår produkt.

Vi började designa ett par personas utifrån vad vi redan vet om användarna - se inlägg: "Personas"

Sammanfattning av intervjuer

För att intervjua människor som har flyttat hit av en eller annan anledning fick vi gå till egna kontakter, då dessa människor är svåra att urskilja på stan. Vi intervjuade alltså dessa huvudsakligen via e-post. Exempelvis intervjuade Isak en av sina gamla engelsklärare som flyttade hit för fem år sen, Alan intervjuade en granne från Italien och Mats intervjuade en arbetskamrat från Kina som doktorerar här på KTH.

Vi kom fram till att de problem vi hade förutspått i denna målgrupp inte var så relevanta då de flesta idag talar tillräckligt bra engelska för att kunna göra sig förstådda. Många av de vi intervjuade berättade att de hade fått intrycket att svenskar gärna talar engelska och att de flesta talar det väl.



Turister fanns det lite ont om på stan den här tiden på året men vi lyckades hitta några som var villiga att svara på frågor och kompletterade även med en enkät på Internet. Exempelvis intervjuade Oscar ett ungt tyskt par och Marwan och Marcus lyckades intervjua några turister på Internet.

De flesta unga turister hade inte planerat sin resa så noga. Vissa berättade att de inte visste var de skulle börja planera sin resa. Ett problem som en av intervjuerna upplyste var att nuvarande tjänster för att planera resor inte visar säsongsberoende öppettider. Några turister hade alltså åkt hit och blivit besvikna för att så mycket var stängt.

Slutsats

Det förutspådda problemet som bäst stämde överens med resultatet från fältstudien är det att det är svårt att planera resor i förväg. Vi bestämde oss alltså för att utveckla produktidéen om en webbplats för att planera en vistelse i Stockholm. 

Problem hos målgrupper

Under övningen bestämde vi möjliga problem för de målgrupper vi hade definierat under samma övning. Detta är vad vi förutspådde och skulle undersöka i fältstudien.

1. Turister som inte talar svenska

Problem

Vi förutspådde att turister som ville åka till Stockholm skulle ha svårt att planera resan i förväg. Vi misstänkte att det skulle vara svårt att hitta tillräckligt med information för att kunna "matcha" olika aktiviteter.

Produktidéer

En sort reseplanerare på webben som ska tillhandahålla information om aktiviteter i Stockholm. Den ska rekommendera aktiviteter baserat på intressen angivna av användaren. Man ska även ha möjlighet att rösta på aktiviteter för att rekommendera dem för andra turister.

2. Studenter som inte talar svenska

Problem

Vi misstänkte att man den första tiden skulle ha problem med att handla mat då det i mataffärer oftast bara finns information på svenska. Vi misstänkte att samma problem skulle finnas med kollektivtrafiken då t.ex. hållplatserna endast står och ropas ut på svenska.

Produktidéer

En applikation till smartphones som ska hjälpa till med mathandel genom att erbjuda en funktion för att läsa av streckkoder och tillhandahålla information om produkten, t.ex. namn på användarens språk och pris i användarens valuta. 

3. Svensktalande studenter

Problem

Vi förutspådde att denna målgrupp inte skulle ha så mycket problem men vi var nyfikna på vilka eventuella problem denna målgrupp skulle ha gemensamt med målgrupp nummer 2.

Produktiéer

Inga då denna målgrupp huvudsakligen var en referenspunkt för målgrupp 2.

4. Engelsktalande som ska arbeta

Problem

Vi förutspådde liknande problem för denna målgrupp som för målgrupp nummer 2 men även att det kunde vara svårt att hitta fritidssysslor. Det som försvårar detta jämfört med målgrupp 2 är att de inte får några fritidssysslor via arbetet.

Produktidéer

Samma som för målgrupp 2.