Versiebeheer

Aan de hand van feedback van de klant worden wireframes constant gewijzigd. Om deze wijzigingen bij te houden is er onder elke afzonderlijke wireframe een tekstveld nodig waarbij de wijzigingen worden bijgehouden. Belangrijk is dus ook dat er van elke wireframe een versie wordt bijgehouden.

Benoemen van elementen

Zie dit als een soort tooltip. Een wireframe bestaat uit heel veel elementen. De functies van die elementen zijn veelal vanzelfsprekend (een knop met “bekijk” zal snel nooit naar een verwijderactie verwijzen). Sommige elementen kunnen meerdere functies hebben of de functie kan op verschillende manieren werken. Neem bijvoorbeeld een sorteerpijl in de header van een tabel. Deze sorteerpijl sorteert de ‘created_at’ datum bijvoorbeeld. Alleen: wordt er gesorteerd op dag, maand of jaar? Om een goede communicatie te verzekeren is het handig dit op een aparte plek in elke wireframe aan te geven. Zo weet de klant wat ze kunnen verwachten, de backend weet hoe ze de functie moeten maken en account managers weten waar akkoord op was gegeven.

Benoemen van componenten

Wanneer je met sommige tools gaat wireframen kan je soms in herhaling vallen. Dezelfde manier van pagination wordt op elke pagina gebruikt en om dat nou twintig keer in een wireframe te copy-pasten is zonde van de tijd. Daarbij is het ook tijdrovend om bij een verbetering al die twintig componenten aan te passen. Het meest handige is dus om één bestand aan te maken waar alle compontenten in staan. Pagination, filters, formulieren, tabellen, alles ziet er op elke pagina hetzelfde uit. Maak dus in één bestand al deze componenten en verwijs hiernaar in je wireframe, zet het component wel volledig in de wireframe maar in het geval van een wijziging hoef je het niet twintig keer aan te passen (dat doe je in je component bestand). Let ook op dat je goed aangeeft dat het hier om een verwijzing gaat. Als de klant dus vraagt om een verbetering en hij/zij ziet die niet na verloop van tijd, kan dat verwarrend zijn. Ze verwachten namelijk, vanzelfsprekend, dat het overal is aangepast.

Gebruik zo min mogelijk kleuren

Wireframes zijn oorspronkelijk bedoeld als schetsen voor je interaction design en informatie architectuur. Gebruik daarom maar een bepaald aantal kleuren. Wit, grijs en zwart zijn goede kleuren om mee te wireframen. Het nadeel bij het gebruik van veel kleuren is dat klanten het idee kunnen krijgen dat je al een hele site klaar hebt. Dit gevoel zullen ze al helemaal hebben bij het zien van een interactief wireframe. Vormgeving en interaction design moet je daarom ook los zien van elkaar. Gebruik drie kleuren (verschil in tint kan wel) en laat het grauwe kleuren zijn.

Wees pixelperfect

Het lijkt tegenstrijdig i.c.m. het idee van schetsen maar het zorgen voor pixelperfect wireframes werpt zijn vruchten bij design en front-end development zeker af. Het uitdenken van de exacte afmetingen zorgt ervoor dat je uiteindelijke design qua afmetingen overeenkomt met je interaction design. Vooral als je de designs niet zelf maakt, maar door een collega of externe partij laat doen, werkt pixelperfect wireframing voordelig.

Schets eerst met pen en papier

Of je nou een wireframe maakt in Illustrator, Omnigraffle, Visio of m.b.v. HTML/CSS, een schets op papier is zeker een goed begin. Het is makkelijk om met wat penstrepen je gedachtes op papier te zetten, daarna kan je het mooier maken met de tool naar keuze. Zo voorkom je dat je essentiële dingen vergeet en kan je direct feedback vragen aan collega’s.

Denk aan de fold

Vooral bij conversiegerichte websites is de eerste content die je ziet op een pagina van belang. Daarbij is het tegenwoordig belangrijk om ook rekening te houden met tablets (lees: iPads). Zorg dus dat je de belangrijkste content bovenaan zet (les 1 van Interaction Design). Zorg er ook voor dat mensen wat te scrollen hebben. Als je boven de fold de helft van een afbeelding ziet ben je eerder geneigd naar onder te scrollen (onder de fold) om te zien wat er nog meer op die afbeelding staat. Ook zit er een verschil in de grootte van het scherm en de grootte van de viewport (dus een adresbalk en bookmarkbalk bij je browser). Het is heel moeilijk hier rekening mee te houden tijdens het designen. Ook omdat elke browser weer anders is en sommige mensen toolbars van Google, AOL, StumbleUpon etc. etc. hebben.