De internationale Web Content Accessibility Guidelines (WCAG) 2.0 zijn opgesteld door het World Wide Web Consortium (W3C) en omvatten een groot aantal aanbevelingen om webcontent toegankelijker te maken. Velen kennen de vorige versie van deze richtlijnen al omdat die onderdeel uitmaken van de Webrichtlijnen van de overheid. Het volgen van deze richtlijnen zal content niet alleen toegankelijker maken voor mensen met functiebeperkingen en senioren, maar ook voor gebruikers in het algemeen. Door toepassing van de richtlijnen worden websites ook beter bereikbaar, beschikbaar, bruikbaar en betrouwbaar voor bezoekers, browsers, zoekmachines en zelfs mobiele telefoons.

De beoordelingsperiode van de Nederlandse vertaling start vandaag en duurt 30 dagen. In december 2009 zal de definitieve versie klaar zijn voor gebruik. Iedereen kan reageren. Beoordelaars kunnen opmerkingen maken over de juistheid van de  concept vertaling. Het is niet mogelijk om inhoudelijke opmerkingen te verwerken. Opmerkingen over de vertaling kunt u sturen naar public-auth-trans-nl@w3.org.

Voor de volledigheid:

• Locaties: Originele versie, Nederlanse vertaling
• De voor deze beoordeling gepubliceerde versie is niet de definitieve versie en kan niet herplaatst worden. De vertaling volgt de officiële vertaalprocedure van het World Wide Web Consortium (W3C) voor  geautoriseerde vertalingen.
• Om lid te worden van de mailinglijst, stuurt u een mail naar public-auth-trans-nl-request@w3.org met “subscribe” als onderwerp. Het archief van deze mailinglijst is openbaar.
• Voor een overzicht van de deelnemende organisaties en voor meer informatie kunt u terecht op de website van stichting Accessibility: http://www.accessibility.nl/WCAG20/WCAG20.htm.

Zie ook: WCAG 2.0: Eindelijk de nieuwe toegankelijkheidsnormen.

Dit artikel is ook gepubliceerd op Frankwatching.

ai! amsterdam: protest tegen regelzucht

Rogier van Kralingen en Quincy James zijn in protest gegaan tegen de stomme regeltjes van hun gemeente, Amsterdam. Blijkbaar mag er in de hoofdstad – die toch bekend staat als een van de meest vrije steden ter wereld – een heleboel niet. Bijvoorbeeld: staand een biertje drinken op een terras, een bankje voor je huis, filmen in de stad, menukaarten op de buitenmuur van restaurants en ijssalons in kinderrijke gebieden.

De gemeente gaat volgens de heren zelfs zo ver dat inspecteurs bij horeca-gelegenheden in auto’s posten om overtredingen te kunnen spotten. “Ze willen dat Amsterdam een creatieve stad is, maar ze verbieden dingen die ons creatief maken”, aldus Van Kralingen. Waarom? Vermoedelijk omdat Amsterdam op de UNESCO werelderfgoedlijst wil komen. “Maar aan ons wordt niets gevraagd.”

Dus kwamen Van Kralingen en James in actie en toverden de Amsterdam-campagne ‘i amsterdam’ om in de social media campagne ‘ai! Amsterdam‘. Hierin wilden ze zo veel mogelijk volgers te krijgen door middel van flyers, raamposters, ‘word of mouth’, Twitter, Facebook, Hyves, e-mail, bellen en natuurlijk een website. Dit resulteerde uiteindelijk in een grote (staande) protestborrel op de Noordermarkt.

Job Cohen en gemeente waren not amused en spanden een rechtszaak aan. Waarop de campagnenaam werd veranderd in ‘ai! [love] amsterdam’. Over de verdere plannen zwegen de heren, maar dat ze plannen hebben, is zeker. Ze zijn in ieder geval blij met hun behaalde succes (aandacht en aangesloten netwerk) en noemen het social media offensief een ‘shortcut to democracy’. Hun lessen:

• Een stad is heel klein. Als je een paar vrienden belt, en die hun vrienden, enz… heb je al snel een groot bereik.
• De pers leidt niet, die volgen. (“we hebben geen enkel persbericht verstuurd”)
• Het medium is minder belangrijk dan de boodschap.
• Mensen beheersen het internet, niet merken of politieke partijen. (Nuance uit het publiek: “People are not in control, but IDEAS that spread.”)
• Sociale media zijn erg krachtig.
• Just do it!

De zaal was minder overtuigd (zie Twitter-stream). Kenmerkende opmerkingen: “Typisch Geenstijl: schoppen zonder oplossingen” en “Shortcut to democracy, maar geen samenwerking met de politiek gezocht”. Aan de andere kant: staand drinken mag weer.

Wat men wel opmerkelijk vond, is dat er in Amsterdam twee keer zoveel Facebook- als Hyves-leden lijken te zijn.

Digitale pioniers

Hierna was het podium aan een aantal ‘digitale pioniers’, startup projecten die in 3 minuten hun idee mochten pitchen.

Polidocs (Maarten Marx) en Ik regeer (Manfred Zielinksi) maken parlementaire informatie (kamerstukken en kamervragen) beter toegankelijk. PoliDocs voegt automatisch structuur toe aan de documenten waardoor je bijvoorbeeld kunt zien welke persoon, van welke partij, wanneer, wat zegt over welk onderwerp. Ik regeer plaatst alle Kamervragen op Twitter, biedt allerhande RSS-feeds aan en een API.

OCO-sterren (Tamar van Gelder), een vergelijkingssite voor scholen, is een project van OCO (Onderwijs Consumenten Organisatie). Ouders en leerlingen kunnen hun school beoordelen (1-5 sterren) op een aantal criteria en zo ontstaan ratings per school. OCO heeft dit proactief aangepakt: het is inmiddels al bij 50% van de basisscholen en 60% van de middelbare scholen in Amsterdam langs gegaan om ter plaatse ratings te verzamelen.

Hoeveel basisscholen hebben 4 sterren? (groene sterren)

Het nieuwe stemmen (Stef van Grieken) beleefde met zijn eerste project – Primaries.nl – een onverwacht succes. Primaries.nl was een protestactie tegen de besloten selectie van lijsttrekkers. Twintigduizend mensen stemden per SMS op Rutte of Verdonk als VVD-lijsttrekker. Inmiddels heeft Het nieuwe stemmen met een zestal projecten (o.a. Wiekiesjij) al 3 miljoen bezoekers getrokken en nodigt het developers uit gebruik te maken van de ontwikkelde API.

Verbeterdebuurt (Carl Lens, CreativeCrowds) wil graag de betrokkenheid van mensen bij hun buurt vergroten. Naar het voorbeeld van Fixmystreet kunnen mensen ideeën en problemen in hun buurt markeren op een kaart. Problemen worden meteen doorgestuurd naar de gemeente, ideeën worden doorgestuurd bij minimaal 10 stemmen. Veel gemeenten doen al mee. Verbeterdebuurt hoopt op zoveel mogelijk websites ingebed te worden. En… ze doen ook al aan augmented reality op basis van Layar. Verbeterdebuurt werd overigens al eerder gespot en geïnterviewd door Frankwatching.

Democatiespel (petities.nl) is de Kieswijzer als adventuregame. Samen op quest gaan en duels uitvechten met woorden (voor, tegen, anders, nl). Daarmee is het ook een strategy game. Je kunt net als politici kiezen uit verschillende strategieën, bijvoorbeeld:

Het spel is duidelijk nog niet af, maar er is - uiteraard - al wel een API waarmee developers zich kunnen uitleven. Erg leuk bedacht!

Een slimmere overheid

Na de pauze was het woord aan Lee Bryant, mede-oprichter van Headshift, een toonaangevend social business adviesbureau uit Engeland. Hij deelde zijn ervaringen met eParticipatie en open data in de UK.

Bryant constateert dat we anno 2009 nog steeds politieke structuren uit de twintigste eeuw hebben. Politici zien burgers als publiek om naar te zenden, niet om mee te debatteren. Zelfs Obama’s ‘we’ is (sinds de inauguratie) in praktijk nog meer retoriek dan realiteit. De verschuiving van oude, vermoeide debatten naar samen problemen aanpakken, gaat langzaam.

Een slimme overheid is groter (qua inclusiviteit) maar kleiner (qua bureaucratie). Er moeten minder besluiten genomen worden binnen de ‘firewall’ van de overheid. We worden namelijk ook geconfronteerd met problemen die overheden niet alleen kunnen oplossen (bv. milieu en gezondheidszorg), die geworteld zitten in netwerken, die gefragmenteerd zijn, bij bepaalde groepen spelen, enzovoorts. En terwijl we meer verwachten van publieke diensten, moeten zij het met minder geld doen.

Wat hebben we geleerd van het social web?

1. (simpele acties * schaal) ^ aggregatie = potentieel machtig netwerkeffect.
2. De kosten voor groepsvorming en samenwerking nemen voortdurend af.
3. Feedback is een krachtig middel voor verbetering (door zichtbaar kritiek gaan organisaties eerder actie ondernemen).

eParticipatie is nodig en nuttig. Maar als we de informatie niet hebben, dan kunnen we de overheid niet goed helpen. Anders gezegd: als we geen open data hebben, zijn we niet voldoende geïnformeerd om goed te kunnen participeren. Bryant pleit dus voor meer transparantie, participatie en zelfredzaamheid.

En zijn gelukkig al voorbeelden van open data en participatie, bv. Data.gov in de USA en het Open Data Project in de UK, maar ook initiatieven als Social Innovation Camp en 4IP die laten zien hoe mensen gezamenlijk sociale problemen oplossen en publieke diensten helpen verbeteren. Bryant stelt dat 10% van de overheids ICT-budgetten beschikbaar gesteld moet worden als sociaal innovatiefonds dat kleinere spelers (bv. communities) in staat stelt aan hetzelfde probleem te werken. “Participation and open data projects should be leading the mainstream, not relegated to the periphery.”

Overigens zijn er ook kritische geluiden over participatie en transparantie:

• Is transparantie heilig? “Transparantie is de nieuwe objectiviteit” (als genoeg mensen vinden dat iets A is, dan is het A) – David Weinberger. En: “More info does not always produce markets that are more efficient. People can ignore it, misunderstand it or misuse it.” – Fung, Graham & Weil
• Kan de burger lang genoeg zijn aandacht erbij houden? “To understand something – an essay, an argument, a proof of innocence -  requires a certain amount of attention.” – Larry Lessig
• Moeten we grenzen stellen aan participatie? Wie willen we niet laten participeren? Extreem rechts bijvoorbeeld? Hoe gaan we hiermee om?

Tot slot geeft Bryant 4 focusgebieden aan voor een social business design methodologie:

