HomeOntwikkeling ❱ Stevige ontwerpfout gemakkelijk te voorkomen

Stevige ontwerpfout gemakkelijk te voorkomen

In dit artikel laat ik je een ontwerpfout zien in een stemwijzer van de waterschapsverkiezingen, die gebruikers niet alleen in de war brengt maar mogelijk zelfs het stemadvies beïnvloedt. Ik deed een eenvoudige gebruikerstest op straat en maakte een simpel prototype, om aan te tonen hoe gemakkelijk jij dit soort fouten kunt voorkomen in je eigen software, (web)app of formulier.

Het is het jaar 2019 en ik besluit de MijnStem stemwijzer van de waterschapsverkiezingen in te vullen (ook beschikbaar voor Provinciale Staten en eerder voor GR2018 en TK2017). "Wat er toen gebeurde zal je versteld doen staan..." ;)

Denk je nu: de tijd van clickbait-grapjes hadden we toch wel gehad? Misschien heb je gelijk. Maar ter mijn verdediging: ik dacht dat de tijd van het lettertoetsenbord voor numerieke velden ook wel achter ons lag:

Stemwijzer

Goed, het toetsenbord is natuurlijk niet het onderwerp van dit artikel. Ik noem het omdat het volgens mij veel zegt over het gebrek aan aandacht van deze stemwijzer voor gebruikersvriendelijkheid. En omdat het mijn professionele voelsprieten activeerde (straks meer daarover).

Heb jij je aanmelding of registratie proces, dus de superbelangrijke transformatie van anonieme bezoeker naar lead of klant, goed op orde? Dit soort fouten kan je tot bijna 50% in klanten kosten (blijkt uit vele voorbeelden en onderzoeken, b.v. Bank of America verbeterde in 2018 d.m.v. prototyping de usability van hun aanmeldingsproces en zorgde voor een bijna verdubbeling).

De ontwerpfout

Het probleem in deze stemwijzer waar ik het over wil hebben is wat geavanceerder. Dit is de situatie: je doorloopt met de stemwijzer een aantal stellingen en per stelling geef je je standpunt, van "helemaal eens" tot "helemaal oneens" (je kent het vast wel).

Zo hebben ze dit uitgewerkt:

Stemwijzer

Elke stap laat één stelling zien, met daaronder een schuifbalk met een handje als aanwijspunt. Het handje staat standaard in het midden (ik vermoed neutraal, hoewel dat niet is aangegeven). Je kunt het handje vastpakken en naar links (eens) of naar rechts (oneens) slepen.

Functioneel gezien zou ik altijd gaan voor radiobuttons van laag naar hoog, zonder standaardselectie - een oplossing die ook naar voren kwam in een gebruikerstest (zie verder). Maar voor de schuifbalk is niet voor niets gekozen, aldus de makers:

"MijnStem.nl nodigt kiezers én partijen uit nuancering aan te brengen in hun antwoord, in plaats van alleen eens/oneens/weet niet aan te klikken. Bij elk van de 22 stellingen bepaalt de gebruiker van MijnStem.nl met een slider de eigen positie. De resultaten worden berekend door de relatieve afstand tussen de eigen positionering en die van de partijen te meten. Door de brede schaal worden verschillen tussen partijen duidelijker zichtbaar dan in andere stemhulpen."
- bron

Ergens halverwege de stellingen gebeurt het: ik heb een neutraal standpunt, dus ik laat het handje in het midden staan en druk op volgende. Ik verwacht naar de volgende stap te gaan, maar in werkelijkheid gebeurt dit:

Stemwijzer

Wat is jouw reactie als je dit ziet? (neem even de tijd en lees daarna verder)

Ik dacht meteen: "JA natuurlijk wil ik het midden kiezen, waarom vraag je niet gewoon of dat de bedoeling is ja/nee?"

Het is begrijpelijk dat de stemwijzer wil voorkomen dat je per ongeluk te snel op [Volgende] klikt. Maar de instructies om een neutrale mening te kiezen zijn wel erg omslachtig. Dit deed me denken aan die goeie ouwe postcode verificatie:

