van A naar Beter app

Procesverslag RWS: Doorontwikkeling van A naar Beter app Uitgave: 6-12-2012, versie 1.0 Door JBLT ; Jonathan Marchal, Bas van Agten, Laurens Carbo, Thijs Blaas

Inhoudsopgave 1. Inleiding... 03 2. Organisatie en werkwijze 2.1. Opdrachtgever 2.2. Organisatie 2.3. Werkwijze... 04... 04... 04... 04 3. Projectplan 3.1. Resultaatdefinitie 3.1.1. Opdrachtomschrijving 3.1.2. Debriefing 3.2. Probleemstelling 3.2.1. SSBK model 3.2.2. Hoofdvraag en deelvragen 3.3. Eisen en randvoorwaarden 3.3.1. Randvoorwaarden 3.3.2. Functionele eisen 3.3.3. Niet-functionele eisen 3.4. Eindproduct 3.5. Plan van aanpak 3.5.1. Fasering 3.5.2. Strokenplanning... 06... 06... 06... 06... 07... 07... 08... 08... 08... 09... 09... 09... 10... 10... 10 2 Procesverslag

1. Inleiding In dit document vind je het projectplan van projectgroep JBLT voor het doorontwikkelen van de van A naar Beter applicatie voor Rijkswaterstaat. De organisatiestructuur en werkwijze zijn uitgelicht en er wordt een resultaatdefinitie weergeven. In de resultaatdefinitie wordt het probleem geanalyseerd en een schets gemaakt van de uiteindelijk op te leveren producten. Ook de planning voor het project is uitgeschreven in fases en in een strokenplanning weergeven. Het procesverslag zal bij elke fase uitgebreid en aangevult worden. 3 Procesverslag

2. Organisatie en werkwijze 2.1. Opdrachtgever Opdrachtgever: Afdeling: Locatie: Rijkswaterstaat, Ministerie van Infrastructuur en Milieu Corporate Dienst, Expertise Online Utrecht Contactpersoon: Lonneke van Dijk Mail: lonneke.van.dijk@rws.nl Telefoon: +31 (0)6 533 879 53 2.2. Organisatie Organisatie: Teamleden: Mail: jblt Jonathan Marchal Bas van Agten Laurens Carbo Thijs Blaas jonathan.marchal@student.hu.nl bas.vanagten@student.hu.nl laurens.carbo@student.hu.nl thijs.blaas@student.hu.nl 2.3. Werkwijze Het project start op 13 november 2012 en zal 10 weken lopen (exclusief 2 weken kerstvakantie). De eindpresentatie vind plaats op 29 januari 2013, tenzij de opdrachtgever anders beslist in overeenstemming met de uitvoerende partij. In deze 10 weken zal de uit voerende partij een procesverslag bijhouden. De opdrachtgever zal tussentijds verschillende versies van dit verslag ontvangen om inkijk te krijgen in de status van het project. Het definitieve procesverslag zal minstens een week voor de eindpresentatie aan de opdrachtgever gepresenteerd moeten worden. Werkplekken en tijden Elke dinsdag van 08.30 tot 12.30 hebben we de mogelijkheid om te werken in lokaal 2S240. Andere tijden en dagen zullen we zelf een werkplek moeten regelen. De dinsdag wordt standaard gereserveerd om aan het project te werken. Maandag- en woensdagmiddag zijn optionele middagen om in teamverband te werken. Dit spreken de teamleden onderling af. Thijs Blaas is aanspreekpunt voor het afhuren van lokalen, tenzij onderling anders is beslist. 4 Procesverslag

2. Organisatie en werkwijze vervolg 2.3. Werkwijze Communicatie Bas van Agten is projectleider van het team en is in het algemeen aanspreekpunt voor de groep voor docenten en de oprachtgever, tenzij onderling anders is beslist. Indien een teamlid contact heeft met docent of opdrachtgever dient hij ten alle tijden de andere groepsleden in de cc mee te nemen. De docent wordt op de hoogte gehouden via het blog. Hier posten de groepsleden alles dat heeft te maken met de ontwikkeling van het project. Jonathan Marchal is verantwoordelijk voor dit blog. Voor het onderling uitwisselen van documenten maken we gebruik van een dropbox folder. Indien een groepslid de afgesproken tijd niet kan halen dient hij dat voor aanvang van de afspraak aan te geven bij de andere groepsleden. Bij voorkeur over de groeps-whatsapp. Bij volledige afwezigheid dient dit op zijn minst 24 uur van te voren gemeld te worden. 5 Procesverslag

