Toch een kanttekening bij puntje 8, het werken met een pool gebruikers.

Ik zeg niet dat het niet werkt, ik heb het trouwens ook al gedaan. Maar er zijn wel wat valkuilen.

• Je hebt het risico, dat hun chef zijn favoriete onderdanen stuurt naar de meeting (of juist niet, omdat ze moeilijk gemist kunnen worden).
• Die gebruikers moeten mondig zijn, in Nederland zal dat minder een probleem zijn, in België ga je toch wel regelmatig op stille muurbloemetjes botsen.
• Er moet een milieu aanwezig zijn binnen de organisatie waar kritiek spuien mag en kan. Bij een organisatie die bijvoorbeeld bezig is met een grote reorganisatie gaan er maar weinigen hun nek uitsteken. Ze gaan de controverse uit te weg en die wil je misschien nét horen.
• Met zo’n pool moet je rekenen op het lange termijn geheugen van de gebruikers. Dat is niet feilloos.
• Ze vertellen niet alles wat ze doen. Soms omdat ze niet willen of durven, soms omdat ze er niet aan denken.
• …

Er gaat niets boven deze gebruikers zelf te observeren in hun eigen biotoop. Daar zijn hun gedragingen het meest natuurlijk en zullen ze veel meer laten zien dan ze zelf kunnen vertellen.

Maar goed, ik weet ook wel dat contextuele taak analyses niet altijd kunnen (budget, veiligheidszaken, budget beperkingen of het bedrijf in kwestie wil er niet van weten wegens te, uhm, ‘nieuw’ … )

Ik denk dat je bedoelde “NIET écht kennen” ipv “écht kennen”.

Ik volg wel dat er meerdere manieren zijn om tot een doel te komen. Het hangt ook allemaal af van de aard van het project, de belangrijkheid, het protocol in het bedrijf of organisatie, het aantal gebruikers, de beschikbaarheid van de team (en andere) leden en last but not least: het budget.

Ik volg ook niet altijd de ‘ideale’ weg: research -> conceptueel model maken -> testen -> basis prototype ontwerpen -> testen -> finale prototype ontwerpen -> testen -> source code laten schrijven.

Deze weg is niet goedkoop, kost wat tijd en is niet voor elk type project nodig of mogelijk.

Persoonlijk hou ik er wel niet van om te starten en wel te zien waar ik uitkom. In mijn nederige opinie is er altijd een kritische massa aan research nodig. Maar goed, ik ben niet echt een grote fan van XP achtige toestanden (wat niet wil zeggen dat er niets goed in dat concept zit).

Ene Gilb heeft eens gezegd dat als een usability wijziging in de ontwerpfase $1 kost, deze $10 kost in de ontwikkelfase en zelfs $100 moet kosten na aflevering van het systeem. Ik heb al ondervonden dat het niet overdreven is.

Voer je die kritische massa aan research niet uit, dan loop je het risico dat de programmeurs onnodige of verkeerde source code gaan schrijven. Het is duurder om functionaliteit te programmeren dan deze even uit te tekenen in een concept of een prototype.

Er is ook een psychologische factor: het dumpen van een prototype (of een gedeelte ervan) wordt veel gemakkelijker aanvaard door het team. Source code dumpen, waar ze weken en zelfs maanden aan gewerkt hebben, is niet alleen een kostelijke affaire het zal veelal tot wrevel en fricties leiden binnen het team.

Het komt ook de leesbaarheid van de code ten goede. Als je constant wijzigt en schrapt, door wijzigende functionaliteit en requirements, dan zit je code dikwijls vol hacks en workarounds, wat dan weer repercussies heeft voor het onderhoud later.

Een ander gevaar is, dat ze het gewoon zo laten. Ook al weten ze dat het niet in orde is. Ze vinden het gewoon zonde om de investering te vernietigen en nieuwe code schrijven kost ook geld.

Wat het Fusion Usability Recept betreft: zeker komen kijken en kritiek geven!

