Waarom je systeem niet gebruikt wordt en hoe je er wel een ontwerpt

Bijna elk technisch bedrijf heeft een systeem dat op papier klopt en in de praktijk stof vangt. Dat komt zelden doordat het slecht gebouwd is. Het komt doordat het is ontworpen voor iemand die aan een bureau zit, terwijl de gebruiker buiten staat.

De aanschaf gaat bijna altijd hetzelfde. Er is een probleem, er wordt een systeem gekozen dat dat probleem op papier oplost, er volgt een demo waarin alles werkt en het wordt uitgerold met een korte instructie. Daarna wacht iedereen op de verandering die niet komt.

Wat er misgaat, is zelden de functionaliteit. Het is dat het systeem is beoordeeld door mensen achter een bureau, met een groot scherm, twee vrije handen en tijd om even te kijken. De persoon die het echt moet gebruiken heeft geen van die vier.

De veertig-secondenregel

Op de werkvloer geldt een ongeschreven regel die elk systeem meedogenloos test. Als iemand het antwoord niet binnen ongeveer een halve minuut op zijn scherm heeft, stopt hij met zoeken en belt hij een collega. Dat is geen luiheid en geen weerstand tegen verandering. Het is een correcte kosten-batenafweging van iemand met een klant die staat te wachten.

Leg je bestaande systeem langs die regel en je weet meteen waar het spaak loopt. Een goed geordende gedeelde schijf haalt hem niet: drie tot vijf kliks en je moet weten hoe de structuur ooit is bedacht. Een zoekbalk die alleen op bestandsnamen zoekt haalt hem niet. Een portaal waar je eerst voor moet inloggen op een telefoon met slecht bereik haalt hem al helemaal niet.

Zolang bellen sneller is dan opzoeken, verandert er niets aan het gedrag. En gedrag is waar de kosten in zitten.

Ontwerp voor de monteur buiten, niet voor de manager binnen

De vraag bij elke keuze is niet "kan het" maar "haalt het de halve minuut, in de omstandigheden waarin het gebruikt wordt". Zes regels die daaruit volgen.

• Eén ingang, niet vier. Zolang kennis verspreid staat over een schijf, projectmappen, mailboxen en een appgroep, is de eerste vraag altijd "waar zou het staan". Dat kost al meer dan veertig seconden. Eén plek waar je begint, wat de vraag ook is.
• Organiseer op vraag, niet op document. Niemand zoekt een document; iedereen zoekt een antwoord. Eén vraag, één antwoord, kort, met een verwijzing naar het onderliggende document voor wie het naadje van de kous wil.
• Gebruik hun woorden, inclusief de verkeerde. Wie "gas" zoekt moet vinden wat onder "koudemiddel" is vastgelegd. Wie de merknaam intypt moet bij het type uitkomen. Synoniemen zijn geen luxe; ze zijn het verschil tussen vinden en bellen.
• Eén hand, klein scherm, slecht licht. Je zwaarste gebruiker staat buiten met handschoenen aan. Als iets alleen comfortabel werkt op een laptop, werkt het niet.
• Toevoegen moet makkelijker zijn dan appen. Inspreken in plaats van typen. Wie net een storing heeft opgelost, vertelt in twee minuten wat er aan de hand was. Diezelfde persoon typt het nooit uit.
• Datum en eigenaar bij elk antwoord. Niet voor de netheid. Een antwoord zonder datum roept dezelfde twijfel op als drie versies van hetzelfde bestand en twijfel leidt terug naar de telefoon.

Waarom een goede instructie het niet oplost

De standaardreactie op lage adoptie is meer uitleg: nog een training, een handleiding, een herinnering in het werkoverleg. Dat werkt zelden, want het probleem is geen kennisprobleem. Je mensen weten dondersgoed dat het systeem bestaat. Ze kiezen er alleen elke keer opnieuw en volkomen terecht, iets anders.

Gedrag verandert pas als de gewenste route de makkelijkste route is. Dat is geen kwestie van motiveren maar van ontwerpen. Zolang de collega bellen dertig seconden kost en zelf opzoeken twee minuten, wint de collega, bij iedereen, elke keer, hoe goed de training ook was.

De test die je vandaag kunt doen

Een eerlijke kanttekening

Een systeem dat perfect is ontworpen maar leeg blijft, is nog steeds nutteloos. Sterker: een leeg of verouderd systeem is erger dan geen systeem, omdat het je mensen leert dat zoeken geen zin heeft. Die les krijg je er daarna niet makkelijk weer uit. Ontwerp en inhoud zijn twee helften van hetzelfde probleem, daarom leveren wij niet alleen de vorm maar ook de vulling en daarom is ophalen in plaats van laten brengen geen bijzaak maar de kern van de aanpak.

Gedrag is het uitgangspunt, niet de uitkomst

De meeste kennisprojecten beginnen bij de inhoud en hopen dat het gebruik vanzelf volgt. Wij beginnen bij het gedrag: wie zoekt wat, op welk moment, in welke omstandigheden en wat is nu zijn snelste weg naar een antwoord? Pas als die weg door het systeem loopt in plaats van via een telefoontje, is er iets veranderd.

Dat klinkt abstracter dan het is. In de praktijk komt het neer op één vraag die je bij elke keuze stelt: haalt dit de halve minuut, met handschoenen aan?