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