“Het Proces van de Creatie van de Gebruikerservaring:

Bij de creatie van een site of applicatie worden volgens mij (en volgens mij ook volgens anderen) steeds 6 stappen doorlopen. Het maakt niet uit of je iets volledig nieuws maakt dan wel iets bestaand verbetert.

Leer je gebruikers kennen

• Zoek uit wie de site/applicatie werkelijk gebruikt
  Dit doe je in het geval van een reeds bestaande site b.v. met online enquêtes
• Kom erachter waarom deze mensen de site/applicatie gebruiken
  Wat zijn hun specifieke noden/doelen/verlangens?
• Wat is het niveau van expertise van deze gebruikers?
  Kunnen ze goed overweg met complexe webapplicaties? Kennen ze het vakjargon van het domein?
• Hoe gemotiveerd zijn ze om uw site/applicatie te leren gebruiken?
  Kan je complexe features voorzien of zullen de gebruikers dan onverbiddelijk wegzappen?

Om hier achter te komen kan je:

• Mensen observeren in hun werkomgeving
  Terwijl ze b.v. de oude applicatie gebruiken
• Rechtstreeks of onrechtstreeks interviewen
  Je vragen gewoon stellen, face-to-face of via een equête
• Gebruikers een dagboek laten bijhouden
  Men noteert gedurende b.v. een week welke problemen men tegenkomt in de huidige site/applicatie (uiteraard vooral nuttig wanneer een bestaande site of applicatie wordt aangepast, minder interessant bij de ontwikkeling van iets compleet nieuws)
• Vergelijken met gelijkaardige sites/applicaties : hieruit ontstaan zowel alternatieve ontwerpideëen als nieuwe requirements
  Wat vinden de gebruikers van die reeds bestaande producten? Voorkom dat je hun slechte eigenschappen overneemt!
• …

Maar de bottomline is: maak contact met de gebruikers (ook wel ‘mensen’ genoemd)

De opzet

Nu je al die nuttige informatie over je gebruikers verzameld hebt, moet je op basis daarvan bepalen wat de opzet van de site/applicatie zal worden, b.v.:

• De gebruikers zijn geen experts in het domein → Voorzie wizards die hen stap voor stap begeleiden
  t.o.v.
  De gebruikers kennen het domein beter dan jij het kan leren kennen in je analyse → Zorg ervoor dat men zelf op elk moment kan kiezen hoe men te werk wilt gaan. Irriteer deze experts niet door hen te vangen in beperkende wizards
• Bij het surfen op een website zijn mensen typisch heel ongeduldig en zullen ze zeer weinig tijd spenderen aan het ‘leren omgaan met de site’ → Eenvoudige functionaliteit; heldere interfaces; ‘help’ wordt voorzien op de pagina zelf, …
  t.o.v.
  Een webapplicatie die men elke dag gebruikt mag een stuk ingewikkelder zijn → Voorzie complexe functionaliteit, geoptimaliseerd voor efficiëntie; externe documentatie is mogelijk …


Brainstorming is in deze fase een goede manier om tot design-alternatieven te komen


Concretisering

Zet deze opzet nu om naar concrete schermen en navigatie. Dit is de fase van het ‘papieren prototype’: een manuele schets van de toekomstige site/applicatie.

• Overleg op basis van dit prototype
• Pas aan
• Vraag de persoon die toevallig in je buurt rondloopt wat hij verwacht dat die knop daar doet
• Probeer uit welke van de verschillende design-alternatieven die persoon het snelst doorheeft

Dit prototype moet uiteraard niet per se op papier zijn. Het gaat erom dat het snel gemaakt en aangepast moet kunnen worden en gemakkelijk deelbaar moet zijn met teamleden, klanten, gebruikers. Papier is daarvoor meestal de beste manier.
Kies iets wat jou persoonlijk ligt.

Finalisering

Eenmaal het papieren prototype snor zit, maak je een dynamisch prototype.

Je stopt in deze fase best nog niet te veel tijd in het grafische design, maar een klein beetje design mag wel. Kleurencombinaties, groottes van knoppen… hebben immers ook hun invloed op de usability. Zo kan ook de klant b.v. nog zeggen dat hij dat groen op de site maar niets vindt, voor het door de grafici helemaal is uitgewerkt.