3. Projectplan 3.1. Resultaatdefinitie 3.1.1. Opdrachtomschrijving Achtergrond Rijkswaterstaat zorgt onder andere voor een beter doorstroming op weg en vaarweg. Een van de labels waaruit zij communiceert is van A naar Beter. Van A naar Beter informeert weggebruikers over geplande wegwerkzaamheden aan rijkswegen, verkeershinder en mogelijke (voordelige) reisalternatieven. Probleem 24 augustus is onze vananaarbeter app gelanceerd. Nu alleen nog voor iphone, in november komt er ook een versie voor android. Voor volgend jaar hebben we een aantal nieuwe versies in de planning staan. We hebben zelf enkele ideeën, zoals een agendafunctie waarmee wegwerkzaamheden op vaste routes alvast vooruit in de agenda gezet kunnen worden, of mogelijkheden om alternatieve rijroutes te presenteren, maar zijn ook geïnteresseerd in uitwerkingen van andere mogelijkheden waar wij misschien niet aan gedacht hebben. Ideeen voor de nieuwe versie hoeven niet alleen maar uit de hoek van functionaliteiten te komen. Ook wijzigingen uit de hoek van UX/usability vinden wij interessant. De doelgroep Weggebuikers (in bezit van iphone/android) Eindresultaat Het eindproduct is bij voorkeur een prototype dat wij bij een usabilitytest aan een gebruiker kunnen voorleggen. 3.1.2. Debriefing Wat is de huidige situatie van de opdrachtgever? Rijkswaterstaat heeft op 24 augustus 2012 een applicatie gelanceerd voor vananaarbeter.nl. De huidige app is nu nog beperkt in functionaliteiten. Rijkswaterstaat wil graag tegemoetkomen aan de wensen van de gebruikers van de app en heeft een lijst van 11 verbeterpunten opgesteld. Daarnaast staan zij open voor eventuele verbeterpunten die wij aan kunnen tonen aan de hand van relevant onderzoek. Op 16 November is de app gelanceerd voor Android-toestellen. 6 Procesverslag

3. Projectplan vervolg 3.1.2. Debriefing Welk resultaat word er verwacht? Een mogelijke oplossing voor 1 of 2 van bovengenoemde verbeterpunten. Deliverables zijn: een werkend prototype Hi-Fi of Lo-Fi, procesverslag en een handleiding. Een voorstel voor usability testing is zeer wenselijk. De voorstellen moeten binnen 1 jaar gerealiseerd kunnen worden. Wat is het plan om daar te komen? We gaan de huidige applicatie bestuderen en onderzoeken de huidige behoeftes van de gebruiker en van de opdrachtgever. Dit kunnen we doen door de wensen van de klant scherp te krijgen door middel van bijvoorbeeld field-research en customer journey maps. Van hieruit ontwikkelen we een concept en een prototype die we onderwerpen aan usability tests. De testresultaten evalueren we en gebruiken we om verbeteringen door te voeren in het prototype tot een definitief product. Wat zijn de mogelijke risico s? Het grootste risico is dat we een verkeerde analyse van de behoefte van de gebruiker vast stellen en gaan werken aan een irrelevant ontwerp en concept. Het is daarom van groot belang dat we de behoefte van de gebruiker goed onderzoeken. Met welke punten gaan wij aan de slag? We gaan aan de slag met punt 5 en 6 van de prioriteitenlijst. Hiervoor gaan we eerst de bestaande contactformulieren doorlichten en testen. Op deze manier willen we kijken waar de zwakke punten liggen. Op deze punten willen wij inspelen, de kennis hiervoor halen we uit bestaande literatuur en uit onze eigen bevindingen. Hiervoor gebruiken we onder andere het boek WEB FORM DESIGN Filling in the Blanks van LUKE WROBLEWSKI. 3.2. Probleemstelling 3.2.1. SSBK model Situatie nu De manier waarop contact opgenomen kan worden met Rijkswaterstaat in de applicatie en op de website voor feedback, klachten en andere vormen van contact is niet of nauwelijks gebruikersvriendelijk. Situatie gewenst Alle contactmogelijkheden binnen de applicatie en op de website zijn voor elke bezoeker van deze media volledig te begrijpen en binnen een minuut in te vullen. Daarnaast zijn alle ontwerpkeuzes voor deze contactmogelijkheden onderbouwd aan de hand van testresultaten en bestaand onderzoek. 7 Procesverslag

