Na het krijgen van de opdracht om twee apps te combineren begonnen we als groep combinaties van apps te bedenken.

We gebruikte een ‘Brain-storm’ om zoveel mogelijk ideeën op papier te krijgen zonder er al te veel over na te denken. Dit leverde veel uiteenlopende ideeën op en zelfs ideeën die in de eerste instantie niet heel veelbelov-end leken konden uitgroei-en tot goede concepten om-dat de rest van de groep er verder op kon bouwen (BC 2.2.1).

Alle opties hebben we bijge-houden en na 15 minuten konden we een uiteindelijk concept kiezen om op door te gaan.

We kozen voor een door Mehri voorgestelde combi-natie van Google Maps en Spotify. We wilde de gebrui-ker hun bestemming laten ‘shuffelen’.

Dinsdag: Start Divergeren

Na het besluiten van de combinatie begonnen we met convergeren om op één lijn te komen met het ont-werp en om ontwerpvragen op te stellen.

We besloten om de ‘Four Categories Method’ te geb-ruiken, omdat we merkten dat we al veel dingen aan het bedenken waren die in de praktijk lastig te maken zouden zijn. (BC 2.2.1).

Al snel merkte dat onze on-twerpvragen gingen over problemen die pas veel later in het proces zouden komen. We hadden door dat we het

kleiner moesten houden en op de kern van het gebruik moesten focussen.

Dus kwamen we uit op de volgende ontwerpvragen:

- Waarom zou je een desti-nation willen shuffelen?

- Wat is de hoofdreden waar-om je de app zou gebruiken.

(BC 2.1.1).

Als antwoord op beide dacht-en we dat mensen dit zoud-en willen gebruiken om een stad te ontdekken waar ze niet bekend mee waren, hi-ermee gingen we door naar het prototyperen

Dinsdag: Convergeren

Met de opdracht om een pa-per prototype te maken be-gonnen we met verzamelen van materiaal.

We besloten snel dat ons protype form over function zou prioritiseren. Om dit te behalen pakte we twee sterk contrasterende kleuren om een simpel maar snel te be-grijpen prototype in elkaar te zetten.

Dit paper prototype was erg gelimiteerd in het ontwerp omdat we zo min mogeli-jk tijd wilde besteden details voordat we wisten datons concept goed werkte.

Het uiteindelijke paper pro-totype bestond uit verschil-lende optie-menu’s op pa-pier. Na het maken van een keuze door de gebruiker gaven wij het bijhorende vol-gende menu om een vol-gende keuze te laten mak-en. Nadat alle keuzes waren gemaakt konden ze een willekeurige kaart kiezen uit de door hun gekozen opties bepaalde poule.

Dinsdag: Prototyperen - Paper Prototype

We wilde snel met ons proto-type feedback gaan ophalen om een beeld te krijgen hoe een publiek zou reageren op ons ontwerp.

We werkte samen met een andere groep aan onze tafel, dus tijdens het bouwen kon-den we al feedback opvra-gen. Als voorbeeld begonnen we met 5 of 6 opties voor activiteiten in het prototype, maar kregen we als feed-back dat dit het prototype onnodig complex maakte. We besloten om het proto-type te maken met enkel 3 opties om het overzichtelijk te houden in de low-fidelity

staat waarin we het zouden testen.

Tijdens het testen op peers buiten onze tafel hebben we het gebruikersproces gefilmd zodat we later met eenterugkijkendeblik konden re-flecteren op hoe een gebrui-ker omging.

Als feedback kregen we dat het een leuk idee was en een werkelijk probleem kon oplossen, maar dat de extra moeite wel gerechtvaardigd moest worden door bijvoor-beeld meer opties en filters toe te voegen.

Dinsdag: Prototyperen - Feedback

Donderdag kregen we de opdracht om ons prototype van dinsdag verder uit te werken zodat we nog meer feedback konden ophalen.

Deze keer gebruikte we de creatieve techniek ‘Chal-lenge Assumptions’ om te identificeren waar we aan-names over maakten om ons prototype beter af te stellen op een gebruiker die onbek-end is met het concept(BC 2.2.1).

Ook gebruikte we een Sketch op een whiteboard om onze ideeën naast elkaar te krijgen (BC 2.2.1).

Donderdag: Divergeren over prototype

Op een whiteboard heb-ben we gezamelijk gecon-vergeerd. Wij waren niet blij met onze origineleontwerpvragen, dus voor ons nieuwe prototype wilde we nieuwe ontwerpvragen stel-len.

Deze ontwerpvragen war-en specifieker dan de orig-inele en hadden als doel om onszelf uit te dagen om dieper na te denken over de doelen van ons concept.

De nieuwe ontwerpvragen waren:

- Waarom zou je een random locatie willen gebruiken?

- Wat is de hoofdreden waar-om je de app zou gebruiken?

- Wanneer is de beste optie om filters in te schakelen.

- Waar gaan we de meeste aandacht aan besteden.

(BC 2.1.1).

We bedachten eerst om weer een paper prototype te maken, maar ik bracht in om het in HTML te proberen om onze skills daarin ook te testen en verbeteren

Donderdag: Convergeren over prototype

We gingen snel aan de slag met ons prototype omdat we wisten dat het maken in HTML een uitdaging zou zijn.

Mehri ging aan de slag met het visuele aspect, een paar mockup schermen om een beter idee van interactie te geven.

Eline en ik gingen aan de slag in HTML. Om het simpel te houden gingen we werken met simpele hyperlinks. Voor de filters werd je verwezen naar interne links om een volgende keuze te maken. Tegen de tijd dat de bestem-mingen moesten worden ge-shuffled werd de gebruiker

doorverwezen naar een rad waar de keuze zou worden gemaakt.

Donderdag: Prototyperen in HTML/CSS

Een HTML prototype gaf een beter begrip van de interacti-viteit en liet het beter werken omdat er geen persoonlijke ingreep van ons nodig was om het volgende menu neer te leggen. Doordat wij het niet zelf vasthielden maar het voor de gebruiker stond merkten we dat het idee sneller en beter overkwam bij mensen. Hierdoor hoefde de gebruiker minder vragen te stellen aan ons en kon het concept beter op zichzelf staan.

Deze keer hoorde we van Maarten en Sidney dat het shuffelen snel begon waar-door het aantrekkelijker was om te gebruiken om-dat het minder tijd kostte en misschien lijdt tot iets wat je anders zelf niet had gep-robeerd.

Maaike merkte op dat de rol van de afstanden onduideli-jk was. Het was niet duidelijk of het ging om lijnrechte af-stand of reisafstand.

Donderdag: Feedback op HTML Prototype

Onze feedbackvragen bij het HTML-prototype waren:

- Vervult de functie een wens van de gebruiker/zou je het willen gebruiken in je

dagelijkse leven?

- Zijn de functies van defilters duidelijk?

Zoals eerder genoemd merk-te we bij Maaike al dat het onduidelijk was wat bedoeld werd met afstand. De ande-re filters waren voor iederen duidelijk en nodig. De filters voelde nodig om toch con-trole te houden over wat de opties zijn voor de verassing.

Deze controle over de uit-komst maakte het concept aantrekkelijker omdat het een resultaat zal geven die waarschijnlijk interessant zal zijn voor een algemene geb-ruiker. Hiermee zie ik in dat we deze filters zouden moet-en behouden, ook al kost het meer tijd voor de gebrui-ker, om het nuttig en relevant voor elke gebruiker te

houden (BC 2.1.2).

Terugblik op Feedback van peers