Momenteel ben ik gewonnen voor Mockingbird, een gratis prototyping tool. Prototyping gaat razendsnel en delen met klanten is geen probleem.

De kracht van Mokingbird ligt in zijn eenvoud. Als je grafische elementen in je prototype wilt opnemen is Mockingbird helaas te eenvoudig. In dat geval kies ik voor Pencil, een gratis add-on van Firefox. Het prototype is niet zo snel gemaakt als met Mockingbird, maar het is vrij dynamisch en je kan makkelijk grafische toetsen toevoegen.

Nog een raad: gebruik echte data en voorbeelden in het prototype (deze ken je uit je gebruikersonderzoek).
Want… je gaat dit dynamische prototype gebruiken in de gebruikerstesten, waar deze fase eigenlijk helemaal om draait:

De voorbereiding:

• Je bereidt enkele scenario’s voor die de testgebruikers zullen doorlopen
  B.v. voor een immosite: “U bent op zoek naar een huis in de buurt van Leuven voor een budget van om en bij de 70 000 euro. Go.”
• Je bereidt specifieke vragen voor die je aan de gebruikers wilt stellen
  “Wat verwacht u onder deze link te vinden?”
• Je zoekt representatieve gebruikers (mensen die je leerde kennen in de eerste fase). Meestal is 3-4 gebruikers per testronde voldoende.

De testen zelf:

• Je stelt de mensen op hun gemak. Je legt hen uit wat de bedoeling is.
  “U moet niet bang zijn om fouten te maken, integendeel, hoe meer fouten u maakt, hoe meer ik leer! De fouten die u gaat maken, zijn eigenlijk de fouten die ik gemaakt heb in mijn ontwerp.”
• Je helpt de mensen niet, je wilt er immers achter komen of ze het alleen afkunnen. Maar je blijft ook niet aandringen als men er niet uitkomt.
  “Oké, dat was inderdaad niet duidelijk. We hadden die functionaliteit onder deze knop verstopt, maar dat moeten we zeker veranderen!”
• Moedig mensen aan om luidop te denken
• Vraag na de test om algemene feedback en wat men van het onderzoek zelf vond. Er valt op alle vlakken nog zoveel bij te leren!

Achteraf:

• Gebruik de resultaten van de testen zo snel mogelijk (ze zitten nu nog vers in je hoofd). Pas het prototype zo snel mogelijk aan o.b.v. je nieuwe inzichten
• Usertest dit aangepaste prototype weer, en weer, tot het snor zit

Implementatie

Pas nu begint de eigenlijke ontwikkeling. Hierin ben ik voorstander van een beetje ‘agile’ werken (excuses voor de favo-term, maar ik ben er echt fan van):

• Op regelmatige tijdstippen laat je zien aan je klanten wat er al klaar is. Ja, ze hebben het prototype al goedgekeurd, maar het echte ding is toch altijd nog heel wat anders. Kort op de bal spelen is essentieel.
• Maar het belangrijkste op usability-vlak: Usertest zo snel mogelijk wat er al klaar is. Het geïmplementeerde product zal altijd nog iets anders zijn dan het prototype. Usertesten blijft dan ook essentieel. Kort op de bal spelen kan ook hier de kosten terugdringen.
• User test natuurlijk ook grondig de volledig afgewerkte site/applicatie. Pas op dit niveau kan je er echt zeker van zijn dat het allemaal goed zit.

Einde

Welk einde? Een goede website/applicatie wordt constant in het oog gehouden en bijgewerkt.

• De zoektermen die men in Google ingeeft kunnen in de loop van de tijd veranderen: blijf de analytics van je site monitoren.
• Maak gebruik van wat je site je kan leren: Waar zoekt men op in onze ‘search box’? Waarom vindt men dit niet via de gewone navigatie? Wijst het misschien op een usability probleem?

Nog meer weten over User Experience Creation en Usability? Lees dan de artikels in onze User Experience Blog.