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