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 weer geven. 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: Mail: Telefoon:
Lonneke van Dijk
[email protected] +31 (0)6 533 879 53
2.2. Organisatie Organisatie: Teamleden: Mail:
jblt Jonathan Marchal Bas van Agten Laurens Carbo Thijs Blaas
[email protected] [email protected] [email protected] [email protected]
2.3. Werkwijze Het project start op 13 november 2012 en zal 10 weken lopen (exclusief 2 weken kerst vakantie). 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 uitvoerende 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 agenda functie 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 contactmogelijkheden. 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 efficiënter en gebruikersvriendelijker maken?
3.2.2. Hoofdvraag en deelvragen Hoofdvraag
Hoe kunnen we de contactmogelijkheden binnen de applicatie en op de website efficië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 NF1
Alle contactmogelijkheden dienen binnen een minuut begrepen en gebruikt te kunnen worden door de 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 Inlezen Analyseren
Onderzoeken Testen Conceptualiseren Produceren Presenteren
Omschrijving Opdracht doorlezen. Opdracht en product analyseren. Onderzoek doen naar het product, de gebruiker en andere relevante variabelen. Usability tests aan de hand van de gebruikelijke app en eigen testopzetten Een concept maken aan de hand van onderzoeks- en testresultaten Het concept omzetten tot een hi-fi prototype Een presentatie van het eindproduct.
3.5.2. Strokenplanning Fase \ Week Inlezen Analyseren Onderzoeken Testen Conceptualiseren Produceren Presenteren
10 | Procesverslag
1
2
3
4
5
6
x
Producten Organisatie en werkwijze Projectplan Onderzoeksresultaten Testresultaten Concept Hi-Fi prototype Testopzet Klantpresentatie
x
7
8
9
10
