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?

Usability zit niet alleen in het gebruik van valide code. Eerder gaat het om inlevingsvermogen in de eindgebruiker. En weten dat je niet kunt voorspellen hoe een gebruiker je website gaat gebruiken, hoe groot je empathie ook is. De gebruiker is altijd gekker of inventiever dan je je kunt voorstellen.

Dus zonder de claim volledig te zijn, hier mijn checklist, voor mei 2011. Een work in progress.

• Toegankelijkheid / Accessibility
  1. zo kort mogelijke response tijd van de website
  2. Tekst
     • voldoende contrast in tekst
     • Goede verhouding tussen lettergrootte en regelafstand
     • Is begijpelijk voor alle gebruikers. Vermijd onnodig jargon
  3. De site is te gebruiken zonder extra add-ons als flash. Basis-functionaliteit is niet afhankelijk van CSS / Javascript.
  4. Plaatjes hebben een beschrijvende ALT-attribuut, of komen uit CSS
  5. Er is voorzien in fallback opties voor flash, video’s of browsers die geen plaatjes tonen (zgn. gelaagd bouwen)
  6. De site is bruikbaar in alle gangbare browsers.
  7. Site heeft een bruikbare 404 not‐found pagina en heeft een bruikbare 500 script error pagina
• Herkenbaarheid / identiteit
  1. De site is herkenbaar. Bedrijfslogo is zichtbaar en herkenbaar
  2. Tagline / functionaliteit maken doel van site duidelijk
  3. de vormgeving is consistent toegepast
  4. Informatie over makers van de site is makkelijk bereikbaar
     • contact
     • feedback
     • disclaimer
     • sitemap
• Navigeerbaarheid
  1. Duidelijke hoofdnavigatie:
     • begrijpelijke en kernachtige labels in het navigatiemenu
     • Het aantal links in de hoofdnavigatie is overzichtelijk
     • Het bedrijfslogo is tevens een link naar de homepage
  2. Links zijn duidelijk herkenbaar (onderlijnd, of vet). Ook zijn de links herkenbaar voor kleurenblinden. Idealiter hebben links herkenbare en onderscheidbare states voor: unvisited, active, visited en hover.
  3. Bij contentrijke site: bruikbare sitesearch
  4. in bestelprocessen is duidelijk waar een gebruiker zich bevindt. De gebruiker kan terugnavigeren naar eerder bezochten stappen in het proces.
  5. URLs zijn betekenisvol, gebruiksvrienndelijk en onveranderlijk.
  6. Klikbare tekst en navigatieelementen zijn ook bruikbaar voor mensen met een motorisch beperking (Fitts’s law)
  7. Houdt de standaardfunctionaliteit van de browser in stand; houdt de ‘back’ button bruikbaar.
  8. Bij lightboxes:
     • bij het openen: zet de focus op het eerste element in de lightbox.
     • geef de gebruiker zoveel mogelijk de kans de lightbox zonder verlies aan informatie te sluiten.
  9. Maak de website geschikt voor navigatie via toetsenbord
• Leesbaarheid
  1. Tekstkopjes zijn beschrijvend, beknopt en begrijpelijk. Er is een inzichtelijke hiërarchie in de structuur van de tekstopbouw
  2. Belangrijke content is zoveel mogelijk direct zichtbaar (‘above the fold’, hoewel?)
  3. Stijlen en kleuren zijn consistent toegepast. Geen overmatig gebruik van cursief en vette tekst.
  4. Tekst en opmaak zijn gescheiden. Geen opmaak in de tekst met style-attributen.
  5. Advertenties & pop‐ups zijn niet hinderlijk aanwezig
  6. Alle content is beknopt en begrijpelijk
  7. HTML pagina titles via <title> zijn beschrijvend en relevant
  8. Afkortingen worden getoond met <abbr>
  9. Gebruik grammaticaal correcte als beschrijvende markup
  10. Gebruik <ul> en <ol> om lijsten weer te geven of definition lists.
