05 Concretisering

Tijdens de concretisering werken we toe naar het afronden van ons onderzoek met daarbij als resultaat een proof of concept. Om tot dat resultaat te komen is het de bedoeling dat we onze op onderzoek gebaseerde ontwerpcriteria scherp krijgen, waarop we vervolgens onze features kunnen bouwen.

Explorerende Schetsen

Na het midterm assessment is ons gevraagd om het vraagstuk nog eens in de breedte te verkennen. Uit de voorgaande interviews hebben we nieuwe aanknopingspunten gevonden waarmee we de breedte van het vraagstuk kunnen verkennen. Op basis van deze criteria gingen we aan de slag om weer te divergeren, dit hebben we gedaan door individueel explorerende schetsen te maken.

Schetsen Frank

Frank Roodnat

"Mij lijkt het heel vet als er een centrale AI is die ervoor zorgt dat de planning zo efficiënt mogelijk in elkaar zit. Deze AI is dan te bereiken op de portofoons, de verdeelde taken zijn dan te zien op een wearable. Deze AI heeft ook toegang tot een vloot aan drones die materialen in no-time naar de bestemde plekken kan brengen. Deze drones zijn middels projection mapping ook in staat om de ruimtelijke indeling te projecteren zodat de crew site precies weet hoe het in elkaar zit."

Schetsen Lorenzo

Lorenzo de Lijser

"Ontwerp voor management en logistiek. Voor dit onderwerp heb ik drie schetsen gemaakt: Een digitaal werkbord, een horloges voor opbouwers en een bril met augmented reality. Een digitaal werkbord heeft een groot scherm waar je makkelijk de kaart van het terrein weer kan geven. Hierop kan je dus real time data displayen met werkzaamheden en materiaal. Het horloge is voor opbouwers die bijvoorbeeld in de hoogtes werken ook digitaal verbonden zijn. Een bril met augmented reality kan belangrijke informatie beamen als je ergens naar kijkt. Het kan je helpen door instructies te geven in je gezichtsveld."

Ontwerpcriteria

De ontwerpcriteria zijn gericht op de eindgebruiker en worden onderbouwd door de opgedane research. We hebben, voor ons, de belangrijkste criteria hieronder uiteengezet. In de subpagina lees je in detail over alle punten, onderbouwing en uiteindelijke toetsing. Hieronder de lijst met criteria:

• De oplossing moet toegankelijk zijn voor de site crew, leveranciers en de projectleider



Dit zijn de 3 gebruikers die we mee willen nemen in het eindontwerp. Dit hebben we besloten vanuit de data analyse. We hebben per rol gekeken welke data ze nodig hebben en welke data anderen nodig hebben van de rol zelf. Dat hebben we met elkaar verbonden, zo ontstond er een soort informatie architectuur.

Daar zagen we dat de projectleider een centrale rol speelde waar alles samenkomt. Wat logisch is want de projectleider is een persoon die het overzicht moet hebben en is verantwoordelijk voor het bereiken van het gewenste resultaat.

In het logistieke proces zijn leveranciers de factor die de spullen van a naar b verplaatsen. Een cruciale rol dus. Het is belangrijk dat ook voor hun inzichtelijk is wat er van ze verwacht wordt, waar ze moeten zijn, en dat ze door de juiste persoon ontvangen worden.

En als laatste de site crew, zij zijn verantwoordelijk voor het verwerken van de leveringen en de opbouw van het evenemententerrein. Ze worden vaak aangestuurd door iemand die boven hen staat zoals de projectleider. Het is belangrijk dat ze hun taken zo efficiënt mogelijk uitvoeren om ervoor te zorgen dat het logistieke proces geen vertraging op loopt.



• De oplossing moet het overzicht van de projectleider verbeteren.



Zoals we nu weten vervult de projectleider een sleutelrol in het logistieke proces. We merken bij de stakeholders dat het overzicht aan leveranciers soms ontbreekt. Niet alleen bij de leveranciers is dit het geval maar ook ontbreekt het soms aan inzichten over de eigen crew. Zoals bijvoorbeeld hun locatie wanneer je ze nodig hebt. Of met welke taken ze bezig zijn.

Als we deze twee factoren beter inzichtelijk kunnen maken kunnen we ook slimme manieren vinden om ze met elkaar te verbinden zonder dat de projectleider hoeft in te grijpen.



• Het ontwerp moet in staat zijn om om te kunnen gaan met de frustratie van de gebruikers.



Efficiënte communicatie is belangrijk, uit het onderzoek hebben we kunnen concluderen dat frustratie en stress factoren zijn die efficiënte communicatie niet ten goede komen. Daarom willen wij dat ons ontwerp de frustratie van de gebruiker kan waarnemen om daar vervolgens op in te spelen, met als doel het frustratieniveau te verminderen.



• De oplossing moet in staat zijn om verschillende datapunten met elkaar te verbinden om zo een efficiënte taakverdeling te maken.



Om de site crew te ondersteunen willen wij een takenoverzicht maken. Dit zorgt ervoor dat ze weten wat ze moeten doen, en minder vaak de projectleider hoeven te storen.

Ook moet de projectleider in staat zijn om taken te prioriseren. Sommige taken moeten namelijk sneller opgelost worden dan anderen.

Sommige taken moeten zelfs aan de hand van de leverancier data automatisch aangemaakt kunnen worden.



• Het eindproduct moet betaalbaar zijn voor kleinere festivals met een beperkt budget.