1. Ecosysteem: developernetwerken die spelen met open data, distributienetwerken en een kritieke hoeveelheid ‘vrienden’ om een project van de grond te krijgen;
2. Co-design:  Zorgen dat gebruikers betrokken zijn in iedere ontwerpstap.
3. Signalen en data flows: hoe beweegt informatie / data door netwerken en hoe attenderen we anderen op relevante en belangrijke informatie?
4. Filters: Meer data vergt betere filters om er chocola van te kunnen maken.

Meer lezen:  Bryant’s eigen samenvatting en slides van de presentatie.

My Society

Tom Steiner is mede-oprichter van mySociety, een open source organisatie die een aantal bekende democratiewebsites in de UK runt, zoals FixMyStreet, WhatDoTheyKnow en TheyWorkForYou.

FixMyStreet is een aantrekkelijke service voor burgers. Je kunt snel en eenvoudig lokale problemen aangeven en bediscussiëren zonder er actief werk van hoeven te maken bij je lokale overheid. Ongeveer de helft van de gemelde problemen wordt door gemeenten opgepakt en opgelost. De helft dus ook niet. Als probleem niet wordt gefixt, dan geeft de site aan wie de lokale verantwoordelijke politici zijn, zodat je er zelf alsnog werk van kunt maken. FixMyStreet is een mooi voorbeeld van sociale druk door transparantie: publiekelijk zichtbare lokale problemen zijn genant voor gemeenten en dwingen daarmee af dat ze opgelost worden.

WhatDoTheyKnow speelt in op de Britse Freedom of Information wet (vergelijk de Nederlandse Wet Openbaarheid Bestuur). De website stelt burgers in staat eenvoudig vragen aan de overheid te stellen en te zien. Bij wet is de overheid verplicht te antwoorden. Dit maakt Freedom of Information (FOI) een krachtig instrument (je kunt het bv. gebruiken om argumenten in een campagne te ondersteunen). Maar is de keerzijde niet dat we de overheid duurder maken door ze van alles te vragen en ze door FOI te dwingen overal op te antwoorden?

TheyWorkForYou is mySociety’s populairste site, die burgers veel informatie geeft over hun politici, bv. wat ze gezegd hebben in debatten, hoe ze gestemd hebben, welke vragen ze gesteld hebben en welke antwoorden ze daarop gekregen hebben. Gebruikers kunnen reacties achterlaten en linken naar individuele speeches.

Dit zijn 3 voorbeelden van het transparant maken van de overheid c.q. democratie. En hiervoor is open data nodig. Maar let op: open data is niet synoniem voor transparantie. Een overheid kan heel goed zijn in het polijsten van datasets, zonder echt transparant te zijn. En alle overheidsorganen zomaar alle data openbaar laten maken, is volgens Steiner ook niet het antwoord. Sommige instanties spenderen dan miljoenen aan open datasets waar niemand naar kijkt, terwijl instanties met populaire data niet extra gemotiveerd worden om hun data goed aan te bieden. Een beter idee is een website waarop mensen kunnen aangeven aan welke dataset ze behoefte hebben en waarom.

Tot slot richt Steiner zich tot de overheidsmensen: Waarom zou je werk moeten maken van open data?

1. Burgers raken steeds meer gewend aan het krijgen van meer en betere informatie. Je kunt niet achterblijven bij de publieke verwachting.
2. Je werkt voor hen.

Op de Usability Week 2009 afgelopen mei vertelde Garrett Goldfield welke afwegingen je moet maken bij het kiezen van navigatiecomponenten voor je website. Hierbij zijn tips – en een aantal van mij – voor het ontwerpen van de globale en lokale sitenavigatie.

Wat is globale en lokale navigatie?

Kort gezegd is de globale navigatie het hoofdmenu van een website. Je kunt ermee naar de hoofdonderdelen van de website navigeren. Als het goed is, kun je de globale navigatie op iedere pagina, op dezelfde plaats terugvinden. Zo kun je vanaf iedere willekeurige pagina altijd direct naar alle hoofdonderdelen toe.

De globale navigatie van Rijkswaterstaat

De lokale navigatie is de navigatie binnen een hoofdonderdeel, vaak submenu genoemd. Vaak geeft de lokale navigatie toegang tot pagina’s op meerdere niveaus.

De lokale navigatie van Rijkswaterstaat

Nieuwe bezoekers van een website zijn meestal eerst gefixeerd op de globale navigatie. Zodra ze een beetje gewend zijn aan de site en de globale navigatie, gaan ze meer focussen op de lokale navigatie. Het is dus belangrijk aan beide aandacht te besteden.

Selectie-facetten voor een navigatiesysteem

Waarover moet je als ontwerper nadenken als het gaat om website navigatie? Natuurlijk de structuur en labeling, oftewel de informatiearchitectuur. Maar ik wil nu vooral ingaan op het interactieontwerp van een navigatiesysteem. We komen dagelijks diverse navigatievormen tegen op alle websites die we gebruiken: een menubalk, uitklapmenu, ‘mega-dropdown’, accordion, tagcloud, enzovoorts. Maar hoe bepaal je welke het meest geschikt is voor de website waar je aan werkt?

Goldfield noemt 3 zaken waar je op moet letten bij de keuze voor een navigatieoplossing: plaatsing, weergavestijl en interactie.

Plaatsing

Bestaat er een ideale plaatsing voor globale en lokale navigatie? In zekere zin wel. Mensen raken snel gewend aan bepaalde conventies. Bijvoorbeeld dat het logo altijd linksbovenaan de pagina staat, dat de metanavigatie (’Contact’, ‘Sitemap’, e.d.) en de zoekfunctie meestal rechtsbovenin staan, en dat banners vaak aan de rechterkant staan.

Globale navigatie verwacht men over het algemeen als horizontale menubalk bovenin, of als verticaal menu aan de linkerkant. Lokale navigatie wordt door de meeste mensen aan de linkerkant verwacht. Dit blijkt volgens Goldfield uit eyetracking studies.

Ideale plaatsing van navigatiecomponenten, gebaseerd op eyetracking studies

Of de rechterbalk ‘ideaal’ is voor contextuele navigatie (zoals de afbeelding suggereert), mag je vraagtekens bij plaatsen. In veel usability tests, ook in mijn eigen ervaring, wordt content in de rechterbalk vaak slecht opgemerkt.

Betekent het ‘ideaalplaatje’ dat je navigatie nooit rechts of onderaan mag plaatsen? Nee, onder bepaalde voorwaarden kan navigatie rechts of onderin best werken. Een menu aan de rechterkant zal wel pas opvallen als er aan de linkerkant geen menu staat (zie bv. dit blog), of als de linkernavigatie zichtbaar ondergeschikt is (bv. filters) aan het menu rechts. Een hoofdmenu aan de onderkant kan werken als de pagina’s geheel op het scherm passen (en er dus niet gescrolld hoeft te worden).

Universiteit Leiden heeft de lokale navigatie aan de rechterkant

Navigatie onderaan die steeds gebruikelijker wordt, zijn bijvoorbeeld metanavigatie en (globale) sitemaps. Bekende voorbeelden hiervan zijn Apple en Amazon.

De footer van Apple bevat contextuele navigatie (in dit geval m.b.t. iPhone)

Weergavestijl

Wat zijn de sterkten en zwakten van een bepaalde weergavestijl? Laten we eens kijken naar een viertal stijlen: 2 conventionele - het horizontale en het verticale menu – en 2 specifiekere – de accordeon en de carroussel/filmstrip.

Horizontaal menu

Gewoon een rij hyperlinks, weergegeven als knoppen, tabs, of gewoon als links. Plaatsing: bijna altijd bovenin de pagina.

Rabobank gebruikt een horizontale menubalk

Verticaal menu

Zelfde als het horizontale menu, alleen met de links onder elkaar, en meestal weergegeven als hyperlinks (al dan niet gescheiden door streepjes), niet als knoppen of tabs.

Het verticale menu van stichting Drempelvrij.nl

Accordeon

Bij een accordeon-stijl menu schuift het item uit als je er met de muis op gaat staan. Beweeg je de muis naar het volgende item, dan klapt dat item uit en het vorige weer in. Vandaar de naam accordeon.

De Amerikaanse Commonwealth Connector gebruikt een accordeon voor de doelgroepingangen.

Carrousel of Filmstrip

Stel je wilt een rij items presenteren, maar je wilt er meer tonen dan waarvoor ruimte is op de pagina. Dan is een carrousel of filmstrip wellicht een goede oplossing. De bezoeker kan dan naar links en rechts bewegen in de rij om de andere items te bekijken. Het enige verschil tussen de carrousel en de filmstip is dat de carrousel rond is (dus geen begin en einde heeft) en de filmstrip een lange strook is. Sommige carrousels draaien automatisch al langzaam rond.

Bij Disney draait een carrousel rond met Disney-karakters

Apple gebruikt een filmstrip om zijn producten te etaleren.

Een bekend soort carrousel/filmstrip is de ‘coverflow’.

Interactie

Over navigatie-interactie kun je hele boeken schrijven. Sterker nog: die zijn ook geschreven. Voor het doel van nu – laten zien dat je keuzes voor navigatieoplossingen bewust moet maken – beperk ik me even tot enkele menu-gedragingen op het niveau van de globale navigatie, te weten:

• Klikken op tab/link opent overzichtpagina;
• Bewegen over tab opent subnavigatie;
• Klikken op tab/link opent subnavigatie;
• Het ‘Mega drop-down’ menu.

Klikken op tab/link opent (overzichts)pagina

De meest basic vorm van navigatiemenu’s bevat de meest vertrouwde en verwachte interactie. Je klikt op een tab (die mogelijk gewoon als link wordt gepresenteerd) en komt daarmee op een (overzichts)pagina. Het menu-item gedraagt zich dus als een gewone hyperlink.

Bij Rijkswaterstaat opent iedere hoofdtab gewoon een pagina.

Bewegen over tab opent subnavigatie

Ook een veelgebruikte vorm van navigeren. Je beweegt de muis over een tab, waardoor direct een submenu naast of onder de tab verschijnt. Je kunt klikken op het hoofditem, maar ook direct op een item in het submenu waarmee je het topniveau overslaat. Klik je niet en beweeg je de muis van de tab en het submenu af, dan verdwijnt het submenu weer.

Het ‘drop-down’ menu van de TU Delft

Bij De Hypotheker verschijnt het submenu onder het hoofdmenu. Risico hiervan is het ‘diagonale probleem’, maar positief aan deze uitvoering is dat het submenu blijft staan als je met je muis weggaat van het menu.

Klikken op tab/link opent subnavigatie

