In deze reeks van vier blogs nemen wij, Talent Area Digital, jullie mee in ons avontuur om een (web)app te ontwikkelen. In de eerste blog bespraken wij ons idee, onze Agile werkwijze en de onderzoeksfase. Vervolgens zoomden we in de tweede blog in op het bouwen van een prototype in Figma en het testen hiervan met de eindgebruikers. In de derde blog vertelden we je meer over het bouwen van je prototype naar een werkend product. Deze vierde blog neemt je mee in de laatste fase: final testing en de launch. Dat klinkt als puntjes op de ‘i’, maar in werkelijkheid houdt deze fase meer in dan dat; je blijft itereren in de slotfase!

🧪 Fase 4: Testing & Optimalisatie

Daar is ‘ie dan: je eigen (web)applicatie! Je wilt nu gaan testen of je product ook echt goed werkt. En niet alleen op jouw eigen apparaat, maar ook op die van je gebruikers. Oftewel, “device responsiveness”. Het komt namelijk vaak voor dat op jouw eigen laptop alles er piekfijn uitziet, maar dat het op je telefoon heel anders lijkt. Dan zul je weer even terug moeten naar de tekentafel.

Het is hierbij belangrijk dat je alle klantreizen van begin tot eind doorloopt op verschillende apparaten. Voorbeelden van aanpassingen waar je bijvoorbeeld tegenaan kan lopen:

• Schalen van afbeeldingen: Maak voor logo’s en animaties gebruik van schaalbare vectorafbeeldingen (SVG’s) in plaats van bijvoorbeeld .JPG of .PNG-bestanden. SVG bestanden kunnen namelijk oneindig schalen.
• Knop-grootte: Op een mobiel apparaat zoals een tablet of smartphone klik je een knop aan met je vinger in plaats van met een muis. Over het algemeen is het daarom verstandig om klikbare content op mobiele apparaten groter te maken. Een richtlijn is een hoogte van ten minste 48px.
• Embrace the difference!: Verschillende apparaten kunnen verschillende functies uitvoeren. Maak daar gebruik van! Zo kun je bijvoorbeeld ervoor zorgen dat een telefoonnummer op een mobiel apparaat automatisch linkt naar de functionaliteit ‘Bellen’ op je telefoon. 

Test Tips

De ervaring leert. Om dit proces beter te stroomlijnen hebben we een aantal tips op een rijtje gezet:

1. 4 ogen zien meer dan 2: Test altijd minimaal met z’n tweeën, een bouwer en een tester. Niet alleen gezellig, maar zo kun je ook meteen je product aanpassen tijdens het testen.
2. Get it done: Bouw modules in één keer, bijvoorbeeld door er een hele dag mee bezig te zijn, i.p.v. de uren verspreid over een aantal weken. Zo houd je alles top of mind en verlies je minder tijd met “hoe zat het ook alweer?” momenten.
3. Test omgeving: Zorg dat je een kopie van je product maakt (met test data) waarmee je risicoloos kunt experimenteren met nieuwe code. Gaat er dan wat fout, gebruik je (console) logs om te achterhalen waar het fout ging.

3…2…1… Ignition!

De laatste ‘test’ is de Demo. Hier test je in hoeverre je product voldoet aan de wensen van je stakeholders en/of (potentiële) gebruikers. Presenteer aan je stakeholders eindresultaat van je inspanningen.

Hoe doe je dat?

• Nodig al je stakeholders uit.
• Presenteer het resultaat én het proces. Wat waren het doel, gemaakte keuzes, geleerde lessen en what’s next?
• Laat stakeholders het product zelf ervaren.
• Ga na je presentatie in gesprek met je stakeholders om zo meer uitleg te kunnen geven en de eerste indruk/feedback op te halen.
• Vier het resultaat met je team!

Dat hoeft er niet zo uit te zien. Kies een stijl die past bij jouw team en jouw organisatie. Die van ons had in ieder geval veel GIFjes.

Hoe nu verder?

Je hebt nu een werkend product gelanceerd. Maar als de bubbels uit de fles zijn gaat het werk weer door. Afhankelijk van je (interne) klant zullen er nog werkzaamheden plaatsvinden na de lancering. Het product moet goed in beheer genomen worden en wellicht komen er nog aanvragen voor nieuwe functionaliteiten. Spreek dus goed af hoe je omgaat met klantfeedback en communiceer naar klanten als er iets gedaan is met hun feedback. Ook gaan we bepaalde taken overdragen aan andere afdelingen en kennis over (de bouw) van het product delen zodat het product toekomst bestendig blijft.