3. Projectplan vervolg 3.2.1. SSBK model Blokkade Er zijn veel manieren om informatie van een gebruiker te krijgen door middel van contact mogelijkheden. Ook hebben veel experts zich hier over gebogen en beweren de meest efficiënte manier te hebben en geven tips hiervoor. Het is moeilijk om de juiste manieren en tips te vinden bij de juiste context. Het is dus onduidelijk wat de meest efficiënte en gebruikersvriendelijke manier is voor het bieden van contactmogelijkheden binnen de applicatie en op de website. Klantvraag Hoe kunnen we de contactmogelijkheden binnen de applicatie en op de website effi ciënter en gebruikersvriendelijker maken? 3.2.2. Hoofdvraag en deelvragen Hoofdvraag Hoe kunnen we de contactmogelijkheden binnen de applicatie en op de website effi ciënter en gebruikersvriendelijker maken? Deelvragen Wat zijn alle contactmogelijkheden binnen de app en op de website? In welke context worden de contactmogelijkheden gebruikt? Welke contactmogelijkheden zijn allemaal nodig? Wie zijn de gebruikers van de applicatie? Hoe kunnen we de gebruikers het beste testen? Wie zijn de experts op dit gebied en welk werk van hun is relevant? Wanneer zijn de contactmogelijkheden efficiënter en gebruikersvriendelijker? 3.3. Eisen en randvoorwaarden 3.3.1. Randvoorwaarden Code Omschrijving R1 Het ontwerp moet binnen een jaar door Shareware gerealiseerd kunnen worden. R2 1 of 2 van de door RWS geconstateerde verbeterpunten moet(en) opgelost worden. 8 Procesverslag

3. Projectplan 3.3.2. Functionele eisen Code Omschrijving F1 Het systeem moet duidelijke en relevante feedback geven na het gebruik van een contactmogelijkheid. 3.3.3. Niet-functionele eisen Code Omschrijving Alle contactmogelijkheden dienen binnen een minuut begrepen en gebruikt te kunnen worden door de NF1 doelgroep. Streefwaarden 80% van de testpersonen 3.4. Eindproduct Aan het eind van dit project leveren we de volgende onderdelen op: Een Hi-Fi prototype die klaar is voor Usability tests. Een duidelijke handleiding van het prototype waarmee shareware dit prototype kan implementeren in de huidige applicatie. Het procesverslag met alle documentatie van de groep voor dit project. Optioneel op te leveren onderdelen: Een testopzet voor het doen van usability tests met het eindproduct. 9 Procesverslag

3. Projectplan 3.5. Plan van aanpak 3.5.1. Fasering Fase Omschrijving Producten Inlezen Opdracht doorlezen. Organisatie en werkwijze Analyseren Opdracht en product analyseren. Projectplan Onderzoeken Onderzoek doen naar het product, de gebruiker en andere relevante Onderzoeksresultaten variabelen. Testen Usability tests aan de hand van de gebruikelijke app en eigen testopzetten Testresultaten Conceptualiseren Een concept maken aan de hand van onderzoeks- en testresultaten Concept Produceren Het concept omzetten tot een hi-fi Hi-Fi prototype prototype Testopzet Presenteren Een presentatie van het eindproduct. Klantpresentatie 3.5.2. Strokenplanning Fase \ Week 1 2 3 4 5 6 x x 7 8 9 10 Inlezen Analyseren Onderzoeken Testen Conceptualiseren Produceren Presenteren 10 Procesverslag