Een tijdje geleden volgde ik bij Stephen Hay een workshop Rabid Prototyping. Sindsdien heb ik met de vraag rondgelopen wat je wanneer doet als je bezig bent met het ontwerp van een website:
- Hoe moet je naar mijn idee het design aanpakken in een nieuwe of bestaande website?
- Wat is het verschil tussen een prototype en een wireframe?
Tien jaar terug was het leven van een webdesigner echt een stuk makkelijker. Je maakte een paar schetsen, werkte ze uit in Photoshop en je was klaar met je design. Even de boel slicen, en het plamuur voor je webpagina was klaar. De webdesigner was een god die altijd gelijk had.
Anno 2011 moeten we niet meer uitgaan van de goede smaak en kennis van alleen Photoshop. De webdesigner van nu moet niet alleen goed zijn in pixeltjes mooi aan elkaar breien, maar moet ook alles weten van usability, CSS, HTML, browserverschillen en de verschillende apparaten die gebruikt worden om websites te bezoeken. Hij moet een duizendpoot zijn die alles weet. En klanten zijn veeleisender geworden; ook zij zitten dagelijks op internet en hebben een gefundeerde mening over wat voor hen een goede website is.
Webdesign is geen taak meer voor alleen coltruidragende designerbrillen. Webdesign is multidisciplinair.Niemand kan alles in z’n eentje, dus moet je samenwerken.
Hoe doe je dat dan? Hoe begin je vandaag de dag aan een nieuwe website? Wat mij betreft:
- schetsen
- wireframes
- mockups (onklikbaar en klikbaar)
- HTML prototype
- Realisatie
Daar wil ik graag alvast bij opmerken dat ik NIET meer geloof in een watervalmethode: niet eerst ALLE schetsen af voordat je aan wireframes begint, maar de onderdelen van de website kunnen parallel aan elkaar ontwikkeld worden. Niet pas aan een HTML-prototype beginnen als de complete mockup klaar is. Je kunt prima al een werkend prototype hebben van een homepage terwijl je nog aan het stoeien bent met bijvoorbeeld productpagina’s. Ik noem maar wat. Agile project managers, make some noise!
Teamwork
Ik wilde het over het design hebben. Idealiter bestaat je designteam uit:
- een Photoshopper met een onverbiddelijk goede smaak;
hij weet alles over kleur, spatiering, lettertypen en leesbaarheid. Hij mag best schetsen in InDesign als hij dat makkelijk vindt, maar verder is InDesign voor webdesign net zo nuttig als hamer en beitel voor een schilder. Iemand die accepteert dat webdesign niet hetzelfde is als print-design - een accessibility / usability expert.
Iemand die zich kan inleven in alle typen gebruikers van de website. Zijn ze laaggeletterd? Zijn ze kleurenblind? Zijn ze heel web-savvy? - een front-end goeroe.
Iemand die alles weet van CSS, HTML en bij voorkeur ook van JavaScript. Iemand die jou de verschillen kan uitleggen tussen browsers en wat ze wel en niet kunnen. Iemand die weet wat je bedoelt met gelaagd bouwen. - een back-end goeroe.
Iemand die vanaf het begin mee denkt hoe de front-end vertaald kan worden naar back-end functionaliteit - een tester:
iemand die elk aspect van een een website zelf kan testen of kan laten testen door een groepje dat bestaat uit de beoogde eindgebruikers. Meten is zweten. - een tekstschrijver
Iemand weet dat schrijven voor het web iets anders is dan een roman schrijven; die weet dat gebruikers teksten scannen, niet lezen. - een projectmanager die zich in kan leven in de diverse rollen hierboven.
Iemand die wel wat van de techniek snapt. Negen vrouwen kunnen niet in 1 maand een baby maken.
Maar laten we het eens over webdesign hebben.
Stap 1: Schetsen en doelstellingen
Schetsen met potlood op papier. Of met z’n allen rond een whiteboard. Hierin vertaal je op hoofdlijnen de wensen van de klant in concretere schetsen. Dit kan zowel een sitemap zijn als de eerste schetsen voor aparte paginatypen, bijvoorbeeld een homepage of een landingspagina. Mij is opgevallen dat we er vaak nog vanuit gaan dat elke gebruiker binnenkomt op de homepage van de website. Eh, neen. Dat is niet zo. Dat geldt voor mensen die je URL weten (de direct hits), maar niet noodzakelijkerwijs voor mensen die je contactgegevens Googelen. Of op trefwoorden die op andere pagina’s voorkomen.
Concrete resultaten:
- Een sitemap
- Afspraken over doelstellingen en denkrichtingen voor alternatieve layouts voor de verschillende platforms
- Schetsen of wilde plannen voor pagina’s. Of voor je app.
Stap 2: Wireframes
Hierin ga je met wat meer precisie bepalen wat de elementen op je pagina’s zijn. Met tooltjes als Mockingbird, Lucid Chart, (ETC) plaats je logo’s, soorten tekst en navigatie-elementen. Per type pagina. Vaak werk je hier ook de sitemap ietsje verder uit. Dit is het moment om je tekstschrijver goed mee te laten kijken (of je klant, als die zelf de teksten voor zijn rekenning neemt). Je kunt niet vroeg genoeg beginnen met zo concreet mogelijke teksten, want zo lang mogelijk alleen loremipsum gebruiken zal er later voor zorgen dat het design aangepast moet worden. Je tekstschrijver kan alvast beginnen met welke teksten er nodig zijn op de website, maar je hoeft hier nog geen concrete teksten te gebruiken.
Je kunt het wireframe in een document vastleggen met tekstuele beschrijvingen van de blokken en functionaliteiten per pagina.
Concrete resultaten:
- Een document met beschrijvingen van de functionaliteiten per pagina
- uitgebreide sitemap
- briefing voor de fotosjopper:
Stap 3: Mockups (klikbaar of niet klikbaar)
Je fotosjoppert heeft inmiddels al ideeën en schetsen gemaakt voor de opzet van pagina’s. Hij heeft de plaats bepaald voor menu’s, logo’s en tekstblokken. Vaste elementen die op elke pagina terug zullen komen zijn qua design al wat verder uitgewerkt. Je kunt je klant deze ontwerpen laten zien om te kijken of deze esthetisch en praktisch in de smaak vallen.
Met deze ontwerpen maken we een klikmodel van dat je zo uitgebreid als je wilt kunt maken. Je frontender kan snel met wat platte HTML-pagina’s een klikbaar geheel maken, zodat je door de eerste pagina’s kunt klikken. De site krijgt vorm en je kunt beginnen met nadenken over back-end functionaliteit: welk CMS, datamodel etc.
Concrete resultaten:
- Eerste designs vwb vaste elementen. Ook: plaatsbepaling van contentblokken
- Eerste opzet HTML-pagina’s: testbaar op diverse platforms (mobile, tablet, desktop, print)
- Bij erg uitgebreide sites: eerste scenario’s voor testen. Deze kun je laten testen door eindgebruikers
Stap 4: HTML prototype
Op basis van de definitieve ontwerpen maak je een prototype. Dit is een complete set met pagina’s (HTML, CSS, JavaScript) dat een goede representatie is van hoe de site er straks zal uitzien en hoe deze in de praktijk zal werken. Via test-scripts en interviews kun je gebruikers laten testen of de interface juist werkt. De HTML uit stap 3 vormde de basis voor deze pagina’s.
Idealiter gebruik je zo veel mogelijk echte content in deze fase, aangeleverd door je tekstschrijver.
Concrete resultaten:
- definitieve designs
- CSS, JavaScript, HTML
- testscenario’s
- teksten
Stap 5: realisatie
Je hebt inmiddels al goed uitgedacht hoe de back-end functionaliteit er uit moet komen zien. Dit is de fase dat je toewerkt naar een concreet eindresultaat. De werkzaamheden splits je zoveel mogelijk op naar behapbare, overzichtelijke blokken, i.e. een homepage, een reeks van formulieren.
Concrete resultaten:
- ingericht CMS of complete back-end code
- definitieve testscenario’s
Nog even over die klanten van tegenwoordig
Klanten zijn geen makke schapen meer aan wie je alleen maar Photoshop-bestanden hoeft te sturen. Even een open deur: klanten komen in soorten en maten. Er zijn klanten die uitstekend kunnen zien wat je bedoelt met schetsen. En er zijn klanten die alleen pagina’s snappen waar kleurtjes en logo’s al op aangebracht zijn. Het liefst laat ik klanten geen plaatjes meer zien, maar schetsen of klikbare webpagina’s die duidelijk maken dat het soort browser dat je gebruikt van invloed kan zijn op wat je uiteindelijk ziet.
Een klant die dit accepteert is de ideale klant.
geschreven voor Jeroen. Weet je nu wat je nodig hebt?