Ik geef je weeral eens gelijk op quasi alles (ik ben het alleen niet eens over wie nu de beste usability expert van het universum is :p).

Soms zijn die richtlijnen genadeloos verkeerd, gedateerd, of uit zijn context gehaald en niet toepasbaar op de applicatie in ontwikkeling. Het vraagt echt wel wat ervaring en kennis om te weten wat je waar en wanneer kan gebruiken.

Soms kunnen dingen feitelijk inderdaad wel juist zijn, maar daarom is dat niet de beste keuze.

Een klein voorbeeldje: kleurcombinaties voor tekst. Groene tekst op een gele achtergrond worden door mensen als één van de lelijkste keuzes aangeduid, terwijl ze daar wel het meest performant (hoogste leessnelheid, minste leesfouten, minst vermoeiend, …) op presteren. Er is een cognitieve psychologische uitleg voor waarom dit zo is, maar die zal ik u besparen.

Bottom line is: als je altijd en overal groen op geel gaat gebruiken, dan ga je veel mensen wegjagen, want ze vinden het écht wel lelijk, daar gaat je conversie dus. Je kan die specifieke combinatie wel gebruiken, maar alleen onder bepaalde voorwaarden.

Ik vind die usability richtlijnen, guidelines en patronen wel belangrijk, maar niet het belangrijkste. Die zijn gewoon een onderdeeltje van een goede usability methodologie.

Dave,

Hoe groot is de kans dat je aan iets compleets vernieuwend mag werken? Die is zeer klein. Meestal bestaat het al of is er een variant en soms heb je gewoon toevallig dezelfde doelgroep zoals bij applicatie of website X.

Zoals Karl aanhaalt: bekijk eens hoe ze reageren op vergelijkbare software of websites.

En stel nu dat het echt nieuw ‘nieuw’ is, zelfs in dat geval kan je een heleboel parameters over je doelgroep gaan invullen.

Via case studies, interne informatie (marketing, verkoop, de chef van de gebruikers , subject matter experts e.a. kan je alvast een heleboel zaken invullen, zoals:

• Gaan ze het frequent gebruiken? En hoe zit die gebruiksfrequentie specifiek in elkaar (7 dagen op 7, 8 uur per dag of 1 keer per jaar? Tussen die 2 uiterste heb je nog boeiende variaties zoals elke dag maar wel exact één keer.
• Hoe belangrijk is hun taak? Kunnen ze zichzelf of anderen ermee in de problemen brengen?
• Zijn ze verplicht het te gebruiken of hebben ze een vrije keuze?
• Hebben ze weinig of veel ervaring met software of websites in het algemeen?
• Hebben ze weinig of veel ervaring met gelijkaardige dingen (concurrentie, een vorige versie, …)?
• Hoe zit het met hun werk of taak ervaring?
• Hoe is hun houding t.o.v. die software? Kijken ze er naar uit of zijn ze bang dat ze hun job gaan verliezen?
• Wat is hun achtergrond qua onderwijs?
• Kunnen ze goed overweg met een toetsenbord?
• Is er veel personeelsverloop?
• Zijn het vooral mannen die het gaan gebruiken? (Neen, ik ben geen seksist)
• Wat is de leeftijdscategorie?
• …

Die gegevens (en nog een hoop andere zaken) kan je met een beetje research echt wel gaan samenstellen. (Opgelet! Niet alle vragen in bovenstaand lijstje zijn van toepassing voor uw project!)

Soms kan je in het begin niet alles weten en soms ga je met volgende iteraties of versies over meer background beschikken. Dan kan je dat gebruikers profiel beter aflijnen en indien nodig andere zaken bijstellen (usability doelen, de prototypes, …)

Je kan niet alleen peilen wie de vermoedelijke gebruiker is, je kan ook uitzoeken waar en hoe hij die applicatie of website gaat gebruiken.

Indien het mogelijk is en wanneer het nodige budget voorhanden is, kan je dat allemaal nog beter in kaart brengen door het feitelijk te onderzoeken (enquêtes, contextuele taak observaties, samenstellen omgevingsprofielen, etc…)

Al die zaken bepalen in grote mate hoe de applicatie of website zich zou moeten presenteren. Je kan usability doelen formuleren en later tijdens het testen afwegen of de onderdelen van het prototype die usability doelen ondersteunen of niet.

Dave

2 zaken die wij in dat geval aanraden:

• Vergelijkend onderzoek
  In plaats van enkel zelf te kijken naar wat anderen doen, kan je mensen die tot je doelgroep behoren eens naar die sites laten surfen en en hen opdrachten laten uitvoeren. Kijk wat ze spontaan doen, wat ze goed en minder goed vinden, wanneer ze zuchten en wanneer ze lachen. Vraag zeker ook specifiek naar die dingen die je zelf waanzinnig cool vindt, om te zien of uw mening overeenstemt met het daadwerkelijk gebruik door uw potentiële klanten.
  (Je wil niet weten hoe vaak wij bedrijven zien die slechte ideeën van anderen kopiëren en de goede dingen laten liggen omdat ze het ‘zelf maar niets vinden’).
• Test vooraleer je begint te coderen
  Eens je bijvoorbeeld de navigatiestructuur en mock-ups hebt uitgewerkt, kan je deze ook voorschotelen aan mensen uit uw doelgroep. Beter in zo’n vroeg stadium tekorten ontdekken dan nadat uw website live staat. Goedkoper om op te lossen (er is nog niets gecodeerd) en iets beter voor uw imago.

Allemaal varianten op de klassieke gebruikerstest dus, de beste uitvinding aller tijden. Oké, het vuur en het wiel mogen er ook zijn. Maar wedden dat die zijn ‘geperfectioneerd’ door iets dat ook lijkt op gebruikerstesten?

Eigenlijk komt het er op neer om de juiste bronnen te vinden, en die hangen vaak samen met de juiste partners vinden.

Een goed netwerk is van levensbelang als je gefundeerde projecten wil realiseren. Zo kan je ‘pin-pointen’ en zowel pro-actief als retro-actief de klant begeleiden in het ontwikkelingsproces.

Organisaties als feweb (http://www.feweb.be/) zijn daarbij erg belangrijk.

(PS: Geen sluikreclame)

Dave