Uit het markt onderzoek is geen software boven komen drijven met dezelfde criteria. De meeste tools die er zijn op het gebied van festivalorganisatie en opbouw hebben te maken met de planning van het evenement, denk daarbij aan artiestenmanagement of ticketing.

Sommigen partijen leveren ook een logistiek module maar die zijn heel hoog geprijsd en onbetaalbaar voor de kleinere evenementen die geen duizenden euro’s klaar hebben liggen voor software.

Uiteindelijke Features

In de subpagina een uiteenzetting tot hoe we op deze features zijn gekomen en de verschillende functionaliteiten van deze features. We hebben ervoor gekozen de projectleider centraal te zetten omdat die in het echt ook tussen de verschillende partijen in staat.

• AI projectleider met frustratiemanagement

  Dit is het hart van de applicatie, deze projectleider is een ondersteuning voor de normale projectleider. De Ai projectleider combineert data van de verschillende factoren om zo de planning en taakverdeling zo efficiënt mogelijk te maken.

  De AI projectleider is voor de gebruikers bereikbaar in een chatinterface. De AI is uitgerust met een machine learning algoritme dat aan de input van de gebruiker kan opmaken wat frustratie is. Vervolgens, door zijn responsen aan te passen, kan de AI het frustratieniveau verlagen en minder stressvolle taken toewijzen.

  Deze feature komt voort uit het onderzoek naar de tools, we zagen dat daar de chatdienst Whatsapp heel populair was als centraal punt van verschillende soorten software. Dat kwam doordat je een groot aantal verschillende soorten bestanden erin kan delen. Zoals locaties, spraakmemo’s en planningen.

  In het digitale landschap staat Whatsapp dus centraal maar in de realiteit staat de projectleider centraal, ze delen daarin dus eenzelfde functie. Eigenlijk zijn we die twee gaan force fitten en kwamen we uit op een chat agent. En dat komt overeen met Frank zijn expertise in conversational interfaces. Tijdens zijn stage heeft Frank een chatbot gemaakt die gebruikt maakt van machine learning om frustratie uit tekst te halen. Dat sloot mooi aan op ons onderzoek en onze criteria.

  Meer over de frustratiemeting
  
  
• Als de bliksem takensysteem

  Het 'als de bliksem' takensysteem ondersteunt de sitecrew en de projectleider in het bijhouden en uitvoeren van taken. Het geeft de sitecrew een overzicht wat ze moeten doen en het helpt de projectleider met het delegeren. Hieronder in een paar punten wat deze feature inhoudt.

  • Taken worden ingedeeld door zowel de AI als de projectleider.
  • De AI projectleider doet dat middels de data van de leverancier en de site crew te combineren. En dat is ook zijn limiet, automatisch taken opstellen aan de hand van leveranciersdata.
  • Wanneer een projectleider een taak opstelt geeft de AI suggesties aan wie hij de taak moet geven. Dit baseert de AI op locatie gegevens van de crew en de hoeveelheid taken.
  • We hebben een prioriteit systeem gemaakt dat beter aansluit op de doelgroep en makkelijker in gebruik is. In plaats van een laag - midden - hoog systeem wat bij onszelf niet werkt zijn we gegaan voor de 'als de bliksem' setting. Wanneer de projectleider deze setting selecteert krijgt iemand van de site crew gelijk een notificatie.
  • Bij een korte update werd enthousiast gereageerd op deze feature
  
  
• Interactieve kaart

  Deze functie zit er eigenlijk vanaf het eerste prototype in. En we hebben gezien dat daar nog steeds draagvlak voor is. Het maakt op een visuele manier het terrein inzichtelijk voor onze eindgebruikers, de projectleider kan zo zien waar zijn crew is.

  
  
  Projectleider

  "Je wilt controle houden op wanneer mensen komen en wanneer ze er zijn. Dit is allemaal heel productiegericht." Als je de kennis hebt om apps te bouwen moet je dat zeker doen en ook koppelingen inbouwen met andere programma's. Dat maakt het interessant. dat je bv door Google Maps in de gaten kan houden waar je runners zijn, nu moet ik 10 telefoontjes per dag plegen. Dat kan bv heel makkelijk via Whatsapp, dus dat kan je ook integreren.

  
  

  En via deze kaart interacteert de projectleider ook met de leverancier. Zo kan hij zien hoever de leverancier van het terrein verwijderd is en wanneer hij aankomt. Van daaruit kan hij iemand van de site crew toewijzen aan de leverancier om hem te ontvangen. Aan de andere kant is het voor de leverancier ook inzichtelijk waar hij moet zijn en wie hem ontvangt.

Proof of research

Om toch nog een beetje de bevindingen te testen kijkt Frank terug op zijn avontuur in Mexico bij het opbouwen van het dreamfields festival.

Proof of concept

Aan de hand van onze technsiche skill set gecombineerd met de ontwerpcriteria en de featureset, hebben we besloten dat de oplossing het best tot zijn recht zou komen als webapp.

Fastive is een stuk gereedschap voor tijdens de opbouw van evenementen. Deze app is uitgerust met verschillende tools om het opbouwproces eenvoudiger en minder stressvol te maken. De AI projectleider die bereikbaar is via de chat interface in de app, is een verlengde van de echte projectleider en het hart van onze oplossing.

Design Iteraties

Voor het ontwerpen van onze proof of concept hebben we verschillende iteratieslagen gemaakt in Figma. Bekijk het ontwerp bestand hieronder.

Bekijk ons ontwerp bestand