Buienradar:
Fiets naar werk
User research, prototyping, usability testing
Mensen klagen steeds vaker over dat Buienradar ernaast zit. Ze geven slechte reviews, delen het online en switchen van app. Hoe is dat op te lossen? Hoe maak je Buienradar weer betekenisvoller?
In het kort:
- Duur: 12 weken
- Context: Opleiding/studie
- Uitdaging: Maak Buienradar betekenisvoller
- Frustratie: Mensen die naar werk fiets worden regelmatig nat en moeten zelf de regen berekenen.
- Onderzoek: Surveys. Klantinterviews, Concurrentie analyse.
- Prototyping: Schetsen, Wireframes, Usability testing, Rapid Usability testing, Wizard of Oz
- Resultaat: Een persoonlijke weerassistent die fietsers wel leuk en interessant vinden, maar niet waardevol genoeg.
01 Problem finding
Problemen ontdekken in 20 korte interviews.
Inzicht: iedereen gebruikt Buienradar voor zijn/haar persoonlijke doelen
- Veel mensen vertrouwen de app niet en dus gebruiken ze meerdere apps
- 50% Van de mensen zegt dat Buienradar er afgelopen week naast zat
- 50% Zegt dat ze geïrriteerd of gefrustreerd waren omdat Buienradar er naast zat omdat het consequenties voor een activiteit had
- Ik check om te bepalen welke kleding ik aan moet trekken
- Als ik naar werk fiets moet ik de regen checken over de route
- Blijft het droog?
- Moet ik een trui aan?
- Gaat mijn training nog door?
02 Focus
Focus op mensen die wekelijks naar werk fietsen. Als we voor hun de app betekenisvoller kunnen maken, dan kan dat ook voor anderen.
Op een zonnige dag naar werk fietsen is geen probleem. Op een wisselvallige dag is dat anders. Dan moeten ze de regen zelf over hun route berekenen en bestaat er een grote kans dat ze alsnog nat worden. Of op terugweg.
Ik besloot om te focussen op deze gebruikers. Want als ik de app voor hun betekenisvoller kan maken, dan kan dat ook voor anderen. Bijvoorbeeld: hardlopers, moestuinders, mensen met kinderen, etc.
03 Empathize
Uit 3 diepte interviews blijkt dat mensen veel beslissingen moeten nemen als ze naar werk fietsen.
Op een zomerse dag is het makkelijk, maar zodra het regent zijn er allerlei vragen:
- Welke kleding moet ik aan?
- Vertrouw ik het weer wel?
- Moet ik regenkleding mee of niet?
- Moet ik nu gaan fietsen? Of moet ik nog even wachten?
- Hoe lang duurt de bui nog?
- Hoe is het weer op de terugweg?
- Etc.
04 Hypothese
Hypothese: Als we de regen over de route berekenen en de beste vertrektijd adviseren, dan maken we het beslisproces makkelijker
- User need: Gebruiker wil in controle zijn en weten waar hij/zij aan toe is.
- Hypothese: Als we de regen over de route berekenen en laten zien waar hij/zij aan toe is, dan maken we de app betekenisvoller.
- Test: Ontwerp een weer assistent die vertelt wanneer hij/zij het beste kan vertrekken. En of er regenkleding nodig is.
- Succes Metrics: Als 80% van de testers de functie waardevol vindt
05 Ideation / Schetsen
Een weerassistent die twee zaken adviseert:
de beste vertrektijd en of je regenkleding moet meenemen.
06 Wireframes
Klikbaar prototype klaar om de weerassistent te testen en te installeren.
Op basis van de schetsen ontwierp ik een klikbaar prototype in Figma. Met als doel: testbaar prototype van de weerassistent en installatie flow.
07 Usability testing
Usability test, 5 deelnemers, 2 taken: installeren en gebruiken.
2 Live testen, 3 remote (vanwege Covid).
Top 5 usability issues:
- Iedere deelnemer had moeite met het vinden waar hij/zij de feature instelt.
- Het overzichtscherm was verwarrend, testers zagen de “maak nieuwe” button over het hoofd
- 4 van 5 deelnemers zagen de animatievlag aan als beste vertrektijd
- Niemand gebruikte de buttons om te bepalen wanneer te vertrekken
- Maar één persoon keek expliciet naar de radar.
08 High fidelity prototype
Oplossingen voor de top 5 usability issues
09 Testing
Nieuwe oplossingen = Nieuwe aannames.
Met rapid usability testing ontdekte ik dat de weerassistent
duidelijk was, maar de installatieroute niet.
10 Resultaat
Weerassistent & installatie flow (Figma prototypes)
10 Resultaat
Een slimme oplossing voor drukke mensen, maar maakt dit Buienradar betekenisvoller?
Om dit te checken stuurde ik nog een survey naar 90 mensen. 79% van de fietsers zei “ja” tegen de functie. Maar ja zeggen, is wat anders dan doen. Een beetje validatie, maar niet genoeg in mijn ogen.
11 Wizard of OZ prototype
Persoonlijk fietsadvies (per SMS) voor een kleine testgroep (11), na twee weken stopt de service. Maar 1 deelnemer vindt dat “erg jammer”, dus geen validatie.
Een kleine testgroep, geworven via Linkedin, ontvangt twee weken lang een SMS met fietsadvies. Daarna stopt de service en vraag ik deelnemers of ze het erg jammer, jammer of niet erg vinden. Mijn hypothese is dat als 40% of meer deelnemers het erg jammer vinden, dan de functie gevalideerd is.
Conclusie: geen validatie van de fiets naar werk functie
12 Reflectie
Inzicht: Het vinden van een écht probleem is belangrijker dan het ontwerpen testen van een “half” probleem. Ook al kost het vinden meer tijd.
In dit proces heb ik te snel de conclusie getrokken dat een weerassistent waardevol genoeg was. Dat bleek achteraf niet zo te zijn. Als ik dieper en verder user research had gedaan, dan had de oplossing waarschijnlijk totaal anders geweest (wellicht buiten Buienradar).
Belangrijkste leerpunten:
- Dieper en meer gebruikersonderzoek uitvoeren
- De wizard of Oz test sneller toepassen te validatie / ontkrachting
- Het is belangrijk om een echt probleem op te lossen, dan een half probleem. Dat bespaart veel tijd, energie en kosten.
