Requirements beschrijven waaraan een product moet voldoen, wat het biedt, welke randvoorwaarden er zijn, hoe het eruit gaat zien, voor wie het bedoeld is, hoe het gaat werken, etc. Maar het blijft een beschrijving, met als nadeel dat iedereen die het leest een eigen interpretatie heeft.

Bij de meeste projecten worden diverse scenario’s met de eindgebruiker of de klant nagespeeld om te bepalen of de specificatie aansluit bij de verwachting. Dit naspelen maakt het voor een eindgebruiker inzichtelijk, aangezien het simuleren en visualiseren van het beoogde gedrag veel meer tot de verbeelding spreekt. En dit voorkomt dat de eindgebruiker een eigen interpretatie maakt van de specificatie. Zoals beschreven in een blog van Karl O’Brien over ‘Requirements are done…‘: “It is like watching a movie versus reading the book, everyone can interpret a book in many ways.”.

Echter stopt het vaak bij de simulaties voor de eindgebruikers, terwijl dezelfde manier van visuele simulatie ook voor de ontwikkelaars en testers van groot belang is. Kans op misinterpretatie bij een eindgebruiker is nu beperkt, maar bij de ontwikkelaars en testers is de kans daarop nog steeds erg groot. Resultaat: het product wordt ontwikkeld met de misinterpretatie en sluit nog steeds niet aan bij de eindgebruiker, tot groot onvrede. Want per slot van rekening heeft de gebruiker tijd geïnvesteerd in validatie, maar ziet deze daar onvoldoende van terug.

Werkwijze

Hoe kun je dit concreet vormgeven, zodat naast gebruikers ook de ontwikkelaars en testers hierin meegenomen worden? Enkele voorbeelden van technieken:

Applicatie-flow

De applicatie-flow bevat schermschetsen van alle flow onderdelen, en deze zijn in de juiste volgorde geplaatst en met pijlen aan elkaar gekoppeld. Zo is er inzicht te krijgen in hoe de applicatie gaat werken.
Bij een van onze projecten hebben we de complete applicatie-flow uitgeprint en groot aan de muur gehangen. Wanneer er een nieuw onderdeel door de ontwikkelaars opgepakt werd, kon de werking daarvan goed uitgelegd worden aan de hand van de applicatie-flow. Ook bij onduidelijkheden waren de ontwikkelaars met regelmaat bij de applicatie-flow-muur te vinden.

Webflow aan de muur

Paper prototypen

Paper prototyping stelt ons in staat om heel snel ideeën te verifiëren met klanten en gebruikers. Zoals de term al suggereert wordt het prototype van de software gemaakt van papier, gebruikmakend van bijvoorbeeld PostIt notes, gekleurd papier, schaar en markers. Maar ook het tekenen of knippen/plakken van schermelementen kan goed werken. De verschillende schermonderdelen worden in papier uitgevoerd en op het ’scherm’ (een vel papier of het bureaublad) geplaatst. Vervolgens kan de gebruiker met de ’software’ gaan werken. Wij zijn de ‘computer’, en reageren op de acties van de gebruiker zoals de software het uiteindelijk ook zou gaan doen. Deze manier van werken is goed om te valideren bij een klant, en de uitkomst kan vervolgens via het paper prototype aan engineers getoond worden.

Paper prototype

Wire frames

Het visualiseren van concepten in schetsmatige schermen dwingt ontwikkelaars beslissingen te nemen over functionaliteiten en structuur, en brengt problemen in een vroeg stadium aan het licht. De visualisaties maken het ook mogelijk om de concepten te communiceren naar mensen buiten het team, bijvoorbeeld klanten of gebruikers.
Tenslotte vormen visualisaties zeer expliciete ontwerpdocumentatie; een goede serie (eventueel pixel-perfect) schetsen laat engineers weinig te raden over.

Wire frames als flow diagram

Simulaties

Veel van het gedrag kan via de bovenstaande manieren inzichtelijk gemaakt worden. Maar het blijft bijzonder moeilijk om interactie aspecten via statische plaatjes duidelijk te maken of tekstueel te beschrijven, laat staan dat gebruikers en ontwikkelaars het vervolgens juist kunnen interpreteren.
Door simulaties in te zetten kan met een clickable prototype, video of animatie veel beter bepaald worden of een interactie aspect werkt zoals het bedacht is. Enerzijds kan aan gebruikers getoond worden hoe bepaald gedrag zal gaan werken, en anderzijds is het ook uitermate geschikt voor engineers om het beoogde gedrag correct te implementeren.

Voordeel

Deze technieken voorkomen of beperken misinterpretatie, niet alleen bij de eindgebruikers, maar ook bij de ontwikkelaars en testers. De hele ontwikkelketen dient dit inzicht te hebben, want “de ketting is zo sterk als de zwakste schakel”.