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å).

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.

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

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.