Hieronder de presentatie die ik gaf op de ‘Dag van de lokale website’ in 2010. Dat is al even geleden, maar het is frappant hoe actueel de tips nog steeds zijn.
Hoewel de voorbeelden gericht zijn op websites van lokale overheden (steden, gemeentes, provincies, …) zijn de tips bruikbaar voor elke website.
De 20 usability tips voor stedelijke en gemeentelijke websites
- Jouw mening is onbelangrijk. En zelfs een expert weet niet alles.
- Klant is koning dictator
- Begin elke dag met het mantra “Wij zijn niet het middelpunt van de wereld. De bezoeker is het middelpunt.”
- Geef het volk wat het volk vraagt (op basis van gebruikersonderzoek)
- Doe echt een grondig vooronderzoek. Checklists zijn rommel.
- Het gaat om de dienstverlening, niet om de dienst
- Weg met het e-loket
- Bouw je website menu op rond toptaken of thema’s (en niet rond je interne keuken)
- Focus op toptaken
- Zet je website op dieet
- Laat bezoekers geen doelgroep kiezen
- De homepage is een uitvalsbasis, geen krant
- Paginatype 1: keuzepagina’s
- Paginatype 2: detailpagina’s
- De rechterbalk is dood
- Pas op met lachende mensen (lees dit artikel over lachende mensen en dit artikel over kijkrichting)
- Stop met volzinnen te schrijven – gebruik opsommingen
- Wees altijd beleefd! (Neem dus geen voorbeeld aan deze foute foutmeldingen.)
- Doe 1 keer een gezamenlijk onderzoek
- Laat je bijstaan door AGConsult
Verwante presentatie
Later gaf ik ergens anders een lezing voor overheidswebsites. De inhoud is gelijkaardig (al staat ie meer op punt), de voorbeelden zijn anders en minder lokaal. Bekijk dus ook de 20 tips voor bruikbare overheidswebsites.
Wist je dat ook jij me kan inhuren als spreker over online marketing en usability?
Vinden jullie ook de website van Jabbeke een schoolvoorbeeld van een goede gemeentelijke website? Eentje waar we allen een voorbeeld aan moeten nemen? En wat is de waarde van de Indigov monitor?
Schoon gerief. Wat bedoel je precies met ‘Checklists zijn rommel’? Wat voor checklists? Het fenomijn lijkt me in deze context onbekend.
Dat je eigenlijk enkel keuzepagina’s en detailpagina’s hebt is een belangrijk inzicht.
Op http://www.klasse.be/ouders/ staat de rechterbalk overal identiek. Ik ga eens checken of er meer doorgeklikt wordt bij detailpagina’s dan bij keuzepagina’s. De content die er staat blijkt in het algemeen wel te werken, maar ik weet nu niet hoe of waar er meer geklikt wordt op die dingen.
Ik kan in elk geval bevestigen dat het maken van duidelijke keuzes (wat wel en niet tonen) enorm moeilijk is. Zelfs met gebruikerstests in de hand wordt er nog getwijfeld en gewikt en gewogen. En dan wordt er vaak gekozen voor de ‘zet alles er maar op’ oplossing. Het is pas na verloop van tijd dat die inzichten komen en dat mensen overtuigd geraken. Als ze zien dat een pagina met ‘maar’ vijf links weldegelijk beter werkt dan de telefoonboek van voorheen. Meten is weten.
@Wouter
– Jabbeke lijkt me geen toonvoorbeeld. Integendeel.
– Je hebt blijkbaar mijn presentatie niet ‘live’ bijgewoond. Bekijk tip 5 om mijn standpunt te kennen.
@Toon
Met checklists bedoelen we usability checklists of andere lijsten die je dan moet aanvinken of beantwoorden met ja of neen om te zien of je website goed is.
Zo’n checklists hebben heel vroeg in het designproces wel nut om te zorgen dat je geen al te grote flaters begaat. We raden aan iedereen die betrokken is bij het maken van websites om de do’s en don’ts van goede websites te kennen (zoals de artikels op deze blog).
Maar zoals we al eerder schreven: expertkennis alleen volstaat niet. Ik ken websites die voldoen aan alle usabilityregels, maar die toch waardeloos en onbruikbaar zijn. De hoofdoorzaak daarvan is vaak dat structuur en inhoud te wensen overlaten. 2 zaken die essentieel zijn voor het succes van een website, maar niet zomaar in een regel te vatten zijn.
Daarom ons basisadvies: doe gebruikerstesten. Werk met echte mensen. Leer je bezoekers en klanten door en door kennen. Want zo groeit je bedrijf 2 tot 3 keer sneller.
Ik vind die richtlijnen, checklists, heuristieken of regeltjes wel belangrijk, maar niet het belangrijkste.
Zoals je al zelf nuanceert hebben die echt wel een waarde tijdens de ontwikkeling van een concept of prototype.
Ene Gilb heeft eens gezegd: “Als we stellen dat fouten eruit halen tijdens de ontwerpfase 1 euro kost, dan kost diezelfde fout verbeteren tijdens de ontwikkelfase 10 euro en zelfs 100 euro na oplevering van het systeem.”
Mijn persoonlijke ervaringen wijken daar niet zo gek veel van af.
Heuristische evaluatie en expert reviews zijn snel en goedkoop uitgevoerd en toch kan je er best veel problemen met vinden.
Je kan met die checklists geen lastige of diepliggende usability problemen ontdekken, maar daarom zijn het geen onbelangrijke issues.
Bovendien door ze vroegtijdig te detecteren en op te lossen, moeten de gebruikers er geen aandacht meer aan schenken, aandacht die ze kunnen gebruiken voor andere dingen.
Ik vind het enorm waardevol om gebruikers te testen (liefst in hun eigen omgeving, met hun eigen materiaal, etc.), maar ik weet ook dat je op die manier ook weer niet alles kunt vinden.
@Edwin
Mee eens dat je problemen zo vroeg mogelijk moet opsporen, maar daar gaan de 20 tips absoluut niet over.
In die conceptfase kunnen checklists helpen. Al vind ik de bruikbare inhoud van checklists zo basic, dat ik blijf hopen dat ooit alle mensen betrokken in de concept- en ontwerpfase van een website die kennis hebben. Als je daarvoor al een usability expert nodig hebt, is het toch wel erg triestig. (Nu ja, het is op dit ogenblik nog nodig. Zo leert ons de realiteit.) Zodra de ‘regels’ wat specifieker worden, is er zo veel plaats voor context en interpretatie dat checklists zeer weinig waarde hebben.
Eens je een website hebt, zijn checklists puur tijdverlies. Ze zijn kunstmatig, missen overtuigingskracht en maken een einde aan afwijkingen en vondsten die plots voor die ene website wel blijken te werken.
Dat is onze ervaring na de analyse van meer dan 1.000 websites (yep, vaak alleen via expert review) en het volgen van meer dan 2.000 gebruikerstesten. 10 jaar geleden geloofde ik ook dat mijnheer de expert met zijn geweldige inzichten via de ‘heuristische methode’ (de term alleen al is verschrikkelijk) het wel eens beter ging maken. Verder kon ik er niet naast zitten.
Onze ervaring leert dat je al zeer vroeg tijdens de conceptfase gebruikers kunt inschakelen. Dat is niet zo duur en ingewikkeld als velen doen uitschijnen.
Niets komt nog maar in de buurt van de overtuigingskracht die gebruikerstesten hebben. Ik heb in het verleden vele uren en dagen verloren met het proberen overtuigen van klanten op basis van expertmeningen en artikels. En ik heb al heel vaak heel snel mensen kunnen overtuigen door gewoon even enkele uren te testen en filmpjes te maken. Dan worden adviezen snel aanvaard, zaken aangepast en hop met de geit. Als je die tijd mee incalculeert ben ik zeker dat in 80% van de gevaallen user testing efficiënter en vooral beter is dan expert reviews.
Usability experts die niet proberen in elke fase tot het uiterste te gaan om gebruikersonderzoek binnen het project te brengen, zouden zichzelf geen usability specialist mogen noemen.
Karl,
Dat is het hem juist, we stellen samen vast dat ze die basics niet toepassen. Zelfs een Apple of Microsoft, die de mensen, de competentie en het budget hebben, zondigen wel tegen een paar basis principes.
Je hebt op zich geen expert nodig om die richtlijnen na te kijken, maar een expert vindt er wel een pak meer. Bovendien kan die expert, wel rekening houden met de doelgroep, taak en omgeving.
Ik wil absoluut niet suggereren dat je testen met gebruikers kunt vervangen door expert reviews, integendeel. Maar ik ben er wel een voorstander van om ze naast elkaar te gebruiken en dit omwille van kosten/baten redenen.
Gebruikers testen kost wel wat, je hebt n aantal gebruikers nodig, je hebt minimum één evaluator nodig, soms nog een cameraman, daarna steek je misschien nog tijd in de montage, moeten er rapporten geschreven worden, etc…
Ik vind dat allemaal normaal, maar het is wel plezant dat je die kosten niet moet maken om basis zaken op te vangen. Dat het loont om mensen te testen, da’s overduidelijk. Code herschrijven is stukken duurder. En dan moet je nog verlies aan conversie, taak efficiëntie en tal van andere zaken erbij verrekenen.
Ik snap wel niet waarom je geen expert review zou kunnen doen van een afgewerkt product. Maar goed, ik zal je wel eens mailen, zou te ver off topic gaan. 🙂
@Edwin
Voor websites heb je geen cameraman nodig. Je hebt zelfs helemaal niets nodig, buiten eventeel een screen capture programma.
Via remote tools kan je zelfs gemakkelijk remote testing doen en opnemen, voor de prijs van 50 euro per maand voor de tool.
Dus je kost is quasi hetzelfde als bij een expert review: de kost van de persoon die de test doet en het rapport maakt. De enige extra kost is de vergoeding van de gebruikers (50 euro max. per persoon) + de tijd om die gebruikers te zoeken. Die minimale extra kost weegt nooit op tegen de gigantische voordelen.
Bij ons is de prijs van een diepgaande expert review amper 500 euro minder dan een user test met 5 personen.
Oh ja, vergeet nooit dat deze blog enkel over web gaat. Niet over software, niet over hardware. Enkel web. Zonder de webgebaseerde toepassingen dan nog. Dat is waar deze blog en onze ervaringen over gaan. Tenzij ik zaag over de iPad.
En wie weet zondigen Apple en Microsoft wel tegen de basisprincipes omdat ze tijdens gebruikerstesten zien dat het amper verschil maakt…
Karl,
Bij contextuele observaties, waar de gebruiker niet op zijn stoel blijft zitten (staat op om naar de printer te lopen of om een document uit een kast te nemen, etc…) wil ik, wanneer ik film gebruik, dat toch ook graag vastleggen. In zo’n geval ben je niet veel met je statische camera.
Ik zeg niet dat je voor elke website zo ver moet gaan, dat hangt immers van tal van parameters af. Kosten/baten dus.
Je kan die expert reviews ook informeel houden, niet te veel in documenten gieten, en dan zal de kost wel significant verschillen met gebruikerstesten. Ook hier moet je kosten/baten correct in schatten.
Gebruikers signaleren ook niet altijd alle problemen en door eerst een schifting te maken van de usual suspects verliezen je gebruikers geen tijd met zich daar over druk te maken en is er dus méér tijd om dingen op te pikken die je met expert reviews niet eens kunt detecteren.
Wat Microsoft en Apple betreft: dat kan zeker wat jij zegt, maar het is ook plausibel dat het ook maar mensen zijn en een foutje gemaakt hebben.
Waarom gebruikerstests (in mijn ervaring) niet altijd gebeuren, zelfs als iedereen het eens is over het nut:
* tijdsinvestering (voorbereiding, tijdens de test, planning, etc.)
* extra vertraging in het proces. Dat argument geldt trouwens voor nog dingen, zoals debugging of functioneel testen.
Het is dus niet uitzonderlijk dat iedereen die betrokken is bij een project het roerend eens is over het belang van fatsoenlijke gebruikerstests, en dat ze toch niet gebeuren. De deadline-fetish.
@Edwin
Contextuele observaties tijdens een user test zijn bij minstens 95% van de websites overkill. En als de gebruiker rechtstaat om in de oude papieren catalogus te gaan kijken, zal je dat ook wel zien…
Externe camera’s hebben vaak zo veel impact op het gedrag van de persoon, dat ik me heel vaak afvraag in hoeverre dat gedrag dan nog zijn natuurlijke gedrag is. Alvast een reden waardoor wij zelfs bij klanten die een usabilitylab hebben, verkiezen om niet van dat lab gebruik te maken bij testen. Wij zien zelfs het verschil tussen en de kleine camera die vroeger op onze laptop stond en de ingebouwde camera’s die we de laatste jaren gebruiken.
Context vang je voor de ‘zwaardere websites’ best op in het echte vooronderzoek. Voor wie daar budget voor heeft…
@Toon
Veel liever een shitty website die de (uit de duim gezogen) deadline haalt, dan een maand later een echt goede website lanceren.
Dàt verschijnsel zien we inderdaad oook vaak. En alle mensen die surfen en zich dagelijks de haren uit het hoofd rukken.
De echte oorzaak ligt natuurlijk in het feit dat niemand tijdens de planningfase ernstig rekening houdt met het feit dat ze gebruikerstesten willen houden. Als je dat inplant, komen er geen deadlines in gevaar.
Karel,
Is inderdaad niet nodig voor een typische website van een gemiddelde KMO. Als de website écht veel volk trekt (of moet halen) of ze is gelinieerd met een kritische taak dan vind ik het wel een must.
Camera’s hebben zeker invloed op het gedrag. Ik kan daar verhalen over vertellen. 🙂
Ik vind ook dat usabilitylabs wel een nut hebben, maar niet om gebruikers te onderzoeken.
En ze nemen inderdaad usability taken gewoon niet op in hun cyclus, als er al één hebben. *grijns*
Als ze dat wel zouden doen, dan zouden ze merken dat usability taken toepassen de development cyclus juist korter maakt. Er moet immers minder foute functionaliteit achteraf herschreven worden. Dat heeft zelfs invloed op de motivatie van de programmeurs. Het is niet fijn voor die jongens en meisjes wanneer ze voor de 3de keer of zo een stuk code in de vuilbak mogen smijten.
@Karl Deadlines zijn in veel gevallen overrated en eerder intern dan extern gestuurd. Geen enkele gebruiker zit te wachten op dé nieuwe site (of toch niet specifiek tegen datum X of Y). Ik heb het dan over interface, niet over tijdsgevoelige content.
Deadlines hangen vaak ook samen met de sector. 1 januari is een populaire, of 1 juni. In onderwijs is dat dan 1 september. De start van het nieuwe (mode-)seizoen, beurs X of Y, dat soort dingen.
De nadelen aan die standaarddeadlines zijn niet min. Er is tegen die data meestal vanalles te doen, de website (en zeker de ‘non-essentials’) hebben dan de neiging om uit de boot te vallen. De aandacht is sowieso verdeeld. Qua publiciteit is het ook moeilijk opboksen tegen allerlei andere dingen in die periode(s). En voor de klant is een nieuwe/vernieuwde (buggy) site ook niet ideaal in een drukke periode.
Ik ben zelf een grote fan van soft-launches in een rustige periode, gevolgd door een soort ‘oh, one more thing’ aankondiging een tijd later, als de site er al staat en nog wat gefinetuned en gestoffeerd is. Online zijn complete redesigns trouwens zelden een goed idee, geleidelijke verbeteringen/aanpassingen werken beter. Grootse deadlines hebben dan weinig betekenis. Ik heb het dan over de gebruikservaring, de achterliggende technologie kan je vaak niet zo gradueel upgraden en moet je soms omgooien. En daar zitten soms wel deadlines aan vast qua support en veiligheid.
Ik heb de rechterbalk van http://www.klasse.be/ouders/ eens onderzocht qua Analytics en blijkt dat de post-its daar wel aangeklikt worden vanop detailpagina’s, met name pagina’s met thematisch gelijkaardige content. Ook wel van de overzichtspagina’s en de homepage, maar die laatste heeft ook een pak meer bezoekers dus dat zorgt voor een onevenwicht (geen idee hoe ik die statistiek in GA proportioneel kan krijgen, trouwens)
@Toon
Helemaal eens met je verhaal over deadlines.
Rechterbalk
– Soms zijn er inderdaad uitzonderingen. Ik geef in mijn presentatie voorbeeld van Gent waar het niet werkte, bij de Stad Antwerpen werkte het per uitzondering wel. Verleden week een user test en daar heeft niemand de rechterbalk gebruikt.
– Bij jullie valt die balk designmatig wel goed op, en dat helpt uiteraard. Zerker die post-its. Heel goed gevonden!
– Meestal werkt het niet, maar zoals we zeggen: test, want checklists zijn rommel 🙂
– Weet je hoeveel mensen procentueel op de rechterbalk klikken en hoeveel op de links onder het artikel?
@Karl
Niet meteen cijfers over die procentuele verschillen. Valt ook niet correct te berekenen, nu. We kunnen wel zien vanop welke pagina iemand op een artikel terechtkomt, maar niet of ‘ie daarvoor een link onderaan of een post-it heeft gebruikt. En dat is net het interessantste verschil.
Maar nu je ‘t zegt, bedenk ik wel dat heel wat ‘kliks’ op die post-it ook van de links onderaan kunnen komen, dat valt gewoon niet op te delen. We weten uit ervaring in elk geval dat dit soort ‘related links’ onderaan een artikel vrij goed werken als ze kloppen en het duidelijk is wat die links zijn. Ik ga proberen van die apart te tracken zonder dubbele urls te creëren.
Alweer iets wat met een usertest van tien gebruikers eenvoudiger uit te vissen valt 😉