Een SMS dienstverlener, WebText.com, die wij evalueren voor een intern softwareproject observeerde dat wij iets uitproberen van hun dienstenpakket. Dit op zich is al vrij bijzonder; de meeste online dienstverleners wachten tot een klant gaat klagen, dan pas gaan ze de logboeken nakijken, op verzoek. Deze partij heeft dus tevoren tijd geïnvesteerd in pro-actieve, geautomatiseerde observaties. Waarschijnlijk met het doel de beschikbaarheid van hun dienst te optimaliseren. Uitstekend.

Maar ze observeerden dus iets bijzonders, voor een normale dienstverlener is dat voldoende reden om (blind) een waarschuwing te sturen, van de strekking “Nu ophouden, of we sluiten je af!” Maar niet de jongens van Webtext…

Let op, ons experiment is innovatief. Het vereist technische expertise om hun automatische observaties van ons experiment te onderscheiden van andere automatische observaties, die schadelijk kunnen zijn voor de beschikbaarheid. Houd dat in gedachten en lees de (ingekorte) e-mail die we tijdens onze experimenten (*) ontvingen.

We noticed you were trying to … through our service. This is not something we have made available yet, but it has been developed,

so we have just now added it to our production site, and you should be able to try again.  Sample text to send:

I have added some more credit to your account so you can try this out.

Best regards,
Dave Clarke
WEBTEXT.COM Support Team

Hierna volgde natuurlijk een mailwisseling waarbij we in direct contact kwamen met de ontwikkelaars van de dienst – alsof we in direct gesprek waren met de mensen in Amerika. Ze communiceerden ook heel bescheiden/open over beperkingen en tekortkomingen in de dienst.

Deze aanpak helpt beide partijen enorm en dat allemaal doordat de support crew aldaar de juiste toon kiest en pro-actief handelt. Testers van hoog nivo zijn voor Webtext immers ook kostbaar. Wij doen het gratis.

En ons experiment? Dat is (natuurlijk) geslaagd!

(*) De e-mail komt uit Amerika, iemand met de technische expertise was om 05:00 AM wakker en werkte dus tijdens onze kantooruren hieraan.

WebText.com logo

Jan, gebruiker

In softwaremaatwerkland lijdt Jan-op-de-werkvloer onder conventionele wijsheid van zijn manager, die een IT systeem laat bouwen voor Jans afdeling. Het meest storende gevolg vind ik de datamodelgedreven interactie waarmee Jan opgezadeld wordt.

Laat ik eerst uitleggen wat datamodellen zijn.

Datamodellen

Tegenwoordig slaan vrijwel alle zakelijke applicaties hun gegevens op in SQL databases. Het principe daarvan is niets meer dan een verzameling tabellen, bestaande uit kolommen met ruwe data (je geboortedatum, je naam, de productcode) en speciale kolommen met regelnummers uit andere,soortgelijke tabellen.

IT managers met een opleiding in de jaren 70/80 (of autodidact) hebben geleerd om databases te ‘modelleren‘. Dat is het zo handig mogelijk opdelen van bedrijfsgegevens in tabellen. Modelleren is een truucje: als je het doorhebt is het eigenlijk heel simpel.

De opdrachtspecificatie van maatwerk bestaat, omdat dat dat nu immers het domein is van voornoemde demografische groep, dan ook meestal vooral uit database-velden: de kolommen van de tabellen. Daar wordt lang en zwaarwichtig over gediscussieerd. Daar voelt men zich veilig en gezaghebbend bij. En dat vindt iedereen tenslotte prettig!

Datamodelgedreven interactie

De inhoud van de SQL tabellen zit diep verborgen onder de motorkap van de applicatie. Echter, door de grote nadruk die managers/klanten leggen op het opslagformaat (de kolommen en tabellen) zetten zij software-ontwikkelaars impliciet onder druk om, op het scherm, te tonen dat de applicatie inderdaad voldoet aan een datamodel.  Zo wordt elk scherm een afspiegeling van de tabelvorm van zijn onderliggende gegevens.  Daarom zien bijna alle schermen eruit als een Excel-blad: een schermvullende tabel.

De knoppen waarop je klikt en de invoervelden zijn later toegevoegd, volgens conventies. Het gevolg is dat de applicatie de acties wel uitvoert zoals gespecificeerd, maar op een hele saaie, inefficiënte en bovenal verwarrende manier. Immers, het conceptueel model van de interactie is gebaseerd op machine-efficiënte gegevensopslag, niet op efficiënt applicatiegebruik of een prettige ervaring. Of om het anders te zeggen: Het is een chassis zonder interieur, zonder pedalen en vooral zonder een stuurwiel. Geen wonder dat het oncomfortabel voelt.

Herken datamodelgedreven interactie

Hoe herken je nu datamodelgedreven interactie? Welnu, ten eerste natuurlijk aan de overdaad aan tabellen, vooral met veel kolommen die je nu niet nodig hebt: je moet dus turen naar welke kolom de gegevens bevat die jij zoekt voor je taak. Als het niet op het scherm past maken we de letters gewoon wat kleiner…

Maar er is nog een teken aan de wand: Bij het uitvoeren van je taak doorkruis je meerdere schermen, waarbij je op elk scherm een ander stukje informatie aan het systeem moet voeren.

Voorbeeld:

Je systeem registreert de teams van de voetbalvereniging. Het datamodel bewaart leden en teams gescheiden, elk in hun eigen tabel. Elk seizoen wijzigt de teamindeling en de klasse van elk team. Dat levert je veel werk op, want je moet

1. het bestaande team opzoeken (scherm 1) en dat “archiveren”
2. een nieuw team aanmaken van de juiste speelklasse(scherm 2) en dat “starten”
3. een teamlid opzoeken (scherm 3) op naam
4. het teamlid toevoegen aan het nieuwe team (scherm 4)
5. voor alle andere 10 spelers stap 3 en 4 herhalen (schermen 5..24)
6. voor alle andere 6 teams stap 1/tm 5 herhalen (schermen 25..144)

Geen wonder dat je daar tegenop ziet!

NB. Ik laat het aan u over zelf een slimmere, gecombineerde manier te bedenken zodat de taak in 1 of 2 schermen klaar is. Hint: teams veranderen relatief weinig.

Datamodellen zijn een ’solution’

De datamodellen in de specificatie zijn zelf een ’solution’: een IT oplossing op zoek naar een probleem. Het probleem van gegevensopslag speelt namelijk nog helemaal niet tijdens de eerste vergaderingen over een mogelijk nieuw IT systeem. De wereld is veranderd sinds de jaren ‘80: het datamodel is meestal onbelangrijk.

In plaats van te vergaderen over datamodellen zou de IT manager moeten praten over

1. welke acties de mensen op de werkvloer met de applicatie moeten uitvoeren en
2. hoe de daarbij benodigde informatie gecondenseerd en in de juiste context aan hen gepresenteerd wordt.

En als je iemand betrapt op het voornemen vooral tabellen te gebruiken, “lekker makkelijk, zoals iedereen gewend is, van Excel”, bedenk dan dat dat eigenlijk zonde is van duur maatwerk: dat kan vrijwel gratis met gespecialiseerde tools en zelfs – hoe kan het ook anders – met Excel zelf!

• de huur van een server,
• de bepalingen in het onderhoudscontract, of
• de afspraken over aanlevering van operationele gegevens

Maar vooral ook afspraken met en over mensen en de operationele organisatie liggen op het bordje van de productmanager, zoals

• het voorbereiden van een gebruikerscursus,
• een marketingcampagne voorbereiden of
• het aanstellen van een applicatiebeheerder

Je zou bijna vergeten dat de productmanager verantwoordelijk is voor de zakelijke inhoud van de software in ontwikkeling! De bouwers zullen ervoor zorgen dat het product opstart, rekent en misschien zelfs “gebruiksvriendelijk” is. Maar hij moet ervoor waken dat het product de investering waard wordt.

Conceptuele Integriteit

Ik zie een leidraad die de product owner kan volgen tijdens de ontwikkelingsfase. Hij moet streven naar Conceptuele Integriteit. Eigenlijk beantwoordt hij doorlopend de vraag: Kan elke functie in de applicatie zijn eigen broek ophouden?

Concept. Integer. Twee moeilijke woorden. Het woordenboek helpt ons gelukkig op weg:

Concept:

Algemeen idee, Intentie, Bedoeling

Integer:

1. Eerlijk en oprecht zijn, morele principes

2. Compleet en inwendig samenhangend. Solide constructie.

Streven naar conceptuele integriteit betekent letten op de Compleetheid, Samenhang en Consistentie ten opzichte van de zakelijke Intenties. Laten we daar eens induiken.

Compleetheid

Een softwareproduct moet in meerdere opzichten compleet zijn, af zijn.

Puzzelstukjes

Bovenal vervult de software een paar stappen van een bedrijfsproces. Elke stap moet het product netjes uitvoeren en elke stap moet ook netjes aansluiten op zijn naburige stappen in de workflow. Mens en machine wisselen hun beurt af om samen een taak uit te voeren. Op de overdrachtspunten tussen beide moet de software netjes in de organisatie passen.

ontbreekt er een puzzelstukje?

Maar ook de gegevens binnenin de software moeten volledig zijn. Gegevensbestanden moeten foutloos ingeladen kunnen worden, per bestand, database of met een externe koppeling.

Mag ik er even bij?

Complexere organisaties vereisen tenslotte ook nog een hiërarchisch systeem van applicatierollen en daaraan gekoppelde rechten. De rechten van elke rol moet de volledige taak van een persoon met die rol ondersteunen. Dat betekent dat elke gebouwde functie die nodig is om de rol op je te nemen ook tot je beschikking staat. (Genoeg rechten.) Door het proces na te spelen blijkt al snel waar nog rechten ontbreken, of welke rollen  teveel rechten hebben. (“Verrek! De conciërge mag de directiesalarissen wijzigen! Oeps.”)

Samenhang & Consistentie

Dat een applicatie alle functies op de lijst van eisen bevat, wil nog niet zeggen dat ze ook te gebruiken zijn. De samenhang van functies en de gelijkvormigheid van systeeminteracties maakt de applicatie voorspelbaar en breed inzetbaar.

Anders dan de rest

Eén stijl

Ten eerste moet de lay-out consistent zijn. De kleuren, lettertypen en de vlakverdeling zijn een houvast voor de gebruikers. Ze maken de applicatie herkenbaar en bieden houvast bij navigatie (“waar ben ik?”). Doordat alle webapplicaties in dezelfde browser, hetzelfde window op je scherm staan is dit tegenwoordig onmisbaar.
En als de gebruikersinterface steunt op een metafoor, moet die metafoor ook consequent doorgevoerd zijn.

Eén ding, één naam

Ook de terminologie snakt naar consistentie. Als je bijvoorbeeld klikt op een link die belooft te leiden naar een “Registratieoverzicht”, mag de pagina waarop je uitkomt niet “Inschrijvingenrapportage” heten, ook al is dat synoniem. Dezelfde naam voor hetzelfde artefact door de hele applicatie dus.
Soms is dit verrassend lastig, omdat bij automatisering van bedrijfsprocessen taken voor het eerst een unieke naam moeten krijgen. Een nieuwe naam bedenken dus en die meteen consequent inzetten, zowel in de applicatie (makkelijk) als in de organisatie (moeilijk).

Eén taak, één manier

Tenslotte moeten systeeminteracties gelijkvormig zijn. Als je een weekrapportage op dezelfde manier opvraagt als de jaarrapportage, hoef je die handeling maar één keer te leren om het allebei te kunnen.
En als je beide rapportages exporteert, voelt het natuurlijk raar als er één in Excel97 en de ander in Excel2007 formaat uitkomt. (Eigen ervaring!)

De keerzijde

Nu een situatie uit het harde leven. Met Conceptuele Integriteit heb je als productmanager telkens alle features waaraan men begonnen is, vol vertrouwen naar vervolmaking gestuurd. Het projectbudget is bijna op, oplevering (van de Scrum sprint) in zicht. Gesteund door je toetsing aan Conceptuele Integriteit concludeer je geschrokken dat één applicatieonderdeel nog niet klaar is. Maar er is ook niet genoeg budget meer om het af te bouwen. Het is geen extra investering of vertraging waard. Wat dan?
Welnu, dan snijd je het rottende orgaan uit de patiënt. Een half werkend feature is geen feature. Het is ballast.

Auw! Dat doet zeer dokter!

In Scrumprojecten, adviseer ik de klant (product owner) over Conceptuele Integriteit, in plaats van er zelf over te beslissen. Dat is een ‘world of pain’.  Ik vermoord niet alleen het hobbyproject van een collega, maar ik doe ook de klant pijn als ik vraag afstand te doen van een half voltooid feature. Dit voelt de klant als een misdaad, als kapitaalvernietiging. Houd de tissues in de aanslag!

Waardeloze, kostbare ballast

Jammer maar helaas

Maar een onaf feature is ballast:

• het belooft een ontwetende gebruiker waarde en stelt hem dan keihard teleur
• het levert negatieve, nettowaarde
• het verwart ontwikkelaars tijdens onderhoud. “Wat is dit nu weer? Dit werkt niet eens!“
• het neemt waardevolle ruimte in, op het scherm en in ieders gedachten

De tijdsinvestering die gemoeid is met het orgaan heeft geld gekost. Maar kapitaal is het niet, want die investering heeft geen waarde opgevelerd. Wat aan het eind van de rit niet werkt, dat zet je buiten de deur. Een programmeur wist alle sporen ervan, de onafgeronde resultaten gaan in quarantaine (versiebeheersysteem) en daarna praten we er niet meer over. Een gezondere applicatie is het resultaat.

Het beoordelen van conceptuele integriteit vereist domeinexpertise en een zakelijke blik. Het is soms confronterend, maar zeker de moeite waard. En als de applicatie dan live gaat, is de kans het grootst dat alle betrokkenen werkelijk iets te vieren hebben wat later geld oplevert!

Met dank aan Marco Plaisier, sparringpartner in de voorbereiding en aangever van de term Conceptuele integriteit.

Grootste gemene deler

De meeste software waarmee we dagelijks werken is ontwikkeld voor een enorme groep mensen. Producten als Word, Windows (of Mac OS) en zelfs de software in je mobieltje vallen in die categorie. Al die mensen willen een beetje van hetzelfde, maar heel veel verschillends. Zo’n product kun je alleen bij de massa aan de man brengen als je mensen tevredenstelt: de kern van hun behoefte bevredigen. Oftewel: dit zijn producten die gaan voor de grootste gemene deler van de functies. Massaproducten voldoen nooit aan al je wensen.

Complete verzameling

Maar in de wereld van maatwerksoftware ligt dat anders. Omdat de opdrachtgever het beste weet wat zij wil kunnen met het product is zij de enige die kiest welke functies we inbouwen. De specialist die de productwensen in detail bespreekt met de opdrachtgever levert een lijst functies - het programma van eisen –  op, die de grootste gemene deler zijn van …. een handjevol personen. Oei..

Dit programma van eisen kost veel tijd en moeite van alle kanten, maar hoe meer opdrachtgevers (collega’s, zakenpartners) ernaar kijken, hoe meer punten eraan toegevoegd worden. Het is geen grootste gemene deler. Dankzij het poldermodel is het de complete verzameling van uitgesproken wensen.

De schaar erin

De hele lijst past niet in het budget noch de planning. Met deadlines om de hoek en een oprakend budget wordt iedereen wat ongeduldig. Dan komt onvermijdelijk het kiezen of delen, dus met MoSCoW (of anderszins) gaat de schaar in de lijst. Maar wie maakt die keuze? Meestal is dat de gepijnigde opdrachtgever die het project betaalt. 

Ik observeer deze kleine marteling dagelijks, met gepast medelijden. Stel je voor dat je al je medewerkers enthousiast hebt gemaakt. Iedereen kwam met goede ideeën en elk idee bleek nog aantrekkelijker nadat de eisenspecialist ze op papier zette. En nu moet je dus kiezen tussen

• Jans kostenbesparende functie, of 
• Pieters informerende functie, of 
• Chantals klantwervende functie, of
• je eigen al-zeg-ik-het-zelf-best-wel-goede-idee voor een functie

Je bent gewend te kiezen uit meerdere opties voor  één kwestie, maar dit zijn allemaal opties met elk hun eigen kwestie! Er valt niks te vergelijken! 

Afkicken

Er bestaan keuzehulpjes die je aandacht richten op Return on Investment, PR-waarde of stakeholder-buy-in. Maar het blijft een ontzettend afkicken. In de roze fantasiewereld van het eisenpakket is alles mogelijk. Dan hoef je niemand teleur te stellen. Betrokkenen verworden tot verslaafden in het prioriteringsproces. Ze zeggen 

• Meer geld! Meer tijd! Ik moet die functie hebben. (geldverslindend)
• Zonder deze functie heeft het het project geen zin meer. (suïcidaal)
• Zit je me nu te belazeren? (paranoïde, wantrouwig)

Daag een eis uit

Ik heb geen definitief antwoord. Ik merk dat mijn opdrachtgevers het verhelderend vinden wanneer ik ze uitdaag: “Ach, dit kunnen we wel schrappen hè?” of “Je gelooft zelf toch ook niet dat deze functie ooit zijn investering terugverdient?” Kortom, vrij boute stellingen. Als er conflict ontstaat is de functie kennelijk de moeite waard om voor te vechten. Anders gaat het in de prullenbak.

Wie strijdt voor gebruiksvriendelijkheid

Maar in deze ondervragingstaktiek schrapt de klant vlotjes alle gebruiksvriendelijkheidspunten op de lijst. In dit blog lees je al dat gebruiksvriendelijkheid te beargumenteren valt, maar meestal is het juist de opdrachtgever die daarvan overtuigd moet worden. Zo kiest dus bijna elke opdrachtgever voor een extra functie, ten ongunste van de gebruikersinterface. Dat stelt enkelen op korte termijn tevreden – je keus voor Pieters suggestie voelt hij als een compliment – maar velen uiteindelijk teleur: iedereen klaagt steen en been over de moeizame ingebruikname van het systeem. 

De UCD expert (ik) zou dus juist de functie moeten verdedigen in een soortgelijk steekspel met de opdrachtgever. Maar daarvoor moet de opdrachtgever inzien dat ze misschien toch niet alles weet van haar eigen toko. Natuurlijk kan je haar met prototypes laten ‘voelen’ wat gebruiksvriendelijkheid oplevert, maar dan moet je eerst wel toestemming hebben om die te ontwikkelen. Soms zie ik daarvoor alleen burgerlijke ongehoorzaamheid als uitweg. En dat is precies wat ik zou adviseren: Tolereer een gezonde mate van dwarsheid van je softwarebouwers. Ze zijn niet alleen je dealer. Ze kunnen ook je afkickbegeleider zijn…

Maak kennis met Oma Olga. Zij wil Internetbankieren.

Olga is een fictief personage die User Centric Designers bedenken om een helder beeld te vormen van een doelgroep. Dit heet een persona. Persona’s zijn fictief maar geen op hol geslagen fantasie: doelgroeponderzoek fundeert de inhoud.

Ken je doelgroep

Oma Olga wìl helemaal niet Internetbankieren, ze wordt gedwongen! Waar ze vroeger haar maandelijkse gift aan haar kleindochters kon doen op het bankkantoor, wordt ze daar nu geweigerd: “Dat doet u beter via Internet mevrouw.” Haar buurtkantoor op loopafstand is opgedoekt.

Olga is beslist niet vervuld van vreugde als ze begint met Internetbankieren. Ze is beledigd, boos en onzeker. Ze zit niet te wachten op features.

Welkom bij de Postbank?

Olga ontvangt voorafgaand een geheimzinnig poststuk, met daarin twee vreemde lettercombinaties en een aanwijzing. Bijvoorbeeld:

gebruikersnaam: kkdjdhy7
wachtwoord: dhjdjdk8756
“U moet bij uw eerste bezoek een nieuw wachtwoord kiezen. U mag dat niet opschrijven. U moet het onthouden.”

Uit mijn vorige artikel begrijp je wel, dat dit niet zo’n goede basis is, gezien ons geheugen.

Wat ervaart Olga bij de Postbank?

Hoewel de usability van de pagina niet eens zo slecht is, is het een tamelijk angstaanjagend geheel: Elke regel tekst is ofwel dikgedrukt, felrood of onderstreept.

Olga’s eerste oogopslag (centraal blikveld) zal vallen op “Hoe kan ik blokkering van mijn gebruikersnaam en wachtwoord voorkomen?” Voor iemand die niet precies begrijpt wat dat inhoudt, een huiveringwekkende boodschap.
Nu is Olga dus beledigd, boos, onzeker èn bang.

Welkom bij de Rabobank!

De Rabobank stuurt Olga vooraf een doosje, met daarop het Rabobeeldmerk en een vriendelijke, stapsgewijze handleiding.

“Houdt uw bankpas gereed.”

Is de enige aanwijzing in de brief. Met bankpas in de aanslag opent ze de site. Olga krijgt er al vertrouwen in:

Olga ziet dat er 3 stappen te volgen zijn. Ze herkent het apparaatje op de foto en uit de instructies concludeert ze dat het werkt als een PIN-automaat. Daarmee is ze al vertrouwd en dus zakt haar angst.

De metafoor van de pin-automaat wekt niet alleen vertrouwen: Olga hoeft nu ook niets nieuws te onthouden, zoals toegangscodes. Ze gebruikt wat ze al weet en voelt zich veilig.
Rondom het centrale blikveld staat nog wat vriendelijke tekst over haar veiligheid en eventuele foutmeldingen.

Simpeler is krachtiger

Programmeurs en technisch geörienteerde managers voelen grote aandrang erop te wijzen dat het scherm van de Postbank beslist “krachtiger” is. Er lijken – in een oogopslag – meer functies op te staan. De “domme” aanpak van de Rabobank is dus vast minder krachtig.

Welnu, dit is lariekoek:

1. Er staan precies evenveel links op beide pagina’s. (voelt niet zo hè?)
2. Rabobank toont alleen taakrelevante informatie
3. Rabobank voorkomt meer fout-scenario’s dan de Postbank (daarover zodirect meer)

Kortom: De “domme” site van de Rabobank is véél krachtiger dan de “krachtig” ogende site van de Postbank. En niet per ongeluk! Dat is de kracht van User Centric Design.

Simpel is goedkoper

De kosten van Internetbankieren per klant zijn veel lager dan persoonlijk contact met een bankmedewerker. Hoe meer uitzonderingssituaties het systeem zelf kan afhandelen hoe beter: zodra een persoon moet ingrijpen is dat kostbaar.
De Postbank koos (onbewust?) voor de Internetsitemetafoor: Bijna elke Internetapplicatie gebruikt een login naam en een wachtwoord ter authenticatie. De Rabobank koos de PINautomaatmetafoor. Het laatste is simpeler te gebruiken, maar hoe vergelijken deze keuzes in uitzonderingssituaties?

Wachtwoord vergeten?

Wanneer Olga haar wachtwoord vergeet, of 3 maal onjuist invoert, blokkeert de Postbank haar toegang. Daarop ontvangt ze per post een papieren afhaalbericht voor toegangscodes. Hiermee kan ze met haar legitimatiebewijs bij het Postkantoor, tijdens kantooruren, haar toegangscodes ophalen. Concreet betekent dit dat ze ongeveer een week geen toegang heeft. Als je tijdens kantooruren werkt is deze methode bijzonder ongemakkelijk voor je. Ik spreek uit eigen, drievoudige frustratie.

Olga heeft geen wachtwoord nodig voor de Rabobank. Dus ze kan het ook niet vergeten. Ze kan eigenlijk alleen haar “Random Reader” verliezen. Ze vraagt (online) een nieuwe aan en ontvangt die de volgende werkdag. In de tussentijd leent ze de RandomReader van haar zoon. Haar toegang is onverminderd actief.

De post- en verwerkingskosten van beide banken zijn gelijk. De Postbank maakt personeelskosten en dupeert de klant. De Rabobank informeert de klant en levert betere service zonder personeelskosten.

User Centric design gaat niet alleen over schermen van websites. UCD specialisten overzien de gehele gebruikerservaring en de procesketen. Dat kan u aardige kostenbesparing opleveren.

Feedback op software: vanzelfsprekend?

Hoe meer feedback op software (in ontwikkeling en in beheer) je geeft, hoe beter de programmeur de software kan “kneden” naar je wensen. Zonder die feedback, is het ontwikkelteam gedwongen te fantaseren over wat je wilt. En dat leidt tot sub-optimale resultaten.

Iedereen weet dat dit zo werkt, maar in de praktijk krijgen nog veel gebruikers iets anders dan ze nodig hebben. Als feedback dan zo goed werkt, waarom komt de feedback dan niet aan?
Nou, daar zijn redenen voor:

• Op het moment van signalering is er geen communicatiekanaal voor de feedback
• Directe communicatie is verboden/afgeremd, dit is via-via feedback
• Gebruikers zijn te bescheiden om feedback te uiten

Op elk van deze drie ga ik wat dieper in.

Geen communicatiekanaal als ‘het mis is’

Als je software pruttelt, of zelfs “crasht”, verrast hij je: Je bent ontdaan en weet je even geen raad. Snel daarna ben je woedend, omdat software de taak verstoort die je nu wilt volbrengen. Die taak is veel belangrijker voor je dan die software, dus vergeet je waarschijnlijk rustig je stappen na te gaan om te rapporteren wat er gebeurde: “Het rotding is fout, mijn werk is weg en nu moet ik ook nog extra tijd investeren in het opschrijven van wat er foutging? Het raam uit met die troep!”
Heel begrijpelijk, maar alléén die stapsgewijse beschrijving (feedback!) maakt de softwarefout herhaalbaar en die heeft de bouwer nodig om het op te lossen.

Zo’n gedetailleerde vastlegging van (verstorende) softwarefouten kent een technisch alternatief:  automatische crash rapportage. Een zelf-feedback-module in het systeem registreert wat je aanklikt en intypt. Als de software crasht stelt hij zèlf een stapsgewijs rapport op en stuurt dit direct naar de bouwers. Steeds meer software, zoals Windows zelf, heeft zelf-feedback ingebouwd.

feedback in 1 click: crash-rapport

Als software niet crasht, maar toch fouten maakt, weet de gebruiker niet aan wie ze de klacht kan richten. In het gunstigste geval komt de feedback tot de drukke afdeling automatisering: een notoir zwart gat. Het is zeldzaam als de bouwers er ooit van horen.

Laat voor deze feedback een feedbackformulier inbouwen, met uitleg over hoe men een schermfoto toevoegt. Elke gebruiker krijgt zo een direct communicatiekanaal naar de bouwers/beheerders. Nog mooier is het als gebruikers onderling elkaars feedback inzien, steunen en een dialoog ontstaat met de bouwers. (voorbeeld: UserVoice met een video-demo).

De uitdaging ligt dus bij progammeurs en opdrachtgevers: verwerk feedbackkanalen waarnaar de bouwers luisteren. Geef de gebruikers de mogelijkheid om zich te laten horen als het hèn uitkomt.

Verboden direct te communiceren: via-via feedback

Goedbedoelende managers kanaliseren soms feedback: “Alles gaat via mij.” In formele onderhandelingen is dat begrijpelijk, maar het is schadelijk om feedback op software te leiden via een tussenpersoon. Iedere tussenpersoon kleurt de boodschap verder. Het is wèl goed als iemand het overzicht behoudt en taken prioriteert, net zoals het ontwikkelteam niet rücksichtlos àlle feedback moet verwerken tot “verbeteringen”.
Het is pertinent verkeerd om de feedback te onthouden van de bouwers: kennisneming ervan voorkomt toekomstige fouten.

Met name het aantal keer dat dezelfde fout wordt opgemerkt is een graadmeter die verloren gaat in de ‘trechter’ van één tussenpersoon zonder industrieële softwaretestexpertise.
Stuur de ruwe feedback zowel naar de bouwers als naar iemand die overzicht houdt.

Bescheidenheid remt

Uw meest ervaren medewerker weet dat de optelsom die het ERP systeem oplevert niet klopt, maar ze zegt er niks over, want ze “weet niks van computers“. Zonder dat u het weet doet zij dubbel werk vanwege die softwarefout. Dit komt vaker voor dan u denkt! En dat is nog is maar intrinsieke bescheidenheid, er bestaat ook veel aangeleerde bescheidenheid:

Mussolini deed niet aan feedback

Mussolini-systeembeheerders hebben sinds jaar en dag patent op dictatoriale automatisering: Intussen is het normaal dat de printer het niet doet en dat je koffie kunt halen terwijl je je computer start. Desgevraagd vertelt Mussolini de “technische” reden die in de weg staat, die je alleen begrijpt als je zelf systeembeheerder bent. Gebruikers zijn geconditioneerd om hun feedback in te slikken.

Bouwers weten minder van de taak dan de gebruikers. Net zo min weet de baas het fijne van de taken op de werkvloer. Ontzag voor expertise (techneuten) en status (de baas) staan eerlijke feedback in de weg. Overtuig je medewerkers dus altijd dat hun inzicht klopt en dat software gebouwd wordt om hun taak te vergemakkelijken. Zwengel die discussie maar aan en geef elke domeinexpert het zelfvertrouwen dat nodig is om zijn bescheidenheid te overwinnen.

De volgende vraag dient zich aan als toegift: Als we de drie voornoemde feedbackblokkades wegnemen, krijgen we dan niet meer feedback dan we aankunnen?

Misvatting: teveel feedback

Soms zeggen mensen dat ze geen feedbacksysteem willen, uit vrees voor lawines feedback. Welnu, die angst is ongegrond.

Hoe vaak vult u zelf een online klachtenformulier in als u een spelfout ziet in een online nieuwsartikel? En hoeveel lezers zullen gebruik maken van het reactieformulier bij het artikel dat u nu leest? Laten we ons geen illusies maken: software interesseert de meeste mensen bar weinig. Slechts een enkeling is zo lyrisch/boos dat hij zich laat horen. Door de drempel voor feedback te verlagen, mengt zich hopelijk ook wat “normaler” publiek (in de statistische zin).

Maar stel dat je verzuipt in je feedback. Is dat een probleem? Als het positieve feedback is is iedereen dolblij. Als je lawines negatieve feedback verwacht, doe je sowieso iets fout. Dan is het maar goed dat je er van hoort.

Meer lezen?

Feedback als softwareverbeterinstrument is ruimschoots beschreven in de literatuur. Een toegankelijk startpunt is het boek Why Software Sucks, D. Platt. Platt suggereert om het niet bij feedback te laten, maar ook publieke vernedering van- en frontvorming tegen bouwers die niet luisteren in te zetten.

Anecdotes over Mussolinis (BOFHs) lees ik graag op de online verzamelplaats Worse Than Failure.

"Beste ___, 

mijn commentaar in jouw tekst, in rood".

Dit is niet alleen psychologische kwetsing van de ontvanger, het is ook crimineel: u pleegt fraude. 

Bovenal is elke e-mail een communicatie tussen mensen. Het grootste probleem is dus dat uw “commentaar in rood” vijandigheid oproept bij degene met wie u e-mailt. Daarnaast is het inefficiënt en tenslotte een vorm van fraude.

Vijandigheid? Alleen de juf mag schrijven met rood!

Rood is een alarmkleur. Hij trekt niet alleen de aandacht (gevaar/bloed), maar het is ook de kleur waarmee strepen gezet worden door onschuldige ideeën. De psychologische gevolgen van de rode correctiepen worden zelfs erkend op basisscholen: steeds minder meesters en juffen gebruiken een rode correctiepen.

We geven het niet graag toe, maar iedere kenniswerker reageert als een stier bij rood commentaar op eigen werk. Wie denk je wel niet dat je bent!?

Inefficiënt. Wie zei nou wàt?

“Mijn commentaar in jouw tekst” werkt maar één keer. Wanneer je e-mail conversatie in een groep mensen gevoerd wordt, dwingt men elkaar telkens nieuwe kleuren toe te voegen om zich te onderscheiden. In de regenboog van (vaak vloekende) kleuren is het snel niet meer duidelijk wie nu wàt zei. Met name degene die abusievelijk een te lichte kleur kiest, zal genegeerd worden.

Schrijven in mijn woorden is fraude

Door te citeren en het citaat aan te passen pleeg je plagiaat en verdraait de woorden, zonder toestemming van de zender. E-mail is tegenwoordig een gerechtelijk bindend “schriftelijk” medium. Door de nieuwe status van e-mail is mutatie van zulke tekstfragmenten eigenlijk fraude: Een citaat behoort men in tact te laten en te voorzien van een bronvermelding. Omdat op Internet veel e-mails verstuurd worden, is een tijdstip eigenlijk ook nodig in die bronvermelding.

Hoe moet het wel?

Sinds jaar en dag is er internationaal geaccepteerde netiquette: gedragsregels op Internet, onder andere voor e-mail. Het komt op het volgende neer:

1. Spring in, citeer met een duidelijke markering  ( ‘>’ ) van elke citaatregel en vermeld duidelijk de bron.

2. Stap 1 gaat automatisch. Klaag bij de leverancier van uw e-mail software als u niet weet hoe 

3. Gebruik een e-mail programma van hogere kwaliteit indien stap 1 onmogelijk is met uw software

Nog een laatste vuistregel: Het gebruik van kleur in e-mail dient alleen decoratieve doeleinden. Het mag niet de inhoud van de boodschap beïnvloeden.

Software verandert processen met tegenzin

Mensen veranderen hun gewoontes alleen als ze daarvan overtuigd worden. Mijn stelling is: Software overtuigt niemand, maar toch wordt nog te vaak software gebouwd die alleen goed werkt als iedereen zich in vergaande mate aanpast aan de bytes.

Voorbeeld: Telefoonrekening online (KPN)

KPN wil dat ik mijn telefoonrekening online lees en geen papieren afschriften meer gebruik. Het systeem wat ze bieden is frustrerend en onbruikbaar. Voor mij is dit achteruitgang. Ik vertik het dus. De ontwikkelinvestering in telefoonrekening online levert KPN daardoor beduidend minder op dan zij zou hopen, want ik ben lang niet de enige.

Waarom gaat het mis?

Waarom overtuigt software niet? Dat is een wat te filosofische vraag. Ik weet wel dat het ongekend veel moeite kost om een glimlach uit te lokken met software. Iemand werkelijk, inhoudelijk overtuigen van iets dat nadelige effecten voor haar heeft is oneindig veel moeilijker.

Desalniettemin gaat de bouw van maatwerksoftware vaak gepaard met wijziging van het bedrijfsproces. Ik classificeer de problemen daarbij in drie groepen Soms heeft de situatie aspecten van twee of meer van deze groepen. Ik geef ter verduidelijking een fictief voorbeeld voor elk.

1. Programmeurs zijn geen domeinexperts: Programmeurs ontwikkelen een gedetailleerd begrip van je processen en je administratie. Je mag niet verwachten dat ze de politieke verwikkelingen in je bedrijf precies kunnen duiden, tot het niveau waarop ze jouw werk zouden kunnen doen en ook nog programmeren!

   Concreet: Bouw van een intranet. De opdracht? “Verzuimoverzicht, grafisch“.
   Misser: Iedereen op de afdeling is woedend, want het nieuwe Intranet toont schaamteloos een grafiek van medewerkers die het vaakst ziek zijn.

2. Een uitzonderingsgeval bouwen kost evenveel als een “algemeen” geval. Ontwikkelaars sturen dus aan op eenvormigheid. Elk mens is uniek maar de software zal voor iedereen zoveel mogelijk hetzelfde zijn.

   Concreet: Bouw een telemarketing systeem. De opdracht? “Bij een marketingactie kan telefonist extra gegevens A1 t/m A34 invullen.”
   Misser: Boosheid alom. Het vastleggen van een telefoongesprek kost telefonisten 25 muiskliks méér dan in het oude systeem. Door die vertraging halen ze hun bonus bij 30 gesprekken per dienst niet meer.

3. De eindgebruiker is geen partij. Hij heeft geen zegje in de beslissing en niet in de beoordeling. Heel begrijpelijk, want vaak is de eindgebruiker niet eens verantwoording schuldig aan het bedrijf (zoals bij KPNs telefoonrekening online). Pure minachting van de gebruiker is daarnaast meestal de diepere oorzaak.

   Concreet: Urenregistratiesysteem introduceren. De opdracht? “Medewerkers worden verplicht hun urenverantwoording digitaal bij te houden, thuis via het Internet.”
   MIsser: Krassen in de Jaguarlak. Part-timers kunnen nauwelijks de huur betalen. Laat staan een PC.

Hoe moet het wèl?

Om terug te komen op mijn stelling: Software overtuigt niemand.  Als je je doelgroep wilt beïnvloeden, zodat ze zelf de nieuwe werkwijze gaat willen, kun je het best software bouwen die hen daarbij faciliteert aansluitend bij haar wensen. Het alternatief is dat jouw doelgroep je software negeert, of in opstand komt.

Voorbeeld: Online aangifte (Belastingdienst)

De Belastingdienst stimuleert burgers online aangifte te doen: Hun programma helpt je en leidt je door het proces (makkelijker), het programma schat het oordeel (ik weet wat ik zal moeten betalen of wat ik nog terugkrijg) en de definitieve aanslag komt sneller binnen (minder boeterente en onzekerheid).

Hoe boksten die “Niet leuker. Wel makkelijker.“-lui dat voor elkaar? Nou:

1. De applicatie is uitgebreid getest op domeinexperts, hun feedback is verwerkt
2. Programmeurs hebben de basisstructuur niet beïnvloed: Digitaal en papieren aangiftebiljet zijn hetzelfde gestructureerd.
   Merk ook op dat er geen structuurrestrictie is toegevoegd: In beide kun je secties invullen in willekeurige volgorde!
3. De belastingdienst erkende de ‘grillen’ van de gebruiker en faciliteerde die. Het online aangiftebiljet laat je experimenteren en het biedt bijvoorbeeld rekenhulp-modules. Aan die functies heeft de belastingdienst niets, maar ze investeert erin om blokkades weg te nemen bij de gebruiker.

Maar hier gebeurt iets opmerkelijks. Het hele proces van belastingaangifte is geleidelijk gedigitaliseerd. Eerst kwamen de bedrijven, toen enkele particulieren en tenslotte alle belastingplichtigen. Natuurlijk hebben individuen geprotesteerd en klachtenbrieven gestuurd, maar uiteindelijk is er geen escalatie geweest: geen nationale opstand, geen kamervragen, niks.
De besparingen voor de belastingdienst zijn enorm en ze hebben alle belastingplichtigen “overtuigd”. Dit is een zeldzaam fenomeen.

Dat ze soms een paar duizend aangiftes kwijtraken is een verbeterpuntje.

De belastingdienst heeft software ingezet als een veranderinstrument, maar het overtuigingsdeel hebben ze goed in de hand genomen. Het instrument zal nog steeds strubbelingen veroorzaakt hebben, maar die waren te overzien.