• Formulieren
  1. Het doel van een formulier is makkelijk te begrijpen
  2. De velden zijn voorzien van duidelijke uitleg van doel, beperkingen en vereisten voor invoer
  3. De werking van formulieren is niet louter afhankelijk van client-side scripting. Alle uiteindelijke validatie gebeurt server side.
  4. Gebruik zoveel mogelijk vertrouwde formulierelementen. Wees terughoudend in het gebruik van CSS voor invoerlementen. En houd rekening met de verschillend tussen diverse browsers en besturingssystemen.
  5. In flows (bv bestelprocessen) kan de gebruiker terugnavigeren naar eerder bezochte pagina’s. Hierbij hoeft hij niet opnieuw gegevens in te voeren.
  6. Vermijd automatische doorverwijzing bij interactie met formulieren (webrichtlijnen)
  7. Laat bezoekers niet raden: geef informatie over hoe ze een gemaakte fout kunnen herstellen. Houd rekening met veelgemaakte fouten.
  8. Geef bezoekers een ‘vluchtroute’: mogelijkheden om verder te kunnen gaan als ze vastlopen. Vluchtroutes zijn onder andere behulpzame links, het kunnen gebruiken van de terug (back) knop, een zoekfunctie, of het onmiddellijk kunnen corrigeren van invoerfouten.
• Call to action:
  1. een call to action is herkenbaar
  2. en is begrijpelijk (percieved affordance)
• Per element, check op:
  1. klikbaarheid
  2. discoverability
  3. accidental activation

Voor een uitgebreidere en uitputtender lijst van criteria zie:

• webrichtlijnen, versie 2
• webrichtlijnen + testtool
• Normdocument Webrichtlijnen

"Search Patterns - Design for Discovery" (Peter Morville, Jeffery Callender)

Zoeken is niet moeilijk. Vinden is het probleem.

Search Patterns is een prettig boek als je meer wilt weten over zoeken op internet. Het geeft een goed beeld van de complexiteit achter ‘Best first’. Iedereen die webpagina’s bouwt (designer, architect, programmeur) zou dit boek moeten lezen. Elk van hen kan bijdragen aan betere zoekresultaten en een betere user experience.

De resultaatpagina van Google is al jaren dé toetssteen voor projecten op het gebied van zoeken. Het is wat mensen kennen en wat ze inmiddels ook verwachten. De overzichtelijkheid en effectiviteit van de Google Search Engine Result Page (SERP) is bedriegelijk. Want wat is ‘Best First’? Wat is “best”, wanneer is deze “best” het beste en voor wie dan? Dit soort vragen kun je niet eenduidig beantwoorden en dat doet dit boek ook niet. Deze vragen moet je jezelf stellen als je met zoeken en vinden bezig bent. Interessant ook is de wetenschap dat search & matching verder gaat dan alleen de resultaatpagina van Google. “Even when we browse, we search.” De intelligente suggesties van iTunes via Genius of de related products op Amazon zijn het resultaat van een zoekalgoritmes met als ingredienten de gebruiker, z’n geschiedenis, zijn zoekopdrachten, z’n verlanglijstjes etc.

Ik was eigenlijk het meest geïnteresseerd in de design patterns die Morville en Callender onderscheiden. Op Flickr staat illustratiemateriaal

• Autocomplete (autosuggest / autocorrect)
  Dit is het automatisch aanvullen van de zoekopdracht die de gebruiker invoert. Hiermee kun je zowel de gebruikers sneller helpen doordat hij mogelijk z’n zoektermen al ziet en je kunt spelfouten vroeg ondervangen.
  Google geeft bizarre suggesties bij sommige zoekopdrachten (vb: Google autocomplete 1, Google autocomplete 2, Google autocomplete 3)
• Best First:
  Open deur: gebruikers vertrouwen er op dat de eerste zoekresultaten de beste zijn. De eerste drie resultaten moeten de juiste zijn. In het gunstigste geval de resultaten op de eerste pagina. Om de gebruiker te verzekeren van de beste resultaten kun je handmatig nog resultaten toevoegen. Dat is de ‘Best Bet subpattern’. Voor de meestgebruikte zoekopdrachten kun je een lijst bijhouden met suggesties die getoond worden voorafgaand aan de overige zoekresultaten
  (voorbeeld op Flickr)
