Bij aanvang van een iPhone of iPad app ontwikkeltraject, weet geen van de betrokkenen precies wat het eindresultaat gaat worden. Dat is niet omdat de opdrachtgever geen visie heeft, en ook niet omdat de freelancer onervaren is. Het is omdat A) er altijd een communicatie-kloof zit tussen de opdrachtgever en de programmeur,  B) de lijst van eisen altijd onvolledig is bij de aanvang van het project en C) veel van de bestaande eisen (zogen. “requirements”) gedurende het traject bijgeschaafd zullen worden of worden verhoogd / verlaagd in prioriteit. Er zullen ook requirements zijn die het helemaal niet halen in het eindproduct. Waarom? Omdat het doel een goede, gebruiksvriendelijke en doeltreffende app is, en niet eentje die aan het theoretische lijstje aan requirements voldoet.

De praktijk is namelijk weerbarstig. Als een scherm of soms de hele app eenmaal gemaakt is en de opdrachtgever het test en ziet, dan pas wordt duidelijk dat wat de opdrachtgever bedoelde niet zo werd begrepen door de ontwikkelaar. En dat er zaken niet inzitten waar de opdrachtgever niet aan gedacht zou hebben maar die hij bij het zien van de app wel vanzelfsprekend vindt.

Als voorbeeld een app voor een klant die in een Android variant en een iOS variant werd gemaakt. Deze app registreerde onder andere de start-, pauze- en eindtijd gedurende een werkdag van een werknemer. In de iOS variant werd bij elke belangrijke actie (bijv. “Start pauze”, “Stop pauze”) gevraagd of de gebruiker akkoord ging met de actie (en dus niet per ongeluk op de knop had gedrukt). In de Android variant werd de actie gewoon uitgevoerd.

De klant zou er echter nooit uit zichzelf op gekomen zijn dat er een bevestiging nodig is bij elke actie, maar de afwezigheid van zo’n knop werd toch als gemis gezien in de Android versie van de app op het moment dat ze het onder ogen kregen.

De Android app ontwikkelaar reageert hier uiteraard op door iets soortgelijks in te bouwen in de Android versie van de app. Een goede (freelance) iPhone / iPad programmeur is ook altijd flexibel wanneer het moet, en beweegt mee met de veranderende requirements.

Maar, die flexibiliteit kost de opdrachtgever vaak geld en tijd. De ontwikkeltijd wordt namelijk fors verlengd bij wijzigende specificaties. Maar hoe kunnen we dat voorkomen? Hoe kunnen we ervoor zorgen dat de specificaties zo duidelijk mogelijk zijn?

Een deel van de oplossing is een zogenaamd klikbaar design, ook wel klikbaar prototype genoemd. Dit is een serie van designs van bepaalde schermen, plaatjes van hoe de app er uit gaat zien volgens de designer / programmeur, maar dan aan elkaar gekoppeld. Zodat er via een vooraf bepaald pad door de hele app kan worden gelopen, zonder dat er ook maar begonnen is met het maken er van.

Hotspots in een klikbaar design

Een klikbaar design is dus een vast, van te voren bepaald pad door de toekomstige app, in de vorm van afbeeldingen (screenshots) die aan elkaar gekoppeld zijn. Bovenstaande screenshot is dus gewoon een plaatje. De emails bestaan niet echt en het scherm is niet scrollbaar. Het is een representatie van hoe dit scherm in de app er volgens de designer en of programmeur uit gaat zien. De vijf blauwe gedeeltes zijn klikbaar. Als op “Search” wordt geklikt, wordt een nieuwe afbeelding getoond, een plaatje van hoe de designer de zoekfunctie voor zich ziet.

Doordat het niet een domme serie aan plaatjes is, maar elke nieuwe afbeelding pas getoond wordt na een klik op een specifiek gedeelte van de huidige getoonde afbeelding, voelt het geheel zeer echt aan. Regelmatig komt het voor dat degene die het klikbaar design onder ogen krijgt, probeert te scrollen in de afbeeldingen omdat het zo realistisch overkomt. Dit zorgt er ook voor dat veel sneller naar boven komt wat er nog aan de gebruikservaring verbeterd dient te worden. En met name dat is in de praktijk het belang van het klikbare prototype boven een “normaal” design. Want in de top-level requirement “we willen een intuïtieve gebruiksvriendelijke app die X en Y doet” zijn X en Y te definiëren, maar “intuitief” en “gebruiksvriendelijk” niet of moeilijk concreet te maken. Een misinterpretatie is snel gemaakt.

Waar intuitiviteit en gebruiksgemak belangrijk zijn, bent u er dus altijd mee geholpen de extra investering te doen in een klikbaar design, iets wat zich met gemak meer dan dubbel terugverdient in verminderde ontwikkeltijd. Voor vragen hierover kunt u altijd contact met mij opnemen.

Een voorbeeld van goede en voor de toekomst veelbelovende klikbaar designsoftware voor zowel iOS als Android is Invision.

Dit artikel is geschreven door Arjan van der Laan

Gebruikte afbeeldingen afkomstig van Wired en Guidingtech