Je hebt gelijk dat veel organisaties hun doelgroep écht kennen en begrijpen en dat dit een risico is voor een agile aanpak. Ik denk wel dat er meerdere manieren zijn om hiermee om te gaan en dat de keuze tussen agile, waterval en een mengvorm van meer factoren afhankelijk zijn.

Je kunt inderdaad meer user research vooraf doen, zoals je voorstelt. Je zou ook de doelgroep meer in het proces kunnen betrekken. In het opvolgartikel vermeld ik tips van Jeff Patton om op regelmatige tijdstippen een pool van gebruikers te betrekken bij user research en usability testing.

In ieder geval ga ik je Fusion usability recept eens goed bestuderen.

Dat is nog altijd best hoog.

Het IE6 marktaandeel is in Azië (23,67% én marktleider) en Afrika (25,21% én marktleider) zelfs nog veel hoger.

Bedrijven die IE6 niet meer gaan ondersteunen en veel klanten in die regio’s hebben, kunnen dus straks op ernstige problemen rekenen.

Maar goed, niemand zegt dat we die IE6 eeuwig moeten blijven ondersteunen.

Misschien moeten de grote browser jongens maar eens een beetje overeenkomen om een volgende ‘IE6 debacle’ deskundiger op te lossen.

Eerst en vooral: soms kom je al eens een blog of website tegen over usability die de moeite is. Deze is er zo ééntje. Hij krijgt dan ook een plaatsje op mijn site.

Ik heb wel wat ervaring met Agile achtige modellen. In organisaties die héél zuiver zo werken, kan je niet op een ernstige manier aan usability doen. Tenzij het om zeer kleine projecten ging, was de usability niet op maat van de gebruiker, zijn taak en zijn omgeving.

Het probleem ligt voor een stuk bij één van de Strengths van je SWOT analyse van een Agile benadering:

“Klanten die de wensen en behoeften van hun gebruikers kennen en begrijpen.”

Dat is in de praktijk een zeldzaam gegeven. Weinigen geven gewoon toe dat ze hun gebruikers niet kennen en begrijpen, de meeste zeggen dat ze dat wél doen, maar in mijn praktijk blijkt dat ze het zelden echt weten. Vooroordelen en misvattingen zijn eerder legio.

Als je niet weet WIE de gebruiker is, WAT, HOE en WAAR hij zijn taken uitvoert dan kan je geen software (website of applicatie) afleveren op maat van die gebruiker.
Dan is die software op maat van de programmeur, zijn omgeving en zijn interpretatie van de taken van de gebruiker. Wat je dan ook kan merken in pakweg 80% van de software in omloop.

Slimme organisaties en bedrijven zien dat wel in en gaan Agile mengen met waterval.

Zo’n mengvorm verenigt het beste van die 2 werelden. Ik ben zelf bezig met zo’n methodologie: http://usability-vlaanderen.blogspot.com/2009/04/het-fusion-usability-recept_10.html

In het kort:
Ik verzamel eerste een kritische massa aan gegevens over de gebruiker, zijn taak en omgeving, destilleer hieruit de usability doelen en hierna ga ik op een Agile achtige wijze te werk bij het ontwerpen van de feitelijke user interface.

Belangrijk is dat de software architecten pas beginnen wanneer het conceptueel model is afgerond, de programmeurs starten pas na aflevering van een getest prototype. Wat uiteraard niet wil zeggen dat de usability mensen eerst ALLES moeten afronden nog voor de anderen aan de slag mogen.

Daarna kunnen de software architecten en programmeurs zoveel ‘Agilen’ als ze zelf willen.

game videos downloads funny download.

Ik zou graag, voor mijn collega’s, verwijzen naar dit artikel, maar vele van hen begrijpen geen Nederlands.

Is het mogelijk om, in ieder geval voor de conclusies, een Engelse vertaling te leveren?

Oftopic: Is er een reden waarom Website als Web Site geschreven is?