Er is een leuk voorbeeld dat ik vaak noem als voorbeeld van gebruikers(on)vriendelijkheid, een postcode veld dat je een paar jaar geleden regelmatig zag: als je "3522AB" invult dan meldt de site "Postcode moet een spatie bevatten". Waarop elke gebruiker denkt: "ALS JE KUNT ZIEN DAT 'IE ONTBREEKT, ZET HEM ER DAN ZELF TUSSEN!".

Laten we eens kijken wat dit nu precies betekent voor het selecteren van je (neutrale) mening:

  • Bij elke nieuwe stelling wordt de schuifbalk in het midden neergezet (standaardwaarde).
  • Schuif je de balk naar links, of naar rechts, dan kun je met [Volgende] door naar de volgende vraag.
  • Is je mening neutraal, dan kun je níet met [Volgende] door naar de volgende vraag.
  • Je moet dan de schuifbalk eerst naar links of rechts schuiven en daarna weer in het midden zetten.
  • Er is dus wél een standaardwaarde, maar die kun je niet zomaar kiezen: je moet de waarde eerst verhogen of verlagen en dan weer terugzetten.

Dit is niet alleen maar onhandig - het is een fout

Als gebruiker kun je deze melding afdoen als 'onhandig' en de instructies braaf uitvoeren, maar in werkelijkheid heeft dit enorme gevolgen voor hoe de stemwijzer functioneel werkt. Je krijgt instructies om je invoer eerst aan te passen en daarna weer terug te zetten. Dit is niet alleen onbeschoft naar jou als gebruiker, het zorgt gegarandeerd ook voor verwarring en invoerfouten.

Mij lijkt het redelijk om te verwachten dat hierdoor:

  • sommige gebruikers denken dat de schuifbalk altijd links of rechts moet (neutraal kan niet)
  • sommige gebruikers de schuifbalk gewoon iets opschuiven
  • sommige gebruikers de schuifbalk opschuiven en terugzetten, maar nét niet in het midden

Alle drie deze gevolgen kunnen cruciaal zijn voor het stemadvies, omdat ze onbedoeld de invoer van de gebruiker veranderen. Het feit dat deze constructie minstens drie aanleidingen voor foute invoer geeft, maakt dit een stevige ontwerpfout.

Deze ontwerpfout heeft in dit geval nog extra veel impact, omdat de sleutel van de uitkomst van deze stemwijzer nu juist zit in de exacte positie van de schuifbalk (zie quote over de schuifbalk, een stukje naar boven).

Gebruikerstest

Ik weet dat ik vanwege mijn werk bovenmatig kritisch ben op digitale producten. En het slechte postcodeveld maakte me extra alert. Bij wijze van supersnelle test laat ik dit scherm zien aan mijn vriendin:

"Ik heb hem ook net ingevuld. Stom he! Waarom vragen ze niet gewoon of je mening neutraal is ja of nee?".

Dus mijn eerste 'proefpersoon' vindt dit ook slecht werken - en bedenkt in een paar tellen hoe het beter kan. Sterker nog, ze noemt dezelfde oplossing.

Wat ik zonet gedaan heb is een gebruikerstest in de meest eenvoudige vorm: ga naar buiten, zoek een gebruiker, laat die iets testen en noteer zijn/haar mening en bevindingen.

Dit soort onderzoek is van onschatbare waarde, want het is onmogelijk om een digitaal product vanaf een whiteboard in één keer goed uit te denken. Dat kun je van niemand verwachten: niet van een opdrachtgever, niet van een product owner en niet van een ontwerper of bouwer.

