Het ontwerptraject blijft het mooiste moment in het gehele ontwerpproces. Lekker vrij spelen met content en interactiepatronen op een oneindig canvas. Maar er komt een moment dat je de conceptfase moet afsluiten en de concepten/ontwerpen moet gaan documenteren voor overdracht. Iedere organisatie hanteert hiervoor zijn eigen voorkeur. De één wil een uitgebreide styleguide, de ander wil alleen beschijvingen bij de individuele schermen en soms is het een Agile-achtige aanpak waarbij je weinig documenteert en de ontwerpen samen met developers implementeert .
De uitdaging in het documenteren is ten eerste om in woord de rijke interactie van sommige elementen te beschrijven en ten tweede te voorkomen dat er ruimte is voor interpretatie. Daarnaast is het documenteren ook een belangrijk proces om je ontwerpkeuzes te valideren en eventuele inconsistenties in je ontwerp eruit te filteren.
Ik denk dat er een aantal belangrijke uitgangspunten zijn om de specificaties zo goed mogelijk te formuleren.
Uitgangspunten voor goede documentatie
Schrijf voor je doelgroep
Misschien een inkoppertje maar van wezenlijk belang. Houd de doelgroep goed voor ogen wanneer je de documentatie opschrijft en eventueel illustreert. Een ontwikkelaar die een interactiepatroon moet uitwerken zal hele andere informatie willen zien dan iemand van business die meer geïnteresseerd zal zijn in het achterliggende concept en uitgangspunten.
Maak het goed leesbaar
Zorg ervoor dat de lezer de tekst makkelijk kan scannen en kan doorzoeken. Op deze manier kan je het ook schrijven voor de diverse doelgroepen. Gebruik heldere koppen en werk met bulletlijsten.
Geef praktijkvoorbeelden
Omdat het vaak erg moeilijk is om in woord de rijke interactie te omschrijven is het van belang om goede praktijkvoorbeelden te geven.
Laat het controleren
Soms kan je je helemaal blind staren op je eigen ontwerp en documentatie. Laat het daarom de documentatie door je doelgroep en collega ID’ers nalezen.
Houd het bij!
Niet onbelangrijk, maar het wordt zo vaak vergeten. Begin al in een vroeg stadium ontwerpbeslissingen te documenteren en houd dit bij. Dit kan als input dienen voor je uiteindelijke documentatie en help bij het verantwoorden van je ontwerpkeuzes.
Hoe documenteer je een ontwerp
Als het ontwerptraject goed is verlopen zijn alle nodige dialogen ontworpen die zich binnen een (web)applicatie kunnen voordoen. Deze ontwerpen zal je moeten vertalen naar generieke patronen en schermen. In verschillende projecten heb ik ontwerpdocumentatie moeten opleveren. De gemene deler in al deze ontwerpspecificaties is het onderscheid tussen componenten en templates.
Templates
Templates zijn unieke en generieke schermen waarop de specifieke schermen zijn gebaseerd. Een template bevat alle nodige constanten, componenten en contentspecificaties om deze instanties te creëren. Denk bijvoorbeeld aan generieke informatiepagina’s of landingpagina’s voor een website. Maar ook een wizard binnen een webapplicatie bestaat uit een generieke constanten en vaste interactiepatronen. (Titel, stappenindicator, formulierlementen, knoppenbalk, etc).
Componenten
Een component is een verzameling van schermelementen en eventuele andere componenten die generiek zijn voor de (web)applicatie. Bijvoorbeeld een knoppenbalk onder een wizard of een voortgangsindicator is een component.
Een template voor het beschrijven van componenten
De manier waarop design patterns worden beschreven vind ik één van de meest complete manieren om een component te beschrijven. Hieronder volgt een template die ik hanteer voor het beschrijven van componenten.
- Probleem: Beschrijf hier wat precies het probleem is wat zich voordoet waarvoor dit component een oplossing is.
- Oplossing: Beschrijf wat de oplossing is voor het probleem. Plaats hierbij ook een afbeelding van het ontwerp.
- Rationale: Leg hier verantwoording af waarom je deze oplossing hebt gekozen.
- Hoe te gebruiken: Hoe kan het component gebruikt worden binnen de (web)applicatie
- Condities: Omschrijf alle condities die zich binnen het component kunnen voordoen, het liefst geïllustreerd met een afbeelding
- Default status: Wanneer van toepassing, wat is de default status van het component.
- Verplichte elementen: Beschrijf welke onderdelen van het component verplicht zijn om in te voeren of te wijzigen. Denk bijvoorbeeld aan variabele titels of content.
- Screenshots: Toon hier enekel screenshots van het component in de applicatie.
- Validaties: Wanneer er validaties van toepassing zijn, bijvoorbeeld bij formulier componenten dan kan je deze hier specificeren.
- Implementatie: Toon eventueel een voorbeeld van de implementatie van het component. B.v. van een codesnippet.
Alhoewel ik het totaal met je eens ben, en het een erg Dan Brown geïnspireerde approach lijkt. Vraag ik me af of er in het algemeen wel genoeg budget word aangeduid voor dit proces, en dat dit niet word gedaan lijkt erg in de hand van de interaction designer te liggen.
Ik vind het schrijven voor de programmeur nog niet zo zeer een probleem, maar vooral voor de Business zitten er vaak nog gaten in huidige methoden.
@bojhan: Ik denk niet dat het direct met budget te maken heeft. Het moet gewoon onderdeel zijnv an het gehele werkproces. Designers blijven visueel ingestelde mensen die graag ontwerpen en alles wat lijkt op het definiëren van het ontwerp benauwd ze.
Als je als Interaction Designer je aanleert om vanaf de eerste schetsen je overwegingen al te op te schrijven dan kan gedurende het ontwerpproces de specificatie ontstaan en dan hoeft het niet nog een project achteraf te zijn.
Wat Business is mijn ervaring dat ze graag de rationale achter het design wil weten. Maar daarvoor zijn ontwerpspecificaties denk ik ook niet voldoende. Voor deze doelgroep is een high fidelity prototype een veel betere manier om inzicht te krijgen in het eindresultaat.