Beheer het web als een bedrijfssysteem.
Een praktische methode om gebruikerstaken, routes, labels, navigatie en zoekgedrag te onderzoeken vóór een herontwerp of websitemigratie.
WebChorus Editorial Team9 min. leestijd
Begin niet bij het menu en teken nog geen nieuwe sitemap. Kies eerst een belangrijke gebruikerstaak, beschrijf het gewenste resultaat en volg iedere realistische route waarmee iemand dat resultaat kan bereiken. Zo wordt zichtbaar of het probleem werkelijk structureel is, of lokaal zit in ontbrekende inhoud, een onduidelijk label, een zwakke contextlink, gebrekkige zoekresultaten of een lastig bedienbaar onderdeel. Die diagnose voorkomt dat een migratie- of herontwerpbudget wordt besteed zonder de betreffende klant- of medewerkerreis te herstellen.
Kernpunten voor de audit
Ontwerp de audit rond één expliciete beslissing, bijvoorbeeld een sectie repareren, labels wijzigen, een migratie voorbereiden of beoordelen of breder herontwerp verdedigbaar is. Leg vooraf vast welk bewijs voor die beslissing voldoende zal zijn. Een taakgerichte informatiearchitectuur-audit onderzoekt immers of organisatie, labels en navigatie mensen helpen informatie te vinden, hun positie en mogelijkheden te begrijpen en een beoogde taak af te ronden. Zonder besluitkader groeit de audit gemakkelijk uit tot een ongerichte lijst observaties.
Baken vervolgens de omstandigheden af waarvoor de conclusie geldt: doelgroepen, doelen, mogelijke instappunten, paginatypen, apparaten, talen, rechten en relevante reisfasen. Een route die werkt voor een ingelogde medewerker op desktop zegt weinig over dezelfde taak vanuit een externe landingspagina op een telefoon. Noteer ook welke onderdelen buiten de opdracht vallen. Dat voorkomt dat een uitspraak over enkele onderzochte taken wordt gepresenteerd als een oordeel over de gemiddelde gebruiker of de hele website.
Houd de audit daarnaast gescheiden van een contentinventarisatie, technische SEO-audit, toegankelijkheidsbeoordeling en herontwerpproject. Die disciplines kunnen waardevolle vervolgvragen opleveren, maar beantwoorden niet dezelfde hoofdvraag. Werk in het onderzoekslog met vier herkenbare categorieën: vaststaande context, waargenomen gedrag, bevindingen uit expertinspectie en nog ongetoetste hypothesen. Daardoor kan een stakeholderaanname niet ongemerkt veranderen in een vermeend gebruikersprobleem en blijft later duidelijk waarop iedere aanbeveling rust.
Bouw de taakset door gewenste uitkomsten in herkenbare gebruikerstaal te formuleren en bij elke taak de herkomst vast te leggen. GOV.UK adviseert te onderzoeken wat mensen proberen te doen, hoe zij dat nu doen, welke problemen zij ervaren en welk resultaat zij nodig hebben. Schrijf daarom bijvoorbeeld niet dat iemand naar een intern genoemde productcategorie moet navigeren. Beschrijf wat die persoon wil weten, regelen, vergelijken, downloaden of afronden, zonder het veronderstelde label of de bedoelde route prijs te geven.
Verzamel kandidaten uit gebruikersonderzoek, webanalyse, interne zoekopdrachten, supportvragen, feedback, eerder onderzoek, observaties en medewerkers die rechtstreeks met gebruikers werken. Deze bronnen leveren verschillende soorten aanwijzingen. Analyses, zoeklogs, uitstappunten en supportcontacten bewijzen niet zelfstandig wat iemand bedoelde, waarom een route mislukte of welke structuur het probleem oplost. Noteer daarom zowel de bron als de interpretatiestatus. Een wens van een manager of een expertinschatting blijft een hypothese totdat gebruikersbewijs haar ondersteunt.
Stel geen taakset samen op basis van volume alleen. Neem naast vaak voorkomende taken ook taken op die grote gevolgen hebben, bekend lastig zijn of een minder zichtbare doelgroep bedienen. Leg per taak de doelgroep, aanleiding, mogelijke startcontexten, succesvolle uitkomst, verwachte bestemming en bewijsbron vast. Een Digital.gov-casus laat zien hoe realistische scenario's uit eerder onderzoek kunnen worden afgeleid en vóór het testen op dekking kunnen worden beoordeeld, zonder de aantallen uit die ene casus tot norm te verheffen.
Gebruik per taak één doorlopend werkblad dat de uitkomst, bestemming, startcontexten, mogelijke routes, waarnemingen, diagnose en hertoets met elkaar verbindt. Neem niet aan dat iedereen op de homepage begint. Een bezoek kan starten bij een zoekmachine, een gedeelde diepe link, een sectiepagina, een afgeschermde omgeving of de interne zoekfunctie. Breng daarom bladerpaden, contextlinks en zoekroutes naast elkaar in kaart en maak zichtbaar voor welke omstandigheden een route wel of niet beschikbaar is.
Noteer bij ieder beslispunt het zichtbare signaal, de verwachting die het wekt, de bereikte bestemming en de herstelmogelijkheid na een verkeerde keuze. Kijk niet alleen of een eindpagina technisch bereikbaar is. Leg ook vast of iemand kan herkennen dat een keuze onproductief was, terug kan naar een betekenisvol punt en een alternatief kan proberen. WCAG 2.2-succescriterium 2.4.5 verlangt meer dan één vindwijze binnen een verzameling pagina's, met een uitzondering voor resultaten van en stappen in een proces.
Laat hetzelfde werkblad meegaan van inspectie naar gebruikersonderzoek, prioritering, eigenaarschap en hertoets. Daarmee blijft een voorstel herleidbaar tot een specifieke taak en een daadwerkelijk onderzocht routeonderdeel. Voeg geen algemeen oordeel zoals ‘de navigatie is slecht’ toe wanneer de gegevens alleen een onzeker label vanuit één instappunt betreffen. Een nauwkeurige rij dwingt het team te benoemen welk bewijs ontbreekt, wie een wijziging kan uitvoeren en welk gedrag na die wijziging opnieuw moet worden onderzocht.
Een taakgerichte IA-audit vraagt niet of de sitemap netjes oogt, maar of mensen via realistische routes een nodig resultaat bereiken.
| Taak, doelgroep, aanleiding, uitkomst en bron | Startcontexten, routes en onderzochte signalen | Gedrag, meetpunten, fouttype en bewijskracht | Kleinste wijziging, eigenaar en hertoets |
|---|---|---|---|
| Een aantoonbaar relevante taak, beschreven zonder bestemmingslabel | Externe landing, bladerpad, contextlink en interne zoekroute; labels en oriëntatiepunten | Voltooiing, hulp, verkeerde afslagen, teruggaan, zoekherformulering en toelichting | Lokale reparatie of structurele wijziging, verantwoordelijke rol en dezelfde te hertoetsen route |
| Een taak voor een andere doelgroep, toestand of apparaat | Alleen de routes die in die context werkelijk beschikbaar zijn | Verschillen tussen contexten, plus de zekerheid en beperkingen van het bewijs | Afgebakende aanpassing per context en vooraf vastgelegde succeswaarneming |
Inspecteer elke materiële schakel van het instappunt tot en met de uiteindelijke inhoud of handeling. Bekijk externe landingspagina's, globale en lokale navigatie, overzichtspagina's, groeperingen, paginakoppen, kruimelpaden of andere locatiesignalen, contextlinks, interne zoekresultaten en het eindpunt. Controleer bij iedere schakel welke belofte een label of kop doet en of de bestemming die belofte waarmaakt. Microsoft adviseert daarbij uit te gaan van gebruikersperspectieven, veelvoorkomende taken en mentale modellen, niet uitsluitend van de organisatiestructuur.
Een bruikbaar label is contextafhankelijk: het moet nauwkeurig en vertrouwd zijn, snel te scannen en voldoende onderscheidend van naburige opties. WCAG 2.2-succescriterium 2.4.6 vereist dat aanwezige koppen en labels hun onderwerp of doel beschrijven. Controleer daarnaast of herhaalde navigatie voorspelbaar blijft; succescriterium 3.2.3 verlangt een consistente relatieve volgorde tenzij de gebruiker zelf een wijziging initieert. Dat verbiedt lokale navigatie niet, maar vraagt wel aandacht voor onverwachte verschuivingen tussen vergelijkbare pagina's.
Herhaal belangrijke taken wanneer paginatype, apparaat, taal, rechten of toestand de route werkelijk verandert. Beoordeel interne zoekfunctie niet als nooduitgang bij voorbaat: zoeken kan een geldige voorkeursroute zijn en geldt binnen WCAG ook als mogelijke alternatieve vindwijze. Onderzoek daarom of zoekwoorden worden herformuleerd, resultaten relevant en begrijpelijk zijn, de bestemming vertrouwen wekt en de taak wordt afgerond. Alleen het gebruik van zoeken bewijst niet dat de navigatie is mislukt.
Kies de methode op basis van de onzekerheid die de auditbeslissing blokkeert. Expertinspectie en bestaand gedragsbewijs zijn geschikt om vermoedelijke zwakke plekken te lokaliseren, maar maken een vermoeden nog niet tot waargenomen gebruikersfalen. Formuleer daarom eerst de bewijsvraag: twijfelt het team aan de groepering, aan een label in de hiërarchie of aan de volledige route door de vormgegeven website? Die afbakening voorkomt dat één bekende onderzoeksmethode voor ieder probleem wordt ingezet.
Gebruik cardsorting wanneer u wilt weten hoe deelnemers inhoud verwachten te groeperen of welke categorietaal zij gebruiken. Bij een open cardsort maken en benoemen deelnemers zelf groepen; bij een gesloten variant verdelen zij inhoud over gegeven categorieën. De methode valideert niet of iemand via een echte pagina, contextlink, zoekfunctie of bedieningscomponent kan voltooien. Gebruik een treetest wanneer de vraag juist is of de hiërarchie en labels een bestemming vindbaar maken zonder invloed van de paginaopmaak.
Kies taakgerichte usabilitytests wanneer de onzekerheid zich uitstrekt over vormgegeven navigatie, paginacues, bediening, contextlinks, zoeken, herstel of voltooiing. NIST beschrijft zulke tests als representatieve gebruikers die representatieve taken uitvoeren. Mogelijke waarnemingen zijn voltooiing, hulp, fouten, tijd, verkeerde afslagen, teruggaan, herformulering van zoekopdrachten, bestemmingsvertrouwen en de uitleg van deelnemers. Leg alleen gegevens vast die de auditbeslissing helpen; er bestaat geen verplichte universele scorekaart voor iedere studie.
Classificeer eerst het defect en kies daarna pas de ingreep. Gebruik herkenbare categorieën: ontbrekende of onvolledige dekking, een ontbrekende instaproute, een misleidend label, onverwachte groepering, gebrekkige oriëntatie, een ontbrekende contextlink, zwakke zoekresultaten, inconsistente navigatie of een bedieningsprobleem. Zo leidt een hoge uitstap, een mislukte klik of een supportvraag niet automatisch tot de conclusie dat de hele navigatiestructuur moet veranderen. Het fouttype bepaalt welk onderdeel moet worden hersteld en hertoetst.
Prioriteer met zichtbare beslisinvoer: belang van de taak, getroffen doelgroepen, waargenomen frequentie, gevolgen, bewijskracht en afhankelijkheden van de oplossing. Bespreek deze factoren afzonderlijk in plaats van het oordeel te verbergen in één universele gewogen IA-score. Kies vervolgens de kleinste ingreep die het dossier ondersteunt, zoals inhoud aanvullen, een label of link herstellen, pagina's hergroeperen, zoekresultaten verbeteren of één sectie herstructureren. Benoem voor iedere ingreep een eigenaar en dezelfde taakroute voor de hertoets.
Schaal pas op naar breed herontwerp wanneer belangrijke fouten in relevante contexten terugkeren, door waargenomen bewijs worden ondersteund, structureel van aard zijn en niet redelijk met lokale reparaties verdwijnen. Test de getroffen taken vóór en na de wijziging; een opgeleverde sitemap is geen succesmaat. Betrek een ervaren informatiearchitect of UX-onderzoeker wanneer taakselectie, onderzoeksopzet of structurele afwegingen de capaciteit van het team overstijgen. Roepen bevindingen toegankelijkheidsvragen op, laat dan een passende conformiteitsevaluatie uitvoeren: enkele onderzochte WCAG-criteria bewijzen geen toegankelijkheid van de hele website.
Een taakgerichte IA-audit volgt onderbouwde gebruikerstaken langs instappunten, navigatie, labels, groeperingen, oriëntatiesignalen, contextlinks, interne zoekroutes en de uiteindelijke voltooiing. De audit stelt vast waar een route en de verwachtingen eromheen breken. Zij vervangt geen contentinventarisatie, technische SEO-audit, volledige toegankelijkheidsbeoordeling of herontwerptraject.
De geraadpleegde bronnen geven geen universeel aantal dat voor iedere audit volstaat. Stem de omvang af op de beslissing, verschillen tussen doelgroepen, het belang en risico van taken, de resterende onzekerheid en de vereiste bewijskracht. Neem aantallen uit een afzonderlijke casus daarom niet over als algemene norm.
Webanalyses, zoeklogs, uitstappunten en supportcontacten kunnen opvallende routes en onderzoeksvragen aanwijzen. Zij bewijzen zelfstandig niet wat iemand wilde bereiken, waardoor gedrag ontstond of welke structuur het probleem verhelpt. Combineer zulke signalen met inspectie, interviews, observatie of taakgericht gebruikersonderzoek.
Nee, zoeken kan een geldige voorkeursroute zijn en een nuttig alternatief naast bladeren. Onderzoek of mensen zoekopdrachten moeten herformuleren, of de resultaten relevant en begrijpelijk zijn, of zij de bestemming vertrouwen en of zij de taak voltooien. Diagnoseer pas daarna een zoek- of navigatieprobleem.
Een breed herontwerp is verdedigbaar wanneer belangrijke taakproblemen in relevante contexten terugkeren, met waargenomen bewijs zijn onderbouwd en structureel blijken. Controleer eerst of gerichte wijzigingen aan inhoud, labels, links, groepering of zoekresultaten het probleem oplossen. Hertoets de getroffen taken voordat u een groter verandertraject goedkeurt.
Voor het onderzoek voor dit artikel zijn de volgende bronnen gebruikt:
Contentstrategie voor websites
Gebruik een paginadoelbrief met negen velden om een contentverzoek te toetsen, de juiste keuze te maken en schrijvers een scherpe opdracht te geven.
Bouw een traceerbare websitestrategie die doelgroepbewijs, klantreizen en websitecapaciteiten verbindt met meetbare resultaten.
Een praktisch kader om paginadoel, bewijs, keuzes en vervolgstap helder te houden in brede, smalle, ingezoomde en gelineariseerde weergaven.
