Exact Tafelruimte Professional

Uw bedrijf opereert elke dag op het scherpst van de snede in een competitieve markt. Daarom leveren wij speciaal voor uw dagelijkse bedrijfscoördinatie het kwaliteitsmateriaal dat aansluit bij uw eisen.

U betreedt uw kantoor door de deurklink omlaag te drukken, onze tafels zijn te plaatsen in alle ruimtes achter deurklinken van industrieel kwaliteitsnivo. Heeft u een klassieke of zelfs modernere RVS deurklink? Geen probleem, onze tafels ondersteunen het!

Exact tafels kunnen staan in werkruimtes mèt en zonder airconditioning, op alle soorten projecttapijt, plavuizen en zelfs granieten siervloeren. Onze ontwerpers kunnen bogen op vele eeuwen onderzoek en gravitatietoetsingen.

Exact tafels zijn regelmatig gehoekt, waardoor u ze eindeloos kunt combineren met een gepatenteerd efficiënte oppervlakbezetting.

Exact tafels zijn een fortuin waard, want u kunt eraan gaan zitten en de beslissingen nemen die u een voorsprong op uw concurrentie doen behouden.

Add-on modules

Bij aanschaf van een Exact tafelpakket, kunt u 4 van onze add-on modules tafelpoot toevoegen voor een vrijwel letterlijke verhoging van uw gebruiksgemak.

Een tafelkenner zou lezen:

Rechthoekige, loodzware tafels zonder poten.

Exact maakt vast prachtige producten, maar dàt doet IKEA ook. Bij die laatste snap je tenminste uit de brochure wàt ze verkopen.

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

Ik heb er nooit bij stil gestaan dat voor onvriendelijke software een markt bestaat, mits het maar onvriendelijk genoeg is. Dilbert bracht dit idee aan het licht…

despondency: wanhoop
self-mutilation: automutilatie

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!

Zoals te lezen was in de artikelen over smeerpaté,

• aanleiding: brief aan Zwanenberg Food Group
• reactie 1: brief terug van Zwanenberg Food Group

heb ik me het lot aangetrokken van caloriebewuste smeerpatéliefhebbers die de verpakking niet openkrijgen door een te sterke sealfolie.

Na de eerste reactie had ik niks meer verwacht van Zwanenberg, de brief was geschikt geweest om op een nette manier van me af te raken. Maar vandaag – tot mijn verbazing – ontvang ik een follow-up:

Betreft:onze smeerpaté-kuipjes hebben een verbeterde opening!

Geachte Dhr. F. Ogg,

ze weten nog hoe ik heet! Maar het gaat nog verder!

In het afgelopen jaar heeft u een van onze 'smeerpaté in kuipje'
producten gekocht waarbij de sluiting van de folieniet optimaal
was. Deze was zeer moeilijk te openen. De afgelopen periode hebben
wij .... probleem ... verholpen Hiervoor hebben wij onze sealmachine
verbeterd.

Wat een helden. De sealmachine zèlf maarliefst. Ze hebben de gereedschapskist erbij gepakt en elke nacht – want overdag staat de machine aan – eronder liggen sleutelen om speciaal voor mijn kuipje het sealproces te perfectioneren.

Dat was genoeg geweest. Ik huil tranen van blijdschap. De wereld is beter geworden. Als ik morgen sterf heeft mijn leven zin gehad. Ik heb niets meer nodig. *snif* Een dankbare stilte maakt zich van mij meester.

Maar wacht… er is meer …

Omdat de klant centraal staat ... wanneer u ons product wederom aanschaft

- hij moest eens weten. Ik eet mijn leven lang niks anders meer!

en de kassabon met uw rekeningnummer ongefrankeerd naar ons stuurt
zorgen wij ervoor dat het aankoopbedrag ... wordt teruggestort....
willen we u graag bedanken voor het feit dat u dit verbeterpunt bij
ons kenbaar gemaakt heeft. Hierdoor kunnen we onze producten blijven
verbeteren.

Alsof ik de postcode-kanjer-straatprijs win. Ik schreeuw het uit. Al het goeds in de wereld komt samen onder mijn voeten. Dit is het smeerpaté-walhalla.

Maar er is een les hier

De werkelijke winnaar is Zwanenberg. Ze hebben er niet alleen alles aan gedaan om hun product gebruiksvriendelijker te maken, maar ze doen het met betere service dan ik zou verwachten van zo’n massaal, industrieel vleesafvalverwerkingscentrum. En dat siert ze.

Eind goed, al goed. Voorlopig richt ik me weer op gebruiksvriendelijkheid van software.

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.