Je ziet deze interactievorm niet zo vaak als de twee voorgaande. De menu-tabs bevatten een submenu, die niet tevoorschijn komen als je er met de muis overheen beweegt, maar pas als je erop klikt. In de horizontale variant verschijnt het submenu in een horizontale balk onder het hoofdmenu. In de verticale variant schuift het hoofdmenu meestal open tussen het aangeklikte item en het item eronder, om ruimte te maken voor de subnavigatie.

Het submenu van ABN AMRO verschijnt pas als je een van de hoofditems aanklikt.

Mega drop-down

Een navigatievorm in opkomst is de zogenaamde ‘mega drop-down’. Jakob Nielsen heeft er al een uitgebreid, aanprijzend artikel over geschreven. Een mega drop-down menu is in principe gewoon een uitklapmenu (‘drop-down’ betekent hier ‘uitklap’) met extra mogelijkheden: meerdere kolommen, plaatjes en ‘rijke’ links (bv. nieuws- of productitems).

Philips benut zijn mega dropdowns ten volste. Minder gebruikelijk aan deze uitvoering is het moeten aanklikken van het hoofditem om het dropdown menu te kunnen zien.

Hier nog een aantal voorbeelden van mega drop-down menu’s.

Tot slot

Er zijn natuurlijk nog meer navigatieoplossingen die je kunt overwegen voor de globale of lokale navigatie, bv. een tagcloud of facetnavigatie (filteren op tag/categorie). Voor alle oplossingen geldt: denk na over plaatsing, weergavestijl en interactie. Welke oplossing past het best bij de site, de content en de doelgroep?

Google vindt het genoeg geweest met Internet Explorer 6 (IE6). Het kondigt aan de ondersteuning van de verguisde browser op YouTube binnenkort op te heffen en adviseert IE6-gebruikers te upgraden naar een moderne browser, zoals Internet Explorer 8, Firefox 3.5 of Chrome. Ik zag de mededeling gisteren bij een klant voor het eerst, maar blijkbaar loopt de aankondiging al sinds juli.

Ook Facebook geeft upgrade-suggesties aan IE6-gebruikers.

De campagne om IE6 kwijt te raken is al even aan de gang, maar als YouTube en Facebook - ’s werelds nr. 3 & 4 populairste sites - de stekker uit IE6 trekken, dan zou het weleens snel echt afgelopen kunnen zijn met de browser, die overigens nog steeds door Microsoft ondersteund wordt. En dat zou goed nieuws zijn voor veel front-end ontwikkelaars. Zij hebben allang massaal afscheid genomen van de browser.

Andere grote spelers die IE6 laten vallen: Digg en 37signals.
Vergeet ik er nog een paar?

Doelgroepgericht zijn: kwaliteit en valkuil

De wens voor doelgroepingangen is eenvoudig te verklaren. De meeste activiteiten van een organisatie zijn gericht op specifieke doelgroepen: van producten en diensten tot marketing- / communicatiestrategieën en -activiteiten. Er zijn ook genoeg organisaties die divisies of afdelingen naar doelgroep hebben ingericht. Het concentreren van mensen en activiteiten rond doelgroepen is een manier voor organisaties om hun doelgroepen beter te kunnen bedienen (meer focus, concentratie van marktkennis) of  misschien wel om het voor zichzelf overzichtelijker te maken. Doelgroepgericht denken en werken is belangrijk voor veel organisaties. Je moet de kenmerken, percepties en behoeften van de doelgroep kennen om te slagen met je product, dienst of boodschap.

De valkuil bij doelgroepgericht denken en werken is het ervan uitgaan dat de doelgroepen jouw referentiekader delen.

Voorbeeld 1: Een gereedschapmerk wil zijn aanbod van boorhamers zo goed mogelijk afstemmen op de klantbehoeften. Dus ontwikkelt het 5 soorten boorhamers; een goedkope recht-toe-recht-aan voor de onervaren en sporadische klusser, een lichtgewicht model voor vrouwen, één met meer vermogen en standen voor de regelmatige amateurklusser, een nog uitgebreidere met extra accu voor de echte doe-het-zelver, en een extra zware kwaliteit voor de vakman. De koper zelf staat er helemaal niet bij stil in hoeverre zijn behoefte anders is ten opzichte van anderen. De koper is taakgericht; hij heeft een klus te klaren. Hij zoekt een boorhamer; eentje die sterker is dan zijn vorige, die hij jaren intensief kan gebruiken, maar niet te duur is. Natuurlijk vergelijkt de koper de 5 modellen met elkaar. Niet omdat hij zich afvraagt welke de leverancier voor hem bedoeld had, maar omdat hij degene wil met de (voor hem) beste prijs/kwaliteit-verhouding.

Voorbeeld 2: Een alumnus komt niet naar de website van zijn oude universiteit om gewoon eens te kijken wat de universiteit nog te vertellen heeft aan alumni. Er is een aanleiding voor zijn bezoek: hij heeft de universiteit nodig voor onderzoek, hij heeft gehoord over een interessante lezing of hij kreeg een brief waarin werd gevraagd of hij als alumnus mentor wil zijn voor studenten.

Dezelfde valkuil zie je bij organisatiegericht denken. Mensen die willen weten hoe het zit met invoerbelasting op internetaankopen of op spullen in de vakantiebagage, kunnen lang tevergeefs zoeken op belastingdienst.nl. De site bevat een categorie ‘Buitenland’, maar daar staat het niet. Terwijl het toch echt gaat om belastingen en buitenland. Om de informatie te vinden, moet je beseffen dat deze belastingen vallen onder de Douane, en dat de Douane niet de grensbewaking doet (dat is de Marechaussee), maar onderdeel is van de Belastingdienst.

“Ik ben” vs “Ik ben op zoek naar”

Doelgroepingangen sluiten niet aan bij de taak die bezoekers voor ogen hebben.

Zoals gezegd denken doelgroepen taakgericht. Bijna altijd komen bezoekers met een bepaalde vraag of taak naar een website. Ze zijn op zoek naar iets. En dat iets - de zoekvraag - hebben ze in hun hoofd al verwoord. Soms heel concreet, soms heel globaal. De zoekvraag roept associaties op; je mag ze ook tags of triggerwords noemen.

Komen bezoekers op de homepage binnen, scannen ze snel de pagina op navigatielabels die overeenkomen met de zoekvraag of de associaties. Levert dit niet direct een ‘hit’ op, dan gaan ze beter naar de aangeboden navigatielabels kijken of typen hun zoekvraag of tags in de zoekfunctie. Komen ze dieper in de site binnen, dan bestaat er een goede kans dat ze hun zoekvraag al aan Google gesteld hebben.

Zoekvragen en tags worden door internetters bijna nooit geformuleerd als doelgroep. Wie statistieken bijhoudt van zoekopdrachten naar en op zijn website, kan dit snel nagaan. Mensen zoeken niet naar zichzelf, maar naar onderwerpen (bv. Michael Jackson), taken (bv. adreswijziging) of levensmomenten (bv. trouwen).

Wie ben ik?

Doelgroepingangen dwingen mensen na te denken in welke hoedanigheid zij de site willen bekijken of in welke doelgroep zij denken dat de site-eigenaar hen heeft geplaatst.

Eind 2007 had OHRA deze homepage:

bekijk volledige homepage

Deze homepage bevatte twee soorten doelgroepingangen. Het meest in het oog springt natuurlijk het blok met de 6 gezichten, met daaronder een navigatielijst met exact dezelfde doelgroeplabels nog een keer. En helemaal bovenaan de pagina staan de knoppen “Particulier” en “Zakelijk”.

Welke ingang kiest:

• Jeroen (27 jaar, getrouwd met Els en net vader geworden): “Jonge ouders” of “Gezinnen”?
• Manon (21 jaar, woont samen met Martijn, studeert): “Student” of “Duo”?
• Lisa (25 jaar, alleenstaande moeder van een 2-jarig kind, studeert): “Student”, “Singles”, “Jonge ouders” of “Gezinnen”?

In het geval van de OHRA homepage zullen er legio mensen zijn die zich tot meer dan één van de gepresenteerde doelgroepen rekenen. Gevolg: mensen worden onzeker in hun keuze. Ze gaan twijfelen welke ingang de beste is: wanneer is de verzekering gunstiger, als student of als jonge ouder? Dus gaan ze alle relevante ingangen uitproberen en de informatie nauwkeurig vergelijken. En hoe meer passende ingangen, hoe groter de twijfel. Dat was wellicht niet de bedoeling van OHRA.

Het is moeilijk doelgroepingangen zo in te delen dat het voor bezoekers ondubbelzinnig duidelijk is welke ingang (het snelst) naar hun doel leidt.

Andersom kan ook het geval zijn. Als mensen die zich nergens mee kunnen identificeren, is het kiezen van een ingang misschien nog wel moeilijker dan voor mensen die in meerdere categorieën vallen.

De Universiteit van Amsterdam heeft een 100% doelgroepnavigatie. Maar welke ingang kiezen de bezoekers die geen studiekiezer, student, medewerker of alumnus zijn? Bijvoorbeeld pers, ouders of decanen.

Redundantie 

Een doelgroepindeling levert vaak redundantie op.

Het groeperen van het informatieaanbod per doelgroep lijkt handiger voor de organisatie, omdat:

• de verantwoordelijke afdeling / redacteur alle pagina’s die hij beheert dicht bij elkaar heeft in plaats van versnipperd over de website;
• de informatie per doelgroep helemaal op maat kan worden gemaakt, inclusief ‘tone of voice’;
• de organisatie goed kan aantonen dat het aan iedere doelgroep aandacht besteedt.

In de praktijk zie ik vaak dat een groot deel van de informatie over een bepaald onderwerp nagenoeg hetzelfde is voor alle doelgroepen. Lichte variaties in inhoud en taal, maar veel van hetzelfde. Dit betekent dus dat er bv. 3 versies bestaan van dezelfde pagina, op 3 plaatsen in de sitestructuur. Als de informatie aangepast moet worden, dan moeten er dus ook 3 teksten worden aangepast in plaats van 1. Ervaring leert dat hierdoor af en toe pagina’s met verouderde informatie ontstaan, omdat sommige pagina’s vergeten worden aan te passen. Dit kan het volgende tot gevolg hebben:

• Als de bezoeker Google of de interne zoekfunctie gebruikt, dan kan hij gemakkelijk op de verkeerde doelgroepsite terecht komen zonder dat hij het doorheeft. Hier zien we in praktijk dat veel mensen op webpagina’s en in zoekresultaten vooral letten op de titel en globale tekst, maar nauwelijks op de context waarin de pagina zich bevindt (bv. URL, actieve menu-item).
• Als de informatie per doelgroep enigszins verschilt, en de bezoeker komt de ene keer via route A en de volgende keer via route B, kan het zijn dat hij de tweede keer op een andere plek uitkomt. Tijdens usability tests zien we soms dat mensen dan aan de paginatitel herkennen dat ze goed zitten, maar ze kunnen het tekstje niet terugvinden dat ze de eerste keer hadden gelezen.

En afgezien van de mogelijke gevolgen voor de bezoeker, levert redundantie ook gewoon meer werk op voor de redactie.

Dieper

Bij doelgroepingangen komt alle informatie een laag dieper te zitten.

Eigenlijk heeft een doelgroepingang voor de bezoeker hetzelfde effect als een splashpage: het kost een extra handeling om bij de content te komen. Onder een doelgroeplaag hangt namelijk meestal gewoon weer een thematische indeling om de informatie te organiseren. Dus tenzij de doelgroepkeuze echt noodzakelijk is, is het beter om meteen te werken met een thematische of taakgerichte hoofdindeling.

Volledig?

Het is moeilijk om te bepalen of de contentselectie per doelgroep volledig is.

Bij een usability test twee jaar geleden vroegen we vooraf wat mensen zouden vinden van een doelgroepingang. Enkele gebruikers gaven wel aan dat ze een doelgroepingang, met daarin informatie op maat (over hun situatie) als prettig zouden ervaren, vanwege het gevoel van volledigheid.

Als je een doelgroepindeling gebruikt naast een (bv.) thematische indeling, en die moeten gelijkwaardig zijn, dan moet je op beide dimensies goed bedenken of je volledig bent. De bezoeker moet via beide routes dezelfde informatie kunnen vinden. Maar heb je echt alle informatie op de doelgroepsite gezet waarin de doelgroep geïnteresseerd is? En hoe kom je daar achter? Hoe weet je dat men ook niet geïnteresseerd is in bepaalde content die je onder een andere doelgroep hebt ondergebracht? Echt volledig zijn is moeilijk.

Overigens hebben we in bovengenoemde usability test de respondenten een homepage voorgelegd met zowel een thematische als een doelgroepnavigatie, met bij iedere categorie links naar pagina’s op het onderliggende niveau. Het verschil tussen de twee soorten ingangen was overduidelijk: de respondenten focusten zich op de inhoud. Ze gebruikten niet de doelgroepingangen, tenzij daar toevallig linkjes bij stonden die voldeden aan hun informatiebehoefte op dat moment.

Wanneer wel doelgroepingangen?

Een veelgebruikte doelgroepindeling is “Particulier” en “Zakelijk”. Deze indeling is vaak goed te verdedigen, al kleeft hier ook een nadeel aan: veel freelancers vinden het moeilijk te bepalen of ze tot particulier of tot zakelijk gerekend worden. Daarom kies ik zelf liever voor “Privé” en “Zakelijk”, omdat dit wat taakgerichter is. Het is dus stiekem ook niet echt een doelgroepingang meer.

Wanneer moet je doelgroepingangen overwegen? Een paar hints:

• Als de meerderheid van de content op de website exclusief voor individuele doelgroepen bestemd is;
• Als cardsorting onderzoek uitwijst dat verreweg de meeste gebruikers de informatie indelen in doelgroepen;
• Als gebruikers tijdens usability tests opmerkingen maken als “zo veel van deze informatie is niet relevant voor mij”.

En als je ze gebruikt, zorg dan dat:

• de doelgroepingangen zo ingericht zijn dat mensen niet hoeven te worstelen met de vraag tot welke van de aangeboden doelgroepen zij behoren;
• je goed onderzoekt welke content iedere doelgroep relevant vindt, zodat er geen interessante content verstopt zit achter andere doelgroepen.

1. Neem de rol aan van product owner

Belangrijk is de rol die de User Experience professional inneemt in het project. Jeff Patton adviseert: “Als UX professional neem je in de rol van product owner verantwoordelijkheid voor business goals. Product owners werken in het verleden, het heden en de toekomst. Ontwikkelteams werken enkel aan de huidige iteratie en zijn daarnaast hooguit bezig de vorige release te repareren.”

De product owner vervult veel rollen:

• Advocaat van de business: Begrijpt de behoefte van de opdrachtgever en selecteert een mix van features die zijn doelen helpt bereiken.
• Advocaat van de klant: Begrijpt de behoefte van de organisatie die het product koopt en selecteert een mix van features die waardevol voor hem zijn.
• Advocaat van de gebruiker: Kan vanuit de gebruiker uitleggen waarom het product wel of niet voor hem werkt, enaangeven hoe hij het product wel wil kunnen gebruiken.
• Materiedeskundige: Beantwoordt technische vragen over het ‘domein’ (o.a. gebruik, gebruiker, organisatie, markt) aan degenen die het product maken.
• Ontwerper: Voegt business-, klant- en gebruikersbehoeften samen in een productontwerp dat voor iedereen bevredigend is. Bewaakt coherentie terwijl het product wordt gemaakt en uitgebreid.
• Communicator: Is in staat om de visie achter en de bedoeling van het product te communiceren, daarmee helpen feature- en ontwerpbeslissingen te nemen.
• Besluitnemer: Neemt bij conflicterende doelen, belangen en/of meningen, moeilijke productbeslissingen.

2. Word een ontwerpfacilitator

“Design isn’t something that designers produce, design is a process that designers facilitate.”

Leah Buley (Adaptive Path)

Idealiter denkt iedereen in je agile team mee over ontwerp. Faciliteer het team daarin. Gebruik bijvoorbeeld workshops om:

• informatie te verzamelen en te analyseren;
• ontwerpideeën te vormen;
• anderen te betrekken in het ontwerpproces;
• onderzoek en kennis te delen.

“Design by community is not design by committee.”

Leisa Reichelt (Disambiguity)

Samenwerken in ontwerp betekent niet dat dat jij niet meer verantwoordelijk bent voor het ontwerp. Gebruik je team, klanten en gebruikers om informatie en inzichten te verzamelen en te betrekken in besluitvorming. Sommige beslissingen neem je als team, andere neem jij als ontwerper en product owner.

3. Onderzoek, modelleer en ontwerp vooraf, maar niet teveel

Ook in agile (Scrum) projecten is er een stap die altijd voor de iteratieve ‘sprints’ komt: het definiëren van het product backlog. Het product backlog is de ‘master’ lijst van alle gewenste functionaliteiten in het product. Bij de start van een agile project wordt niet verwacht al een uitputtende lijst te kunnen maken. Agile gaat immers uit van voortschrijdend inzicht. Er wordt dan ook niet heel veel tijd in gestoken. Meestal worden de meest voor de hand liggende dingen opgeschreven, wat vaak al meer dan genoeg is voor de eerste sprint.

Dat neemt niet weg dat het maken van het product backlog een fase op zich is, waar goed aandacht aan besteed moet worden. Dit is een ideaal moment om wat user research te doen en businessdoelen vast te stellen. Probeer ook een globaal beeld te vormen over de interactie die jij bij het product en de gebruikers vindt passen. Gebruik dit allemaal vervolgens bij het schrijven van de gebruikerscenario’s (user stories).

Denk ook alvast na hoe je in de rest van het project om wilt gaan met user / usability research.

4. Hak je ontwerpwerk in brokken…

…maar voorkom dat ontwerptijd in het gedrang komt. Dit kun je doen door ontwerpintensieve iteraties af te wisselen met ontwikkelintensieve iteraties.

Voor contentgedreven websites is dit een stuk lastiger dan voor de meeste applicaties. In applicaties zijn functionaliteiten vaak te relateren aan specifieke acties (knoppen, menu-items) en daardoor goed te isoleren. Bij veel websites dragen vaak veel pagina’s direct of indirect bij aan de conversie. Een gemiddelde contentpagina is een puzzelstukje in meerdere scenario’s. Hoe hak je dus het interactieontwerp van een website op in brokken? Een aanpak die ik zelf onlangs gebruikt heb, is beginnen met de basis bouwstenen van een site (structuur, navigatie en generieke functionaliteiten), en daarna pas één voor één onderdelen als home, nieuws, project uitwerken. Risico hierbij blijft natuurlijk dat je eilandjes ontwerpt in plaats van een coherente user experience, zoals ik in mijn eerste artikel al aangaf.

Patton adviseert: organiseer de user stories in een schema, beperk je niet tot alleen prioriseren. Een schema helpt het grote plaatje te blijven zien.

5. Werk parallel aan de huidige iteratie vooruit aan de volgende en evalueer/test de vorige

bron: Case Study of Customer Input For a Successful Product, Lynn Miller

Bovenstaande afbeelding vat het mooi samen: in iteratie X, test iteratie X-1, ontwerp iteratie X+1 en doe alvast user research voor iteratie X+2.

6. Maak prototypes simpeler (’low fidelity’) naarmate de samenwerking met ontwikkelaars intensiveert

Eigen ervaring: als je samenwerkt met een nieuwe outsourcing partij ergens in India of Jordanië, dan moet het functioneel ontwerp exact laten zien en beschrijven wat er gebouwd moet worden. Wat er staat, wordt letterlijk genomen enwat er niet staat, wordt niet opgepakt. Omgekeerd is het wellicht overbodig om in detail te modelleren en beschrijven hoe een bepaald component zich moet gedragen als je naast de developer zit en continu overlegt over features.

7. Gebruik prototypes / wireframes voor discussie in plaats van specificatie

“Use wireframes as communication space, not as blueprints.”

Jeff Patton

Er gaat snel veel werk zitten in het schrijven van een functioneel ontwerp. Maar hoe lang na oplevering c.q. live-gang blijft het FO een goede blueprint? Sterker nog, hoe vaak worden er niet al tijdens de bouw- of stabilisatiefase van het project functionele wijzigingen aangebracht, die niet meer bijgewerkt worden in het FO?

Een agile suggestie: Schets de interface, hang het aan de muur en bediscussieer het met het team. Laat ze vragen stellen, notities maken en zelf annotaties toevoegen aan de schetsen. Zo krijgen ze precies de specs die ze nodig hebben en omdat ze het zelf (in hun eigen woorden) opgeschreven hebben, begrijpen ze de specs waarschijnlijk ook beter.

Uitdaging voor de projectmanager en klant: “Beoordeel het ontwerp niet op de documentatie, maar op het gevolgde proces.”

Sommige agile interactieontwerpers documenteren nog wel de historie van ontwerpbeslissingen, voor zichzelf of andere/volgende interactieontwerpers.

8. Organiseer continu user research in een eigen spoor, los van development

Als vervolg op punt 3: Er was niet genoeg tijd om al het user research te doen voordat development begon. Je hebt vast ook niet voldoende tijd per iteratie om de alle benodigde research voor de user story te doen. Misschien is het dus beter om user research zijn eigen tempo te laten volgen. Plan vaste (wekelijkse?) momenten in om user research te doen voor nog uit te werken functionaliteiten.

Het liefst werk je, ook tijdens de vaste momenten, met een groep gebruikers. Creëer een pool die groot genoeg is om niet iedere week met dezelfde gebruikers te hoeven zitten. Daarmee houd je gebruikersfeedback vanuit een frisse blik. Plan mensen wel ruim van tevoren in, zodat ze weten wanneer iets van ze verwacht wordt.

9. Combineer meerdere doelen als je met gebruikers zit

Je kunt de pool gebruiken voor zowel user research (vooraf) als usability testing (achteraf). Sterker nog: je hebt al niet veel tijd om je gebruikers te betrekken. Benut je tijd met gebruikers dus zo goed mogelijk door in dezelfde sessie:

• Informatiebehoefte- en taakanalyse te doen;
• Feedback te krijgen op ontwerpen in wording;
• Feedback te krijgen op het werkende product (afgeronde sprints).

10. Test en optimaliseer de user interface ‘ultra’ iteratief

Hier heb ik zelf erg goede ervaringen mee. Voor mij is tijd met gebruikers meestal ook erg schaars. Sterker nog, ik zie ze in veel projecten alleen maar bij cardsorting of het testen van een ‘paper’ prototype. Waarbij paper tegenwoordig bij mij meestal een klikbaar prototype (gegenereerd door Axure) is. Deze usability tests duren vaak maar 1 dag, of soms twee keer een halve dag met een dag ertussen. Als na 2 testsessies evident is dat iets niet werkt, dan pas ik het ter plekke aan en compileer het op tijd voor de derde testsessie.

Ik vind het belangrijker om aan het einde van de dag een ontwerp te hebben waar tussentijds al belangrijke verbeteringen zijn doorgevoerd, maar dat zelf misschien alleen nog maar door de laatste 2 gebruikers getest is, dan een onderzoeksrapport waar keurig in staat hoeveel procent van de gebruikers tegen welk knelpunt aangelopen zijn.

Valkuil

Als laatste tip een kleine waarschuwing. Als je erg gericht bent op vooruit kijken en iteratief ontwerpen, is het gemakkelijk om in deze valkuil te lopen: de evaluatiefase per cyclus overslaan. Inclusief usability testing. ‘Geen tijd’ is een slecht excuus. Als je alleen focust op zo snel mogelijk alles ontwerpen en bouwen, als je backlog niet verandert, dan ben je niet met agile, maar met waterval bezig.

Chris Smissaert (Min BZK) licht toe: “Het doel van de Webrichtlijnen bij het opstellen was om alle overheidsinformatie goed toegankelijk te maken. Niet alleen voor kwetsbare groepen, maar ook voor alle verschillende computers, telefoons en dergelijke, én voor hergebruik. De gebruiker van overheidsinformatie kan eisen stellen aan het gemak, de snelheid, de flexibiliteit en de gemeenschappelijkheid ervan.” En door Web 2.0 te omarmen, wil BZK innovatie (e-participatie en open data) stimuleren.

De eerste resultaten hiervan zijn een vijftal widgets, die Tam Tam met Alper Çugun (Aardverschuiving) voor BZK ontwikkeld heeft, en de prijsvraag “Dat zou handig zijn”. Deze prijsvraag luidt: “Welke slimme toepassingen van de overheid zouden handig zijn voor de samenleving?” Goed om anderen deze vraag te stellen, want – zo stelt Alper: “Het is voor overheidsorganisaties onmogelijk om alle gebruik van data te voorzien en in te voorzien.” Door open data en API’s beschikbaar te stellen, stel je iedereen in de gelegenheid ermee aan de slag te gaan.

Widgets

De vijf gemaakte widgets waren onder meer bedoeld om (onder meer de overheid zelf) te laten zien dat open overheidsinformatie op nieuwe manieren gebruikt en hergebruikt kan worden. Dit zijn ze:

• Zoekdienst Bekendmakingen
  Kijk snel en eenvoudig wat er in de buurt aan vergunningen en andere bekendmakingen zijn gepubliceerd.
• Rijksoverheidvideo’s
  Video’s zoals gepubliceerd door de Rijksoverheid op Regering.nl
• Waarschuwingen van de VWA
  De meest recente waarschuwingen van de Voedsel en Warenauthoriteit
• Agenda van Werken bij de Overheid
  Agenda widget met daarin de aankomende evenementen van Werken bij de Overheid
• Vacatures van Werken bij de Overheid
  De vacatures van Werken bij de Overheid

Moeten widgets voldoen aan de Webrichtlijnen? Op dit moment voldoen ze in ieder geval nog niet, omdat ze op websites in een iframe geladen worden. De nieuwe versie van de Webrichtlijnen zou hiervoor dus iframes moeten toestaan. Verder wordt er gediscussieerd over de toegankelijkheid van de widget. Moet de informatie in de widget zelf per se toegankelijk zijn? De data komt immers van een website, waar de informatie als het goed is al goed toegankelijk is. Is het niet voldoende om gebruikers voor wie de widget-presentatie (door bv. JavaScript of visuele weergave) niet optimaal werkt, door te verwijzen naar een website waar de broninformatie staat? Is een widget niet ‘extra’? De meningen zijn hierover verdeeld.

De geest van de Webrichtlijnen

Alper Çugun geeft een prikkelende presentatie, getiteld De geest van de Webrichtlijnen.

Voor het bouwen van de 5 widgets heeft hij gekozen voor het OpenSocial platform, omdat:

• OpenSocial het grootste open platform is (iGoogle),
• Het de beste syndicatiemogelijkheden biedt,
• Er nu ook een hele goede mobiele versie van iGoogle is.

Er zitten echter ook wat nadelen aan:

• De eerder genoemde iframes,
• Geen page loads: alles wordt dynamisch opgebouwd met scripts. “Progressive enhancement heeft dus eigenlijk geen zin.”
• Geen DOCTYPE’s mogelijk in widgets, waarschijnlijk vanwege het inline gebruik van widgets. Gevolg: in Internet Explorer 6 zijn de widgets ‘stuk’.

Ondanks de nadelen vindt Alper OpenSocial beter dan de andere platformen, zoals Netvibes.

Over de Webrichtlijnen heeft Alper een prikkelende mening. Alper vindt dat veel mensen te rigide met de Webrichtlijnen omgaan. Hij is zelf een voorstander van pragmatiek en gezond verstand. “De Webrichtlijnen zijn goed om naar een beter Web te komen, maar er zijn betere dingen te doen dan je op alle micro-optimalisaties te richten, zoals goed ontwerp en heldere teksten. Maar is dat minder nauwkeurig toetsbaar”. Hij pleit voor een minder rigide naleving van alle 125 Webrichtlijnen en citeert Douglas Bader (RAF-piloot tijdens WOII): “Rules are for the guidance of wise men and the obedience of fools”. 

Ikzelf onderschrijf Alpers boodschap van harte. Ik denk dat bijvoorbeeld begrijpelijke taal en goede (natuurlijk wel geteste ) usability meer invloed heeft op de kwaliteit van een website dan het netjes coderen van alle afkortingen en korte taalwisselingen in de content of het ombouwen van een zoekfunctie om daar ook vriendelijke url’s te krijgen.

Belangrijkste issues

Bart Hilhorst (Tappan) inventariseert onder het publiek de belangrijkste issues van Web 2.0 in relatie tot de Webrichtlijnen en kijkt samen met de aanwezigen of er snelle antwoorden voor zijn.

N.B. Ik ben geen echte techneut, dus het kan zijn dat ik sommige punten niet helemaal juist weergeef. Ik hoor het graag als dit het geval is.

Routebeschrijving uitbreiden met Google Maps (zodat gebruiker eigen vertrekpunt kan opgeven).
Helaas is de Google Maps code niet Webrichtlijnen-compliant.Google Maps embedden gebeurt (bijna?) altijd met een iframe, dat is dus nu nog een probleem. Misschien dat je hier omheen kunt werken als je de API gebruikt. Roel van Houten (Viziris): “De ‘basis routebeschrijving’ vanaf bepaalde nabije punten naar de organisatie is de verantwoordelijkheid van de organisatie. Het aanbieden van een routebeschrijving van je eigen adres is extra, dus hoeft in principe niet toegankelijk te zijn. Je kunt als organisatie hiervoor ook linken naar een online reisplanner.” Als dit zo werkt, kan de Google Maps toevoeging dan genegeerd worden bij toetsing of blijft de suboptimale code een punt waarop afgekeurd kan worden?

Kunst in een met Flash gecreëerde sfeer op een site presenteren
Het standaard uitgangspunt is: “In principe moet een gehandicapte kunnen doen wat anderen ook kunnen” (Roel van Houten). Maar hoe beschrijf je bijvoorbeeld muziek aan een dove? Of een abstract schilderij aan een blinde? Ik kan me goed voorstellen dat voor bepaalde belevingen geen gelijkwaardig tekstequivalent te maken valt. Moet je het dan toch proberen, omdat het nu eenmaal een toetsingcriterium is? Goede vraag…

Sommige nieuwe technologieën (HTML5, ARIA) en bepaalde API’s  niet bruikbaar volgens Webrichtlijnen
Bepaalde technieken als Canvas en SVG embedded conflicteren met de Webrichtlijnen. De volgende versie van de Webrichtlijnen, waarin WCAG 2 wordt verwerkt, biedt wel ruimte aan nieuwe technologieën.

User generated content (bv. video)
Voor een organisatie kan het een enorme klus worden om door bezoekers geuploade videoclips te ondertitelen en te voorzien van een audiobeschrijving. De verantwoordelijk neerleggen bij de bezoeker zelf is ook geen optie: de drempel wordt dan voor veel mensen te hoog om video’s in te zenden. Is het uit de scope te halen (conform Caesura richtlijnen) als zijnde geen ‘key scenario’? Of kun je je erop beroepen dat je geen verantwoordelijkheid kunt nemen voor content door anderen gecreëerd? Volgens Koen Willems zou dit laatste niet opgaan.

Webstats tellers in de broncode
De meeste webstatistiekpakketten maken geen gebruik van ECMA-script voor de code snippets die je in de broncode van je pagina’s moet plaatsen om gedetailleerdere webstatistieken te krijgen. En dat levert een conflict op met de Webrichtlijnen. Scripts van Google Analytics kun je overigens wel zelf herschrijven.

Webrichtlijnen-conforme chatfuncties
Bestaat er chatsoftware voor op websites die voldoen aan de Webrichtlijnen? In de zaal is er niemand met een concrete oplossing.

Dynamisch wisselende content (bv. live nieuwste Twitter-berichten)
Je kunt proberen ARIA hiervoor te gebruiken. Je kunt een verversknop aanbieden bij geen JavaScript. In bepaalde gevallen kan het misschien zelfs gewoon buiten de scope getrokken worden.

Inlezen externe content
Met XML / RSS moet dit geen probleem opleveren.

Plugins met inline styles/script
Veel populaire open source platformen zoals WordPress ondersteunen plugins, die in principe iedereen kan schrijven en gebruiken. Veel plugins bevatten inline styles/scripts omdat ze rijke functionaliteiten bieden en moeten kunnen functioneren zonder dat de gebruiker dingen hoeft aan te passen aan het platform. Misschien kun je “zelf een betere maken”, zoals sommigen tijdens de barcamp suggereren, maar of dat een werkbare oplossing is?

Rich interfaces: drag/drop, rechtermuistoets
In bepaalde rich internet applications (RIA) wordt gebruik gemaakt van bijzondere handelingen zoals drag & drop en contextmenu’s (keuzemenu’s die met de rechtermuistoets worden opgeroepen). Door gelaagd te bouwen zouden deze functies ook toegankelijk en conform Webrichtlijnen aangeboden moeten kunnen worden.

Conclusies?

Op zich lijkt een aantal zorgen met betrekking tot Web 2.0 en Webrichtlijnen inderdaad ongegrond. Met goed gelaagd bouwen kom je vaak al een heel eind, maar er zijn toch een aantal mogelijke hindernissen met de huidige Webrichtlijnen. Concrete technische hindernissen zijn bv. iframes voor widgets, maar wat minder concreet zijn ‘Web 2.0 features’ op websites waarvan het misschien lastig te bepalen is of die deel uitmaken van de key scenario’s van de website (en dus moeten voldoen) of ‘extra’ zijn, waardoor ze mogelijk uitgescoped mogen worden en dus geen belemmering meer vormen. Ook bij user generated content blijft het lastig om te garanderen dat je blijvend kunt voldoen aan de Webrichtlijnen. Gebruikers zullen niet de moeite nemen hun content zorgvuldig toegankelijk te maken en voor de meeste organisaties zal het onbegonnen werk zijn om dit achteraf te doen voor alle gebruikerscontent. Kennis over Web 2.0 en Webrichtlijnen, en mogelijk uitgebreidere antwoorden op de vragen tijdens Bart Hilhorsts sessie kunnen bijgedragen worden op www.overheid20.nl/werkruimte/45/LabWeb2.0.

“…En daarom hebben we besloten om je een 10 te geven!”

De timing van mijn afstudeeronderzoek was perfect: de Webrichtlijnen waren de afgelopen maanden een hot topic waar uitgebreid over werd geblogd, getwitterd en geschreven in kranten en bladen. Een ideaal moment dus om de Webrichtlijnen te bestuderen en mensen die met de Webrichtlijnen bezig zijn (of juist niet) bij de overheid en in het bedrijfsleven te vragen naar hun meningen en ervaringen. Vandaag het slotstuk: mijn aanbevelingen, mijn ontwerp voor Webrichtlijnen.nl en voor de echte liefhebben mijn complete scriptie.

Onderzoek

Om een antwoord te vinden op mijn onderzoeksvraag heb ik naast een grondige bestudering van de Webrichtlijnen zelf een groot doelgroeponderzoek gehouden. Ik heb 27 mensen gesproken die werken bij overheidsorganisaties, commerciële bedrijven en internetbureaus in de functie van opdrachtgever, manager, ontwerper, ontwikkelaar of redacteur. In dit onderzoek wilde ik achterhalen of mensen bekend zijn met de Webrichtlijnen en wat ze ervan vinden, maar ook wat zij nou precies belangrijk vinden voor een website, en voor welke argumenten zij in hun specifieke rol gevoelig zijn.  De interviews leverden een gevarieerd beeld op: bij de overheid was het kwaliteitsmodel bekender dan in het bedrijfsleven, waar veel mensen er zelfs nog nooit van hadden gehoord. Ook verwarren veel mensen de Webrichtlijnen met Stichting Waarmerk Drempelvrij.nl. Ontwikkelaars waren over het algemeen erg positief over de richtlijnen, terwijl ontwerpers niet enthousiast werden over richtlijnen van de ’saaie’ en ‘trage’ overheid.

Aanbevelingen

Er is meer nodig dan een flitsend logootje of een rake slogan om de Webrichtlijnen beter verkoopbaar en meer bruikbaar te maken. Uit mijn onderzoek blijkt dat het probleem dieper zit. Mijn aanbevelingen hebben dan ook niet alleen betrekking op de communicatie van de richtlijnen, maar ook op organisatorische aspecten. Ze vereisen een andere instelling aan de kant van de initiatiefnemers van de Webrichtlijnen.

Focus op de doelen

Één van de grootste problemen van de Webrichtlijnen is het feit dat mensen ze zien als saaie, strenge regels. Waaróm je die regels zou toepassen wordt daarbij soms bijna vergeten.

Mijn eerste aanbeveling is daarom: focus op de doelen, de voordelen. Laat niet die lange lap met richtlijnen zien en vertel niet direct dat je aan alle 125 richtlijnen moet voldoen om door de keuring  te komen, maar vertel dat je site er sneller door wordt, dat je meer mensen bereikt en beter vindbaar bent in zoekmachines.

Stichting Webrichtlijnen: niet alleen de overheid, maar iedereen

Uit mijn doelgroeponderzoek blijkt dat veel mensen de overheid niet ‘vertrouwen’ als afzender van de Webrichtlijnen. Op het terrein van technologie en internet, dat zich razendsnel ontwikkelt en waar innovaties aan de orde van de dag zijn, is de overheid voor veel mensen geen logische keus. Veelgehoord zijn uitspraken als: ‘de overheid loopt niet bepaald voorop op dit gebied, kijk maar naar de blunders met DigID, de ov-chipkaart…’. Om dit wantrouwen tegen te gaan, raad ik aan een Stichting Webrichtlijnen op te richten. Dit moet een stichting worden waarin allerlei organisaties plaatsnemen: De overheid, belangenorganisaties als drempelvrij.nl, maar ook toonaangevende internetbureaus en andere partijen uit het bedrijfsleven. Zo worden de Webrichtlijnen echt ván en vóór iedereen.

Andere indeling Webrichtlijnen

Een volgende aanbeveling is het anders indelen van de Webrichtlijnen. Het doel hiervan is om een kortere, meer overzichtelijke lijst te creëren. Dat kan door de richtlijnen bijvoorbeeld in te delen in meer algemene hoofdprincipes. Een lijst van een stuk of 30 hoofdprincipes is gemakkelijk te scannen, en door de minder technische omschrijvingen van de hoofdprincipes zal het ook voor opdrachtgevers en managers duidelijker worden waar de Webrichtlijnen over gaan.

Andere toetsingsregeling

Op dit moment ben je alleen ‘geslaagd’ voor de Webrichtlijnen als je aan alle 125 richtlijnen voldoet. Voor veel organisaties is dat (op dit moment) onhaalbaar, of onwenselijk. Met name in het bedrijfsleven moeten keuzes gemaakt worden wat betreft budget. Mijn advies is dan ook om de toetsing anders te regelen, bijvoorbeeld door middel van een rapportcijfer. Dus niet meer ‘alles of niets’, maar meerdere niveaus. Met een basisset aan richtlijnen kun je al een 7 scoren. Overheidsorganisaties zullen uiteindelijk voor de 10 willen gaan. Maar als ze dit niet direct halen, dan is het toch veel bemoedigender als ze wel een 8 kunnen halen, in plaats van volledig afgekeurd te worden? Een bezwaar dat sommige mensen tegen dit advies hebben is dat het kan leiden tot een lakse houding bij organisaties: de 7 is dan opeens wel ‘goed genoeg’. Naar mijn idee weegt dit echter niet op tegen de verbetering van de kwaliteit van websites die op zal treden als meer organisaties in ieder geval een deel van de Webrichtlijnen gaan gebruiken. Want al gaan ze dan niet direct voor de 10, nu laten veel organisaties het hele kwaliteitsmodel maar links liggen als blijkt dat ze niet aan alle 125 kunnen voldoen.

Campagne

Bovenstaande aanbevelingen zijn vooral gericht op mensen die vanuit hun functie bezig zijn met de bouw of het beheer van een website. Om het besef dat de Webrichtlijnen waarde hebben echter  door te laten dringen in alle lagen van de maatschappij is het naar mijn idee een goed plan om een landelijke campagne te organiseren die gericht is op ‘het grote publiek’, de eindgebruikers van websites. Deze campagne moet alleen over de voordelen van de richtlijnen gaan voor die eindgebruikers, en dus geen technische taal bevatten. In een ideale situatie worden de Webrichtlijnen net zo bekend als de BOB-campagne of de Thuiswinkelorganisatie. Dan wordt het voor opdrachtgevers en managers bijna vanzelfsprekend om de Webrichtlijnen mee te nemen bij een beslissing, en zullen ook internetbureaus zorgen dat ze aan deze nieuwe klantvraag kunnen voldoen.

Community

Ook in de digitale wereld kan gewerkt worden aan de verkoopbaarheid van de Webrichtlijnen. Een levendige community is hierbij van groot belang. Er zijn zoveel mensen bezig met de Webrichtlijnen. Al die mensen kunnen vanuit hun eigen perspectief vertellen over het kwaliteitsmodel, hoe zij ermee omgaan en wat ze ervan vinden. Op de nieuwe website van de Webrichtlijnen zou ik dan ook een weblog starten waar mensen uit allerlei hoeken over de Webrichtlijnen kunnen schrijven. Denk aan opdrachtgevers die vertellen hoe zij een Webrichtlijnenproject hebben aangepakt, aan ontwikkelaars die tutorials schrijven en redacteuren die tips en tricks met hun collega’s delen. Naast een weblog is een forum ook een goed idee. In mijn doelgroeponderzoek gaven veel mensen aan dat ze behoefte hebben aan meer samenwerking. Ze willen niet telkens het wiel opnieuw uitvinden, of één op één met de Webrichtlijnenhelpdesk bellen. Op een forum kunnen soortgelijke organisaties elkaar vinden, en kunnen zowel de mensen van de helpdesk als andere professionals elkaar helpen met vragen en problemen. Tegelijk kan een weblog of forum een discussieplatform worden: met name ontwikkelaars geven aan dat zij mee zouden willen denken over de verdere ontwikkeling van de Webrichtlijnen.

Nieuwe website Webrichtlijnen

Het laatste deel van mijn onderzoek had specifiek betrekking op de aansluitende afstudeeropdracht: het creëren van (een ontwerp voor) een nieuwe website voor de Webrichtlijnen. Ik onderzocht hiervoor  aan de hand van de User Experience Honeycomb van Peter Morville hoe de gebruikservaring van elk van de doelgroepen geoptimaliseerd kan worden. Aansluitend op dit onderzoek heb ik een ontwerp gemaakt voor de nieuwe website van de Webrichtlijnen.  In dit ontwerp zijn ook mijn aanbevelingen verwerkt. Ook heb ik gekeken naar een verbetering van de online communicatie op het gebied van schrijfstijl en tone of voice.

Conclusie

Kan de verkoopbaarheid en de bruikbaarheid van de Webrichtlijnen vergroot worden? Jazeker! Ik ben ervan overtuigd dat een betere communicatie en een andere benadering van het kwaliteitsmodel ervoor kunnen zorgen dat de Webrichtlijnen bij een groter publiek bekend en geliefd worden.  Dankzij mijn unieke stageplek had ik de mogelijkheid de Webrichtlijnen van alle kanten te bekijken. Ik zag bij Tam Tam dat het zeker mogelijk is om websites af te leveren die aan alle Webrichtlijnen voldoen, maar ook dat veel opdrachtgevers er nog niet klaar voor zijn. Ze weten er niet genoeg van af, of hebben er simpelweg geen interesse in. Bij de overheid zag ik de strijd die veel organisaties leveren om hun website aan alle standaarden te laten voldoen, en de frustratie als dat dan door een paar richtlijnen net niet lukt.

Wat is nu de heilige graal van de Webrichtlijnen? Ik denk dat het ‘samenwerken‘ is. Samenwerken in een Stichting Webrichtlijnen, samenwerking tussen organisaties onderling om verder te komen met de Webrichtlijnen en als initiatiefnemers, webprofessionals en Webrichtlijnenexperts samen nadenken over de toekomst van het kwaliteitsmodel.  Geen eenrichtingsverkeer meer, maar een levendige discussie en een ’samen komen we er wel uit’-mentaliteit.

Tijdens mijn onderzoek kwam ik erachter dat de Webrichtlijnen gevoelig liggen: iedereen heeft er wel een mening over. Maar wat mij het meest opviel was dat al die mensen die met de richtlijnen bezig zijn dat doen vanuit een eerlijk enthousiasme en een betrokkenheid bij het daadwerkelijk beter maken van de gebruikservaring van internetgebruikers. In die 4 maanden afstuderen heb ik veel interessante mensen ontmoet, nuttige feedback ontvangen en veel hulp gekregen. Aan alle mensen die mij hebben geholpen bij mijn onderzoek: dank jullie wel! Het was een inspirerende en een leerzame ervaring.

Eindpresentatie en downloads

Wie meer wil weten over mijn onderzoek kan hier mijn scriptie en eindpresentatie downloaden en mijn prototype bekijken.

• Eindpresentatie “Webrichtlijnen voor iedereen” (PDF, 4MB)
• Scriptie “Webrichtlijnen voor iedereen” (PDF, 17MB)
• Demo nieuw ontwerp Webrichtlijnen.nl
  N.B. Dit is een functionele demo. De code is gegenereerd door Axure en is dus niet W3C-compliant.

Volgens Jakob Nielsen en Hoa Loranger worden gemiddeld de meeste ernstige usability issues veroorzaakt door slechte vindbaarheid, oftewel informatiearchitectuur en navigatie (zie figuur 1). En dit is nog exclusief ‘zoeken’.

Figuur 1: Gewogen (op ernstigheid) usabilityproblemen per categorie (bron: Nielsen & Loranger, 2006)

Als we inzoomen op het aspect ‘navigatie’, blijkt dat gebrek aan intuïtiviteit (inderdaad geen goed Nederlands), zichtbaarheid, context en consistentie van het navigatiesysteem de voornaamste oorzaken zijn dat mensen informatie op een website niet kunnen vinden (zie figuur 2).

Figuur 2: Grootste navigatie-gerelateerde oorzaken voor het niet slagen van gebruikerstaken (bron: Goldfield, 2009)

Zoals gezegd zijn dit de voornaamste oorzaken. Volgens Goldfield voldoet een effectieve navigatie minimaal aan deze 10 eigenschappen:

• zichtbaar
• intuïtief
• contextgevend
• consistent
• permanent
• passend
• uitbreidbaar
• niet hinderlijk
• gecoördineerd
• toegankelijk

Zichtbaar

Maak van navigeren geen paaseieren zoeken: Zorg ervoor dat de belangrijkste elementen van de navigatie standaard zichtbaar zijn. Mensen scannen websites op hyperlinks met trefwoorden die aansluiten bij het doel dat ze voor ogen hebben. Veel interactie-elementen worden hierbij intuïtief genegeerd. Ook subtiele, maar essentiële hyperlinks als “menu” in onderstaand voorbeeld lopen een groot risico over het hoofd gezien te worden.

Figuur 3: Op Novell.com is de navigatie onzichtbaar

Figuur 4: Hoe hoger de beeldschermresolutie, hoe meer het navigatieknopje van Coca Cola voor het oog verdwijnt

Intuïtief

De gebruiker moet direct snappen hoe het navigatiesysteem werkt. In de regel betekent dit interface-elementen gebruiken waarmee de gebruiker al vertrouwd is. Dit gaat over zowel presentatie, groepering en taalgebruik. Over alledrie bestaan conventies. Gebruikers verwachten bijvoorbeeld:

• direct zichtbare en herkenbare menu’s, bovenaan en/of links;
• een “home” knop (maar niet op de homepage) helemaal links in de globale navigatie (het hoofdmenu) of in de buurt van het menu;
• een logo in de linker bovenhoek;
• een open zoekveld in de rechter bovenhoek;
• log in/uit en winkelwagen-icoon (indien van toepassing) in de rechter bovenhoek;
• subtiel vormgegeven metanavigatie helemaal bovenaan en/of helemaal onderaan;
• dat bepaalde navigatielabels op iedere site gehanteerd worden: Home, Contact, Sitemap, maar ook “Over ons”. Hoewel je dit laatste nog mag vervangen door “Over [organisatienaam]“.

Maar ook een creatieve navigatie-interactie (dus zonder vertrouwde interface-elementen) kan intuïtief werken, als de werking al bij de eerste aanraking direct duidelijk wordt.

Niet intuïtief zijn bijvoorbeeld menu’s die drukke / bannerstijl plaatjes gebruiken in plaats van tekstlabels. De hoofdnavigatie van Coca Cola was in eerste instantie al onzichtbaar, maar als je het vervolgens openklikt, zie je navigatie-items vermomd als banners.

Figuur 5: Coca Cola’s hoofdnavigatie ziet eruit als een rij banners

Contextgevend

Het navigatiesysteem moet communiceren waar in de website de gebruiker zich bevindt. Dit kan op verschillende manieren, zoals:

• huidige locatie visueel aanduiden (bv. door contrasterende kleur) in de lokale navigatie;
• hoofdonderdeel waar de huidige pagina onder valt, visueel aanduiden in de globale navigatie;
• broodkruimelpad opnemen in de pagina.

Daarnaast is het voor de oriëntatie van de gebruiker erg belangrijk dat de navigatie permanent en consistent is.

Permanent en consistent

Het navigatiesysteem is op iedere pagina van de website aanwezig. Het wordt op iedere pagina op dezelfde plaats en op dezelfde manier gepresenteerd. Het gedraagt zich consistent van pagina naar pagina en ook de links erin gedragen zich consistent.

Figuur 6: Wehkamp heeft een permanente, consistente navigatie

Bovenstaande lijkt allemaal vanzelfsprekend, maar gaat nog vaak genoeg mis. Bij grote, complexer websites met een diepe informatiestructuur (bv. 7 lagen) is het vaak zoeken naar navigatiesysteem dat alle lagen bereikbaar maakt en nog goed te hanteren is voor de gebruiker. Dit wil dan nog weleens ten koste gaan van bijvoorbeeld het permanent tonen van de bovenste lagen.

Passend

Navigatiecomponenten en -stijl passen bij de functie van de website en de organisatie erachter. Bijvoorbeeld: een carrousel is wellicht niet erg geschikt voor een bank, maar past prima bij een merk als Disney.

Figuur 7: Carrouselnavigatie op Disney.com

Laat ook meewegen welk navigatiecomponent je gebruikt voor welk type navigatie. In het voorbeeld van Disney wordt de carrousel gebruikt als extra navigatiemethode, maar het is erg riskant om het te gebruiken als hoofdnavigatie. Zie weer het voorbeeld van Coca Cola: doordat het linker navigatiemenu onzichtbaar is, is het meest opvallende navigatiecomponent de carrousel in het midden. Maar die brengt de gebruiker alleen maar naar een zomeractie, een reclamespot en naar Hyves (weg van de site dus).

Uitbreidbaar

Het navigatiesysteem is berekend op geplande groei. Sommige organisaties weten zeker dat hun website nooit meer dan 3 hoofdonderdelen gaat bevatten. Maar in de meeste gevallen is de tijdens het project ontworpen navigatie slechts de uitgangssituatie. In de levenscyclus van een site kan de navigatie verbreden, verdiepen en veranderen. Wees hierop voorbereid. Vooral een horizontale navigatiebalk kan snel volraken. Amazon had in maart 2000 bijvoorbeeld nog 9 hoofd-tabs. Vier maanden later waren dat er al 15, verdeeld over 2 regels. Later is de hoofdnavigatie verplaatst naar de linkerkant.

Niet hinderlijk

Soms wijst de navigatie niet de weg, maar staat hij zelfs in de weg bij het uitvoeren van andere gebruikerstaken. Goldfield liet in London een videofragment uit een usability test zien waarin een gebruiker de zoekfunctie van de Amerikaanse BMW-site wil gebruiken, maar daarbij wordt gehinderd door het uitklapmenu.

Figuur 8: Het uitklapmenu van BMW (USA) hindert de zoekfunctie

Gecoördineerd

Veel sites bevatten meerdere navigatiecomponenten: globale en lokale navigatie, metanavigatie, broodkruimelpad, gerelateerde links, navigatie in de content, enzovoorts. Zorg ervoor dat de verschillende componenten elkaar aanvullen en niet tegenwerken.

Toegankelijk

Last but not least: Het navigatiesysteem moet ook gebruikt kunnen worden door mensen met een mobiele telefoon (klein scherm, misschien plaatjes uitgeschakeld) en mensen met een functiebeperking (bv. blind, lichamelijke handicap). Zorg dus dat het ook werkt zonder plaatjes, zonder javascript, dat toetsenbordbediening ondersteund wordt, dat blinde mensen het navigatiemenu ook kunnen overslaan, enzovoorts.

Figuur 9: De website van het Ministerie van VWS heeft niet alleen een toegankelijke navigatie, maar biedt ook snel-links naar de verschillende navigatiecomponenten