Uit nieuwsgierigheid heb ik de test nog iets uitgebreid:

  • Buiten op mijn kantoorterrein vroeg ik 5 willekeurige mensen om 1 minuutje van hun tijd.
  • Dit waren mensen zonder technische ICT-achtergrond (geen ontwerpers, ontwikkelaars etc).
  • Ze werden gevraagd om twee stellingen in te vullen en daarbij "hardop te denken".
  • Ze moesten eerst een stelling eens of oneens stemmen, en de stelling daarna neutraal.
  • Ik heb geturfd of ze mopperden over de melding.
  • De mensen die mopperden heb ik gevraagd "Hoe zou je dit handiger vinden werken?"
  • Ik heb geturfd of ze dan iets zeiden dat lijkt op de oplossing "Stem je neutraal ja/nee".
  • Ik heb opgeschreven of ze (ook) een andere oplossing noemden.

Hier zie je de resultaten:

Stemwijzer gebruikersonderzoek

  • 3 van de 5 mopperden over de melding
  • 2 van die 3 noemden "Stem je neutraal ja/nee" als oplossing
  • 2 van die 3 noemden ook "Laat gewoon 5 bolletjes van 1-5 zien" als oplossing
  • 1 van die 3 noemde "verberg het handje totdat ik een keus maak" als oplossing

Best mooi: samen met 5 gebruikers hebben we nu een duidelijk knelpunt aangewezen, en meer dan voldoende input om dit onderdeel van de stemwijzer te verbeteren.

Bovenstaand onderzoekje heeft mij alles bij elkaar een half uurtje gekost. In een officiële setting zou het wat meer voorbereiding en nawerk vragen, maar dit geeft aan hoe je met lage kosten je product enorm kunt verbeteren.

Levensecht prototype

Zo'n gebruikerstest is dus een geweldig instrument. Maar we hebben nu een live product getest... de stemwijzer is al gemaakt en wordt volop gebruikt. In het algemeen kosten aanpassingen van bestaande software veel tijd en geld en kunnen ze in extreme gevallen weer nieuwe problemen opleveren.

Het ideale moment om met gebruikersonderzoek te starten, is vóórdat je start met bouwen. En dat doe je met een levensecht prototype.

Met een prototype laat je jouw gebruikers zien en voelen wat je maakt, zonder het te maken. De feedback die je -gegarandeerd- ontvangt, hoef je dan niet (duur) te verwerken in je reeds ontwikkelde product, maar pas je toe in het ontwerp.

Door je prototype vroeg te delen hoef je niet op feedback te wachten totdat je product gebouwd is, maar kun je de uiterst waardevolle eerste ervaringen, meningen en feedback van je gebruikers direct meenemen in het ontwerp van je eerste versie. Lees ook mijn post waarom een prototype onmisbaar is als je een app, site of tool laat maken.

Door al met een prototype feedback te verzamelen, zal jouw digitale product bij lancering al veel beter zijn. En omdat je de eerste gebruikersfeedback niet in je live product hoeft door te voeren, bespaar je enorm in de kosten. Want let op: die feedback zul je altijd krijgen. Dus dan liever vroeg dan laat!

Begin met de eerste gebruikerstests vóórdat je gaat bouwen - je lanceert gegarandeerd een beter product tegen lagere kosten.

Bekijk mijn live prototype

Waarom is prototyping eigenlijk zoveel goedkoper dan testen en herstellen van je echte product? Dat komt omdat je tegenwoordig heel snel een waanzinnig realistisch interactief prototype kunt maken, zonder tijdrovend programmeerwerk.

Om je een voorbeeld te geven heb ik een prototype gemaakt van een verbeterde versie van deze stemwijzer.

Je kunt het prototype hier live bekijken (geoptimaliseerd voor iPhone 6 en groter). Het kostte mij minder dan een uur om dit prototype te maken en publiceren.

Auteur(s): Jorrit Venema

 Nu advies bij je software project? Bel 030 320 0450 of plan een belafspraak

Software ontwikkeling advies voor ondernemers en startups
Lanceer winstgevende software, efficiënt & voorspelbaar

VAART software | Kanaalweg 18-G Utrecht


030 320 0450 | belafspraak

KvK 30187211

Privacyverklaring

Elke maand tips en inzichten over software ontwikkeling: