Usability + Utility = Useful

Een tijdje terug heb ik de vraag gekregen om in mijn rol binnen mijn organisatie de usability van ons product te onderzoeken en te verbeteren. Utility hebben we allemaal wel in het vizier. We willen een product, proces of werkwijze die voldoet aan wat we moeten kunnen doen. Maar datgeen wat we kunnen doen in het systeem omdat het functioneel zo geregeld is, in hoeverre is het werkbaar en prettig voor de eindgebruikers? Een mooie vraag en reden om op onderzoek uit te gaan, want wat verstaan we eigenlijk onder usability?

Het vakgebied usability houdt zich bezig met de gebruiksvriendelijkheid van gemaakte dingen. In een ideale wereld wordt tijdens de ontwikkeling van producten, machines, gereedschap, processen en websites voldoende rekening gehouden met de beoogde gebruikers. Hoe toegankelijker en gebruikersvriendelijk een product is, hoe meer mensen er eenvoudig mee zullen kunnen omgaan.

Usability-vs-user-experience-01

Het internet biedt mooie informatie over wat usability is. Waar ik nieuwsigierig naar ben is hoe andere organisaties met dit belangrijke onderdeel omgaan. Hoe ga jij of jouw organisatie om met de usability wanneer er een nieuwe werkwijze of proces ingericht/bedacht moet worden?

1 like

Eigenlijk laat jouw afbeelding het al zienā€¦ Hoe gebruiksvriendelijker een proces is hoe breder de bereidheid en het draagvlak zal zijn om het te gebruiken.

Ik krijg vaak vragen over simpele online processen waarbij mensen direct het gevoel hebben tegen een muur aan te lopen, ā€œik snap het niet, het is mij niet helder wat ik moet doen, maar als ik nu hier klik wat gebeurd er dan?ā€. In mijn ogen is er dan niets mis met het proces, maar wel met de omschrijving of de look&feel van het proces.

Er zijn dan gewoonweg teveel opties of het proces is ingewikkeld omschreven. Terug naar de basis is dan mijn advies, begin bij het beginā€¦ tot het punt waar je het wel snapt en volgt en breidt dit dan weer verder uit.

In het geval van CRM is het dan bijvoorbeeld vaak het geval het systeem terug te dringen naar een ordinaire online kaartenbak, daarna koppelen we categorieƫn, daaruit volgen lijsten, die je exporteert naar externe systemen etc.

Wanneer je begint met autorijden stap je namelijk ook niet direct in een Ferrari :wink:

waar het inderdaad om gaat is wat je wilt. Hoe werkt mijn bedrijf, hoe lopen de processen en wat is de werkwijze of etiquette? Dat bepaal je eerst, daarna kijk je naar het systeem. Het is niet zo dat ieder CRM exact kan wat jij wilt, maar er is vaak wel een pakket onder de vele aanbieders van CRM, wat goed aansluit bij jouw usability wens.

De olievlek methode. Rustig een organisatie laten wennen aan inderdaad eerst de kaartenbak. En daarna gaan opschalen voor wie er aan toe is.

Want als gebruikers eenmaal blij zijn met het systeem en zien dat hun werkzaamheden worden ondersteund, dan is het makkelijker om ze verder op weg te helpen en dieper in het CRM te duiken door meer mogelijkheden te benutten.

Je creƫert dus eigenlijk een CRM-hiƫrarchie bovenop je bestaande organisatie: administrator, key-users, CRM-coƶrdinatoren per afdeling, en tot slot de gewone gebruikers die in feite alleen maar de kaartenbak vullen. Je hebt ze allemaal nodig.

Maar bovenal staat er wel een CRM-manager aan de lat die alles monitort, analyseert en stuurt.
Nietwaar @y.neuschwanger-kars?

@Lindsy.Bruin, @katja en @janbulthuis dankjewel voor jullie antwoorden. Wat ik vooral lees is het klein en simpel houden van je proces en vanuit daar uitbreiden. Dit klinkt voor mij theoretisch fantastisch, maar in de praktijk een werkelijkheid die ik persoonlijk zelden zie.

Wat ik zie is dat men begint met een CRM-systeem, maar nooit om enkel de klantgegevens vast te leggen, het wordt altijd aangeschaft met het idee een proces te ondersteunen, zoals verkoopkansen vastleggen of service-aanvragen te registreren. In de praktijk zie je dan zelfs dat gedurende het project er steeds meer dingen bijkomen, omdat dat toch wel handig is om nu mee te nemen. Ik kan me ook voorstellen dat wanneer je het als bedrijf het eerst heel klein zou opzetten het uiteindelijk veel geld en tijd gaat kosten om te implementeren. Daarbij kunnen we uiteraard het argument aanhalen dat wanneer mensen niet blij zijn met je systeem dit je ook geld gaat kosten, maar ik wil voor mijn vraag uitgaan van mijn dagelijkse praktijk en ben benieuwd hoe jullie daar de usability zouden opkrikken. Hoe zorg je ervoor dat een systeem goed geĆÆmplementeerd wordt en vooral gebruikersvriendelijk wordt ervaren als het niet zo kleinschalig als een kaartenbak wordt opgezet? Betrek je de eindgebruikers in je proces? En waar? Laat je ze iets vinden van de inrichting of niet? En als je dan een proces hebt ingericht en men snapt er niets van, wat dan? Hoe zorg je ervoor dat de 1-0 achterstand die je hebt gecreĆ«rd een 2-1 voorsprong wordt?

Het blijft beginnen bij de basis, echter wil dat niet zeggen dat men maanden in de basis moet blijven hangen. Een goede implement bereik je door gebruikers het nut en voordeel te laten ervaren en door goede kennis overdracht. Vandaar het klein beginnen, dan evalueren, daar komen vanzelf vervolgstappen uit. De volgende stap nemen, weer evalueren. Een systeem goed neerzetten (data die klopt, geen vervuilde bestanden meenemen) en ervoor zorgen dat men het systeem begrijpt en er dus makkelijk en efficiƫnt mee kan werken zorgt voor die voorsprong, vervolgstappen zullen dan namelijk als (bijna) vanzelf uit de eerste stap rollen.

Hoi Marloes, een interessant onderwerp. Mag ik vragen hoe je dit onderzoekt? Kun je daar iets over vertellen? Ben ik namelijk benieuwd naar.

Hoi Anne,

Leuk dat je dat vraagt!

Voordat ik iets meer vertel over hoe ik het doe, eerst een klein stukje informatie over waar vanuit dit is ontstaan.

Ik onderzoek de usability vanuit leveranciersperspectief. Dit werkt in mijn optiek wat anders dan wanneer je CRM implementeert in je organisatie. Dan is het mogelijk om het heel klein op te zetten en vanuit daar verder te bouwen. De situatie waar vanuit ik werk is dat we klanten hebben die al jaren klant zijn en ook al jaren met ons product werken. Ons product bestaat uit drie lagen, waarbij een laag onze laag is. Dit is de laag die we onderzoeken voor onszelf m.b.t. usability. Het mooie hiervan is dat meteen de overige lagen aangeraakt worden en de klant hier ook profijt uit kan halen.

Wij hebben besloten als leverancier en ontwikkelaar van ons product om de eindgebruikers meer te betrekken bij de doorontwikkeling. Zij zijn degene die er mee werken en het prettig in gebruik moeten vinden. Wij als leverancier kunnen bedenken dat het logisch is om een knop ā€˜Bevestigenā€™ te noemen, maar eindgebruikers kunnen daar heel anders over denken en vinden de term misleidend en zouden intuĆÆtiever ermee kunnen werken als het ā€˜OkĆ©ā€™ zou zijn. Naar dit soort informatie zijn we op zoek, functionaliteiten die er zijn, maar beter kunnen in functionaliteit, design, logica etc. en ook naar functionele behoeften.

We pakken dit als volgt aanā€¦ We gaan langs bij onze klanten die bereid zijn om hierin mee te denken, want het vraagt tijd van de klanten. Van tevoren neem ik contact op met de klant om duidelijk uit te leggen wat de bedoeling is van de sessie. We vragen ook aan de eindgebruikers om alvast na te denken over verbeterpunten. Hierbij ook het handvat om bij een benoemd verbeterpunt ook te formuleren wat dan de gewenste situatie moet zijn, dit om te voorkomen dat het een soort klaagsessie wordt i.p.v. een constructieve sessie. De sessies bestaan uit kleine groepen (maximaal 6 personen) zodat er een dialoog ontstaat. Deze groepen willen we het liefst zo divers mogelijk hebben, dus denk aan een veel-gebruiker, positief-kritische gebruiker, incidentele gebruiker, iemand die negatief tegenover het product staat, etc. Zodat er met verschillende brillen naar het product gekeken wordt. Gebruikers brengen input in en vanuit daar start het gesprek om boven te halen wat de eindgebruiker daadwerkelijk wil en ook de beweegreden erachter. Op die manier krijgen we niet enkel praktische input voor de doorontwikkeling, maar ook een beter inzicht in de denkwijze van de eindgebruiker. Wat voor mij persoonlijk heel waardevol is, want je merkt toch dat je anders kijkt naar het product doordat je er dagelijks mee werkt en de ins en outs weet.
Alle input verzamelen we en houden we bij in een bestand. Op dit moment is dit ook nog de fase waar we inzitten, dus het verzamelen van input. De volgende stap is als de eerste ronde usabilitysessies voorbij zijn om te inventariseren wat geroepen is bij de verschillende klanten en te kijken naar mogelijkheden en in hoeverre het past binnen onze eigen oplossing. Vanuit daar gaan we door ontwikkelen en de nieuwe functionaliteiten/design/etc. meenemen in nieuwe updates. En wat mij betreft start er dan weer een nieuwe ronde en wellicht dat die er wat anders uit gaat zien, maar het idee is om de communicatiestroom met de eindgebruikers intact te houden, zodat ze een korte lijn houden met mij en ik weet wat er speelt bij de eindgebruikers.

Dank voor je uitgebreide antwoord.

Lijkt me een ontzettend interessant proces om mee te maken. In mijn vorige baan was ik, als eindgebruiker, betrokken bij het testen van een nieuw systeem. In dat geval was het een systeem dat ontwikkeld werd voor onze afdeling en het oude systeem zou vervangen. Wij zijn gestart met testen begin 2014 en toen ik het bedrijf verliet eind 2016 waren ze net aan het overstappen op het nieuwe systeem :smiley: Zo zie je maar weer, een systeem bouwen is niet 1, 2, 3 gedaan.
Ik vond het erg leuk om bij de ontwikkeling betrokken te zijn. Je leert veel over hoe het in zijn werk gaat zoā€™n implementatie en wat dat allemaal met zich meebrengt. Tevens is het voor de acceptatie van het systeem een uitstekend middel. Onze eindgebruikers fungeerden dan ook als ambassadeur binnen hun team.

Ik ben benieuwd hoe het proces bij jullie verder verloopt na het verzamelen van alle input.