Tot zover de top 10 voorwaarden voor een effectieve website-navigatie. Hiermee kun je veel belangrijke usability-problemen voorkomen die betrekking hebben op informatie vinden binnen de website.

Agile (Engels voor snel, levendig) staat voor iteratief (kortcyclisch) werken, onderdeel voor onderdeel. Handig voor het programmeren, daar zijn velen het wel over eens. Maar op het eerste gezicht lijkt agile een bedreiging voor de user experience (UX) omdat het developers controle geeft over het proces en het niet genoeg tijd gunt voor user research, interactieontwerp en gebruikstesten. Toch horen we ook positieve ervaringen van UX-professionals. Hoe waarborg je user experience in een agile omgeving?

Wat is agile?

De meestgebruikte projectmethodieken volgen het watervalmodel. Hierbij doorloopt het project achtereenvolgens een vast aantal stappen, meestal analyse, ontwerp, bouw, test, acceptatie, implementatie en ten slotte overdracht naar beheer. Iedere stap wordt zo volledig mogelijk uitgevoerd, gedocumenteerd en geaccordeerd, zodat het voor iedereen na iedere stap duidelijk is wat het resultaat is/wordt. Bijkomend voordeel is dat projectscope, -planning en -kosten vroeg in het proces ingeschat kunnen worden en ‘fixed’ afgesproken kunnen worden.

“Waterfall method is best when you can’t afford to learn from your mistakes. You don’t design software for the Space Shuttle in an Agile manner.”

Alon Salant, engineer

De Agile filosofie gaat er juist vanuit dat projecten altijd last hebben van ‘voortschrijdend inzicht’. Dat de klant pas echt weet wat hij wil nadat hij een eerste werkende versie van zijn product heeft gezien. Dat bepaalde denkfouten of gaten in het ontwerp pas worden ontdekt tijdens het bouwen of – erger nog – daarna. Met als gevolg dat er een dure, vertragende iteratie nodig is om dat op te lossen, waar van beide kanten geen rekening is mee gehouden. Agile softwareontwikkeling omarmt juist iteraties en verandering van inzicht. In het Manifesto for Agile Software Development staan de volgende waarden:

• Individuals and interactions over ‘processes and tools’
• Working software over ‘comprehensive documentation’
• Customer collaboration over ‘contract negotiation’
• Responding to change over ‘following a plan’

Agile werken vertaalt zich o.a. in:

• Het tegelijk inzetten van alle rollen bij een sprint, in één team. Bij de watervalmethode heeft iedere fase experts., die hun taak uitvoeren en het resultaat overdragen naar de experts voor de volgende fase,
• Het werken aan één onderdeel tegelijkertijd in korte sprints (liever enkele weken dan enkele maanden),
• Zeer frequente tussenopleveringen, dus vaak feedback van de klant, dus regelmatig wijzigingsverzoeken,
• Zo snel mogelijk vertalen van ideeën naar werkende software. Dit is de belangrijkste voortgangsgraadmeter,
• Zoveel mogelijk persoonlijk contact, zo min mogelijk documenteren,
• Geen vroege zekerheid over hoe het eindresultaat wordt, hoeveel iteraties er nodig zijn en/of hoe hoog de projectkosten zullen zijn,
• Nauwe samenwerking op dagelijkse basis tussen ontwikkelaars en belanghebbenden.

Waarom de vraag?

Een agile projectaanpak zou de nadelen van het watervalmodel moeten oplossen. Er zijn inmiddels voldoende voorbeelden van bedrijven die agile succesvol toepassen. Een van de bekendste is 37Signals (bekend van tools als Basecamp en Backpack), die er zelfs een boek getiteld “Getting Real” over hebben geschreven. Door de succesverhalen krijgt de agile filosofie steeds meer aanhangers. Waarom dan de vraag of agile en usability wel samen gaan?

“Agile methoden proberen usability barriëres in traditionele softwareontwikkeling weg te nemen, maar introduceren nieuwe bedreigingen voor de kwaliteit van de user experience. … Agile’s grootste bedreiging voor de kwaliteit van een systeem komt voort uit het feit dat het een door programmeurs voorgestelde aanpak is die vooral de implementatiekant van systeemontwikkeling adresseert. Dit heeft tot gevolg dat interaction design en usability vaak over het hoofd gezien wordt en dus meer als bijeffect van het programmeren ontstaan.”

Jakob Nielsen (Usability-coryfee)

De meeste user experience designers hanteren een watervalaanpak. Het bekendste voorbeeld hiervan is wellicht Jesse James Garrett’s “Elements of User Experience” model. Het proces begint vaak met het inventariseren van o.a. functionele eisen en wensen, gebruikersdoelen en huidig gebruik. Vervolgens bedenken we dan een concept, creëren – al dan niet met input van gebruikers – een informatiearchitectuur en interactieontwerp, testen op usability, en documenteren het geheel. Ten slotte zorgt het grafisch ontwerp voor het glazuur van de user experience.

Wat gebeurt er met dit proces als we user experience design agile gaan benaderen? Een korte SWOT-analyse:

Sterkten (Strengths)

In welke situaties komt agile goed tot zijn recht? (bron)

• Bij projecten:
  • waarin doorontwikkeld wordt (bv. nieuwe features) aan een product (waarvan het concept dus al staat),
  • van start-ups met een duidelijke visie op hun product, features en doelen,
  • waarbij de ‘time to market’ kritiek is voor succes.
• Bij teams:
  • die het volledige vertrouwen krijgen dat ze de doelen behalen, en die daarin optimaal gefaciliteerd worden,
  • die ervaren zijn, intensief kunnen samenwerken en actief kunnen participeren,
  • met UX-ontwerpers die zich comfortabel voelen bij constante iteratie,
  • met engineers/ontwikkelaars die ook gericht op de gebruiker (’user-centered’) zijn en veel communiceren met ontwerpers.
• Bij klanten:
  • die de wensen en behoeften van hun gebruikers kennen/begrijpen,
  • die dagelijks en face-to-face betrokken kunnen zijn en snel beslissingen kunnen nemen (maar ook van gedachten kunnen veranderen),
  • met heldere, vaste business doelen en visie.

Zwakten (Weaknesses)

Wanneer werkt het watervalmodel beter? (bron)

• Bij projecten:
  • waarin intense, non-modulaire, branded user experiences gecreëerd worden,
  • met grote risico’s en/of complexiteit, die heel goed doordracht moeten worden,
  • waarbij het succes van het ontwerp afhankelijk is van de uitkomsten (en beslissingen) van research.
• Bij teams:
  • op afstand, bv. outsourcing, of gewoon op verschillende locaties,
  • waarvan de leden niet allemaal tegelijkertijd aan hetzelfde kunnen werken.
• Bij klanten:
  • die de wensen en behoeften van hun gebruikers niet kennen/begrijpen,
  • die niet dagelijks en face-to-face betrokken kunnen zijn en snel beslissingen kunnen nemen,
  • met veel belanghebbenden die documentatie nodig hebben als context voor besluitvorming,
  • die fixed price, fixed time èn fixed features willen.

Kansen (Opportunities)

• Het werken in iteraties biedt de mogelijkheid om veel regelmatiger feedback van gebruikers te krijgen. Je kunt het zien als continu verbeterproces.
• Testen met werkende software is meestal te prefereren boven testen met beperkte prototypes.
• De user experience designer blijft continu betrokken en kan de usability dus blijven bewaken. Bij watervalprojecten raakt hij vaak na de ontwerpfase op de achtergrond, omdat hij niet meer op het project is ingepland en inmiddels aan zijn volgende project werkt.
• Door veel persoonlijk contact binnen het team wordt usability geen papieren tijger, maar onderwerp van gesprek. Bovendien bespaart het niet uitgebreid documenteren van alle functionaliteiten tijd.

Bedreigingen (Threats)

• Websites zijn niet hetzelfde als webapplicaties. Agile is in principe gebaseerd op het ontwikkelen van applicaties, met grotendeels afgekaderde, op zichzelf staande functies. Bij veel gebruikersscenario’s voor websites speelt het vinden en verwerken van content een grote rol. Daarom zijn website-taken niet makkelijk te isoleren in specifieke functies.
• Het opdelen van het product in kleinere, losse delen, die één voor één ontworpen en ontwikkeld worden, heeft verder als risico dat de gezamenlijke features geen coherente totaalbeleving opleveren.
• Door het werken in korte iteraties van slechts enkele weken en dus heel strakke deadlines, is het risico groot dat als eerste beknibbeld wordt op usability (research en/of testing), uit angst dat daar geen tijd voor is.
• Als de doelgroep moeilijk bereikbaar en/of beschikbaar is voor het projectteam voor gebruikstesten, maar je wilt wel in iedere iteratie toetsen op usability, dan kan dit een tijdrovende en kostbare activiteit worden.
• Een nauwe samenwerking tussen ontwerper en ontwikkelaar is noodzakelijk. Bij waterval hebben ontwikkelaars nog een Functioneel Ontwerp als houvast voor het uitwerken van de user interface. Wat niet beschreven staat, wordt – met name door ontwikkelaars die zich niet ten volste betrokken voelen bij het succes – niet gemaakt of zo makkelijk mogelijk opgelost zonder overleg met de ontwerper. Hieruit volgt ook: Agile en outsourcing gaan niet samen.

Succesvol zijn in een agile omgeving

Jeff Patton (onafhankelijk consultant en agile coach) heeft de volgende aanbevelingen voor user experience designers om succesvol te zijn in een agile omgeving:

• Neem de rol aan van business owner.
• Onderzoek, modelleer en ontwerp vooraf, maar niet teveel.
• Hak je ontwerpwerk in brokken. Voorkom hierbij dat ontwerptijd in het gedrang komt door ontwerpintensieve iteraties af te wisselen met ontwikkelintensieve iteraties.
• Werk parallel aan de huidige development iteratie vooruit aan de volgende iteratie en evalueer/test de vorige iteratie.
• Creëer een pool van gebruikers waar je continu gebruikersonderzoek mee kunt doen.
• Organiseer continu gebruikersonderzoek in een eigen spoor, los van development.
• Combineer meerdere doelen als je met gebruikers zit.
• Test en optimaliseer de user interface iteratief.
• Maak prototypes simpeler (’low fidelity’) naarmate de samenwerking met ontwikkelaars intensiveert.
• Gebruik prototypes / wireframes voor discussie in plaats van specificatie.
• Word een ontwerpfacilitator.

In een volgend artikel ga ik uitgebreider op deze aanbevelingen in.

Zelf ervaring?

Zelf heb ik nog geen hands-on ervaring met agile UX design. Wie heeft er al wel ervaring mee? Klopt de SWOT-analyse? Nog tips?