Opdrachtgevers raken altijd enthousiast en opgewonden van het idee dat alles straks met een druk op de knop geregeld is. Hun visie is gebaseerd op dat voornemen. Maar soms is dat niet optimaal. In zo’n geval loopt het raderwerkje in hun hoofd al snel volledig vast.

Met een druk op de knop

ITers automatiseren jouw functie weg waar je bij staat. Als opdrachtgever moet het lijken alsof er geen eind komt aan de mogelijkheden van automatiseren van hele ketens van bedrijfsprocessen. Je begint met het digitaal verwerken van de inkoopfactuur, maar als je de ITers hun gang laat gaan blijkt dat je je inkoopfacturen al digitaal kunt ontvangen. Nee, wacht! Je kunt het inkoopproces zèlf automatiseren op basis van de (te automatiseren) voorraadinformatie. En ga zo maar door…

Wat vroeger tijd, opleiding en een hoop papier kostte gaat nu sneller, goedkoper en is eigenlijk …best stoer! Al die grafiekjes op je scherm! Machtig spul, software. Alles geregeld met een druk op de knop.

De doe-wat-ik-wil-knop

Tijdens mijn informaticastudie volgde ik het college User Interfaces.

“De ideale user-interface heeft eigenlijk maar 1 knop, de doe-wat-ik-wil-knop.”

Professor Paul de Bra nam toen een gewichtige adempauze, keek met twinkelende oogjes het publiek in en liet ons zijn wijsheid op ons eigen tempo waarderen. Toen de meeste studenten begonnen te knikken in overeenstemming, ging hij verder

“Maar als het systeem dan zo precies weet wat ik wil, waarom moet ik dan nog op die knop drukken? Die knop is dan overbodig.”

Mijn ontwerp van de kinderversie.

Mijn scherm of jouw scherm?

Mijn klanten hebben meestal een toekomstvisie voor hun systemen rondom een soort gravitatiecentrum: hun eigen computerscherm.

En hoe kun je een ITprobleem binnen dat referentiekader anders oplossen dan door de toevoeging van een knop die je probleem oplost? Natuurlijk is “knop” wat te smal: het omvat ook dat extra rapport, de extra checkbox die je afvinkt, of dat nieuwe formulier (boven de knop) dat je online bezoekers laat invullen. Maar in wezen is dit hetzelfde: je lost het probleem op binnen een scherm, er zal iemand op klikken, in typen, of het zien op het scherm. Vervelend (invul-)werk schuift dan naar andermans scherm, leuke dingen zoals goedkeuring zijn welkom op ons eigen scherm. Software bouwen met de strategie van je one-night-stands. De hamvraag is: Wordt het op mijn scherm of op jouw scherm?

Headless killer-apps

Applicaties zonder scherm noemt men headless. Deze metafoor vindt zijn oorsprong in de opstelling van je desktopcomputer vroeger: de monitor (zo’n toeter) was altijd het rustende hoofd bovenop de schouders van je brommende computerdoos (desktop). Maar deze onthoofding is veel minder gruwelijk…

Het grootste deel van de ècht belangrijke, grootschalige applicaties zijn headless. Banktransactiesystemen, het WWW en eindeloze digitale infrastructuur zijn slimmer en nauwkeuriger juist doordat ze niet wachten tot iemand op het juiste moment op een knop duwt. Ze functioneren goed, zonder knop: je start ze op en ze blijven draaien tot de stroom uitgaat.
Vrij letterlijk zijn veel van deze headless applicaties zó belangrijk, dat ze killer apps genoemd mogen worden, als die stroom inderdaad uitvalt.

Extra scherm extra ballast

Minder risicovolle applicaties, zoals dat hippe, automatische teleconferentiesysteem, of dat evenzo gave projectplanningssyteem kunnen enorm baat hebben van zulke onthoofding. Door zo’n applicatie niet weer een nieuw, eigen gezicht (‘head’) te geven, maar het in de duisternis te laten werken, hoeven gebruikers niet ‘nog een nieuwe user interface’ te gebruiken, die niet werkt in hun InternetExplorer of waarvan ze de URL niet kunnen vinden.

Recentelijk ontwierp ik bijvoorbeeld een scherm waarop iemand een PDF kon downloaden, zoals de klant vroeg. De gebruiker zou de link naar dat scherm via e-mail ontvangen.
Uiteindelijk heb ik klant en gebruiker dat hele scherm bespaard: we hechten de PDF nu gewoon aan die mail!

Ik vergeet soms zelf voldoende afstand te nemen om op te kunnen merken dat je schermfuncties kunt weglaten. Maar vaker wìl de klant er gewoon niet aan: de radertjes in zijn/haar hoofd lopen vast als je het scherm uit het plan haalt.

Mashups in duisternis

Web2.0 was bracht ons Mashups: een nieuw schermpje door de koppeling van onafhankelijke, bestaande webapplicaties. Iedereen was er dolenthousiast over. Maar het koppelen is interessanter dan de mashups! Steeds meer bestaande applicaties faciliteren headless uitbreidingen. Zo kun je weer werk verzetten zònder dat iemand zich ermee bemoeit, in een soort digitale duisternis. Dàt is pas echt automatiseren: Zònder user interface werken systemen … vanzelf.

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

Het hoeft niet. Tegen een kleine investering irriteert u uw eigen webbezoeker/-klant niet meer. En het levert nog gigantische besparingen op ook.

Zet uw adres op de stippellijn

Het meest voorkomend gegeven dat ik invul op webformulieren is mijn e-mail adres. Grappig genoeg is dat dus ook meteen hetgeen dat ik het minst snel weggeef. En als ik het moet invullen vink ik vooral geconcentreerd de vinkjes “geen e-mail nieuwsbrief” aan. Maar dan komt de lol pas. Mijn postadres is ook een gewild informatie-item. Het kan meestal in het volgende vakje…

straat, huisnummer, postcode, woonplaats, toch?

Het adres bestaat in Nederland uit 4 onderdelen:

standaard adresinvoer

1. de straatnaam
2. het huisnummer, extra vakje voor de “toevoeging”
3. de postcode, meestal 2 vakjes, of 1 vakje waarbij de laatste letter net onleesbaar wordt
4. de woonplaats

Dus de standaard is dat ik 6 velden *verplicht invul om – schoorvoetend – mijn adres te geven. Telkens weer opnieuw. Het is geestdodende routine. En dan heet ik uit pure wanhoop al snel Donald Duck.

Soms wens ik  – gewoon voor de afwisseling – dat ik een postbus of een antwoordnummer tot mijn beschikking had, zodat 99% van de formulieren onbruikbaar zouden worden… Want er is minder aan een Nederlands adres, dan de “grote vier”.

fout! postcode en huisnummer

Afgezien van de telkens terugkerende ellende met het postcodeveld dat te klein is, of – vaker nog – te dom om te ’snappen’ dat ik met het menselijke “5612 WH” hetzelfde bedoel als “5612WH”, zonder spatie, wat schijnbaar de standaard is in computerland (of juist vice versa? Het is mij een raadsel), ziet adresformulier bouwend softwareland (waarde collega’s) een veel groter verbeterpunt over het hoofd: de postcode en huisnummer zijn je volledige adres:

1. de postcode, in 1 vakje inclusief letters: “5612 WH” en zonder protest ook “5612WH”
2. het huisnummer, in 1 vakje, dat eventuele toevoegingen negeert

Maak uw bezoekers blij en neem een (betaald) abonnement op een postcodetabel, er zijn vele aanbieders van. Ik tik mijn postcode en huisnummer en floeps! Mijn volledige adres staat ter controle op de site. Wat een heerlijk gevoel.

En contact met de aanbieder van zo’n tabel behoedt u meteen voor kopzorgen over Internationale adressen, want die ellende heb we nog niet eens aangeroerd. Het postcode + huisnummer concept werkt namelijk lang niet voor alle landen van de wereld. Een gespecialiseerde dataleverancier weet hoe het zit.

De bonus

Wilt u helemaal de blits maken en uw site-bezoeker een plezierig formulier bieden? Bouw het kreng dan niet zelf, maar hergebruik het beste formulier van een webservice, dat

• perfect omgaat met alle invoer-eigenaardigheden en
• minder Donald Ducks en Jan de Vriesen verwerkt, of ze eruit filtert
• netjes past in uw huisstijl en
• in alle denkbare talen vertaald is voor uw Internationale bezoeker.

Een kleine investering die zichzelf dubbel en dwars terugbetaalt in gewonnen merkimago en gebruiksgemak.

De jackpot: Standaard gegevensbronnen zijn te goedkoop om zelf te onderhouden

Postcodes zijn het topje van de ijsberg van gegevensbronnen die niemand in het dagelijks leven kan omzeilen. Naast het comfort, biedt een specialistisch gegevensleverancier informatie inzichtelijk en aantrekkelijk aan. Maar uw systeem wordt vooral beheersbaar: Onderschat niet de enorme administratieve last van het actualiseren van een persoonsbestand, voor welk doeleinde dan ook. Dat kun je tegenwoordig goedkoper uitbesteden dan zelf doen. Een klantenbestand van 1000 klanten actualiseren kan al voor €170,- Daar doe je het zelf niet voor.

De angst voor online gegevensbronnen is niet meer van deze tijd. Voor een prikkie zet u (of erger nog: uw concurrent) een leverancier in. Investeer dus niet àlles in het mooiste web-formulier, maar laat een restje om uw systemen te koppelen met zulke diensten.

• 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.

Tijdens mijn presentatie over User Centered Design, tijdens de klantendag beantwoorde ik die vraag als mijn eerste casus. In dit artikel zal ik hem nog even herhalen.
De eerste vraag die jij – de eigenaar van de blog-website – je waarschijnlijk stelt is “hoe vaak zou ik het zelf gebruiken?” En dat is meteen een slechte raadgever: software-ontwikkelaars, directeuren, marketeers, maar al te vaak neemt de beslisser zichzelf als maatgevend voor de gebruiker. Soms draagt iemand aan “ik ben zelf ook … en ik doe het zo … “, waarmee hij dan impliceert dat iedereeen het zo doet. Welnu, User Centric Design gaat uit van echte gebruikers.

En laten we eerlijk zijn. Hoe goed kennen we onze bloggebruiker?

We lezen slecht

Volgens recente onderzoeken lezen Internetgebruikers gemiddeld maximaal 20% van de woorden op de pagina. We nemen dus 20% van de aangeboden informatie daadwerkelijk tot ons. In de illustraties kun je zien wat we bekijken en wat we (ongeveer) zien.

wat je ziet

wat je waarneemt

Dat we slecht lezen is in dit geval trouwens gunstig voor Ryanair (zie rode letters centraal op de pagina).

We onthouden nog slechter

Een wachtwoord van een blog lijkt op je vaste telefoonnummer: je moet het weten, maar je traint niet elke dag je geheugen om het te onthouden.
Onderzoek toont aan dat 1 op de 4 willekeurige personen zijn eigen vaste telefoonnummer niet uit het hoofd kent. We onthouden die dingen niet meer. Nu denkt u: “Onze blogsite trekt vooral jongeren, die hebben nog jong en goed geheugen!” Maar helaas:

1. Jongeren onthouden minder datums en nummers dan 50-plussers. Ouderen hebben ten minste nog ooit echt dingen leren onthouden
2. Een steekproef onder de doelgroep (gadget girls) zegt: 2 van 3 meiden kent haar eigen telefoonnummer niet

He meid: Weet jij je eigen telefoonnummer?

70% van ons allen gebruikt namelijk een elektronisch geheugensteuntje, zoals een mobieltje, voor telefoonnummers en feestelijke data. Maar onze mobieltjes zijn niet zo handig voor onze wachtwoorden helaas…

Herinneringsfunctie de investering waard!

Je concurrerende blogsite Meebo ontvangt dagelijks 670.000 unieke bezoekers. Zij overwogen het linkje ‘I forgot my password’ weg te halen. Gelukkig telde iemand toen eens hoeveel bezoekers de functie gebruiken: 11.000 elke dag!
Voor Meebo is “Ik ben mijn wachtwoord vergeten” een extreem waardevolle functie: Haal die functie weg en na een week is zo’n 10% van de unieke bezoekers buitengesloten. Dat is catastrofaal voor een site die gefinancierd wordt met advertentie-inkomsten.

UCD steunt investeringsbeslissingen

User Centric Design omvat gebruikersonderzoek, zodat de investeerder/bouwer inzicht krijgt in de waarde van een functie. In gevallen zoals dit is dat soms goed te beredeneren en verrassend overtuigend.

De voorbeelden en cases die ik behandel zal ik, in groter detail, ook later toevoegen op dit blog. Maar de primeur is natuurlijk voorbehouden aan het publiek dat de moeite neemt om naar Amsterdam te komen!

Ik heb er zin in!

Hij geeft treffende voorbeelden van ‘foute’ dingen en luistert het geheel op met muziek. Een overtuigende presentatie met veel stand-up comedy!

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.