Categorieën
geekiness usability web design

Van wireframe naar realisatie

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:

  1. schetsen
  2. wireframes
  3. mockups (onklikbaar en klikbaar)
  4. HTML prototype
  5. 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?

4 reacties op “Van wireframe naar realisatie”

Dit is statisch design, je gaat hier aan allerlei mogelijkheden voorbij die het web tegenwoordig biedt. Door met stills te beginnen krijg je dit niet lekker in je ontwerp, als het er al in komt is het gevaar groot dat het effectjes achteraf zijn ipv een wezenlijk onderdeel van je design.
Denk er eens over om parallel een werkende HTML-demo en papieren versie te maken, elk kan iets aan je ontwerp toevoegen wat de ander niet kan.

Dan heb ik het blijkbaar niet goed opgeschreven.
Juist in de schetsfase moet je al nadenken over interactiviteit. Ik haat stills, maar in een schetsfase zijn ze handig.
Zo snel mogelijk met een bewegende HTML-versie beginnen, zou ik zeggen.

Ik ben het eens met Victor. Een “goede photoshopper” is niet genoeg. Je hebt iemand nodig die erg goed is met UX. Dat kan natuurlijk de vormgever zelf zijn. Maar met een plat photoshopdocumentje kom je er tegenwoordig niet.

Verder denk ik dat het werken aan het functioneel ontwerp een aparte stap is. Alleen al om aan te geven hoeveel tijd de verschillende onderdelen kosten.

Neen, mijn hele idee is juist dat we af moeten van platte photoshopdocumentjes. Wat ik dan ook versta onder een goede fotosjopper is:
iemand die smaak heeft
iemand die ALLES weet van interactie
iemand die fantasie en voorstellingsvermogen heeft

En dus niet een pixelschuiver die alleen goed is met kleurtjes. Als ik even mag chargeren.
(dank je wel, Edwin)

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.