• Federated Search
  Dit is het ontsluiten van ongelijksoortige informatie uit verschillende bronnen (of collecties) via 1 enkele zoekopdracht. Dit gebeurt als je een gebruiker niet wilt lastig vallen met waar informatie vandaan komt. Dit is volgens mij minder een design pattern dan een gegeven voor de architectuur. Denk aan het zoeken in een bibliotheek in zowel tijdschriften- als de boekencollectie. Veelal kun je een gebruiker de keuze geven in welke  collectie gezocht moet worden en kan je het aanbieden onder de facetten (zie faceted navigation)
• Faceted Navigation
  Dit is het visueel aanbieden van filters om zoekresultaten te verkleinen of te verfijnen. Het toont de mogelijke karakteristieken die aanwezig zijn in een resultaatset waarop een gebruiker kan filteren of inzoomen. Het is een grafische weergave van booleaanse operators als AND of OR in zoekopdrachten
  (voorbeeld op Flickr, Nobel-prijswinnaars gepresenteerd met diverse facetten )
• Advanced Search
  Dit is een interessante want Morville en Callender zijn wat sceptisch over een aparte, uitgebreide zoekmogelijkheid. Vaak is een advanced search namelijk niet meer dan een groter aantal zoekvelden waarin op een ingewikkelder manier zoektermen wel of niet aan een zoekopdracht worden toegevoegd. Dat is leuk voor gebruikers die zelf al Booleaanse operators kunnen invoeren in het standaard zoekveld. Maar hun belangrijkste bezwaar is misschien wel dat de context waarin de gebruiker werkt vaak verloren gaat. Advanced search is een aparte pagina op een site waarin de voorafgaande browsegeschiedenis en context zijn weggevallen.
• Personalization
  Het aanpassen van zoekresultaten aan de gebruiker. Zo kun je bij mobiele zoekopdrachten de locatie van een gebruiker een rol geven. Of de zoek- of aankoopgeschiedenis van de gebruiker bepaalt mede welke andere producten getoond worden. Het moeilijkste hierin is relevant te zijn, maar niet te opdringerig en doorzichtig.” personalization is a dish best served simple. Only in limited contexts will past performance predict desired future results.”
• Pagination
  Het opdelen van de resultaatset in aparte blokken waartussen je kunt navigeren.
  Er valt nog veel te zeggen voor het gebruik van pagination, in plaats van het tegenwoordig reuzehippe “river of news” ofwel een endless scroll. Via pagination kun je makkelijker tussen blokken heen en weer navigeren en zijn blokken te bookmarken en dus deelbaar met andere gebruikers. Veel gebruikers zijn gewend aan pagination. Ook kost endless scroll meer om te implementeren.
• Structured Results
  Sommige zoekresultaten vragen om andere vormgeving. Het resultaat voor een straat + plaatsnaam wordt in Google bijvoorbeeld al via een kaart getoond. En wie via Google vraagt hoeveel 16.000 voet omgerekend in meters is, ziet het resultaat ook in een apart blok (zoeken: hoeveel is 16.000 voet in meters?)
• Actionable Results
  Dit is het aanbieden van zoekresultaten zodanig dat een gebruiker er direct mee aan slag kan. Bijvoorbeeld direct video afspelen of het direct kunnen printen van documenten zonder de het resultaatscherm te hoeven verlaten.
• Unified Discovery
  Ik weet niet of dit een apart pattern is. Hiermee bedoelen Morville en Callender het vervagen van de grenzen tussen browse en zoeken. Ik denk dat het een goede zaak is om bij de opzet van websites geen al te stricte scheiding aan te brengen tussen de twee.  Bied meerdere wegen aan om informatie tegen te komen; door gericht zoeken en door het lukraak aan te bieden. “For each search pattern, we should ask how it might relate to browse. Autocomplete and best first might automatically feature category matches. Personalized search may be informed by our current location and browsing history.”