Conclusion

Test conclusie

Do's

Geef context en concrete opdracht

Zelf heb ik ook weer even Don't make me think gelezen om te kijken of daar nog zinnige dingen uit kwamen. Er stond wel iets wat ik mee nam in de testen. Je moet context geven aan de testpersoon en een duidelijke opdracht, dus: Stel je komt op de website en je wilt graag een artikel lezen. Voordat je het artikel leest, wil je eerst weten hoe lang het is. Kun je mij vertellen hoe lang het eerste artikel is. Zo geef je een concrete opdracht en laat je de gebruiker toch z'n eigen ding doen.

Splittesten

Dit is met name handig als je niet veel tijd hebt. Test gewoon meerdere dingen. Ik had bijvoorbeeld een sans-serif font tegenover een serif font getest (incl. uppercase en lowercase). Kost niet veel tijd om te maken, maar ik kwam erachter dat Roger de voorkeur gaf aan lowercase sans-serif. Super handig.

Simpel houden

Maak het niet te complex. Dat wil je eigenlijk niet. Als je misschien een complexe app hebt, waarvan je wilt weten of de gebruikers het allemaal wel kunnen doen: oké. Maar voor dit soort tests moet je gewoon kleine en simpele testjes maken die niet teveel tijd kosten.

Deel de uitkomsten

Wij hebben/hadden een document waar alle notulen in stonden. Zo kon je ook de notulen van anderen lezen. Daarnaast is het ook goed om de uitkomsten met elkaar in een call te bespreken. Dit hoeft niet te lang, maar zo leer je ook van elkaar. Wellicht dat de ander nog wat andere dingen heeft gezien/gehoord.

Zeg na de opdracht niet veel

Nadat je de opdracht gegeven hebt, moet je eigenlijk niet meer zo veel zeggen. Het is immers aan de testpersoon om te laten zien of het allemaal logisch is. Uiteindelijk sta jij ook niet achter elke toekomstige gebruiker om te helpen.

Neem de tests op

Dit ging nu heel makkelijk, omdat wij het online deden. Maar neem je tests op. De testpersoon moet hier wel mee akkoord gaan. Als je dit doet, kun je ze later altijd nog terug kijken. Je zult wellicht nog dingen tegenkomen die je tijdens de test niet eens waren opgevallen.

Don'ts

VOORZEGGEN!

Ik was mij zelf al bewust van dit probleem, maar tóch deed ik het. In de eerste test had ik een menu gemaakt die je kon open klappen. Ik zei tegen Roger dat hij met spatie het menu kon openklappen. Lekker slim, want in de praktijk is er niemand die dit voor zegt.

Net voor de test dingen aanpassen

Je hebt nog een uurtje, dus je kan nog wel iets aanpassen. Vervolgens push je het en begint de call. Je hebt het idee dat het werkt, maar op een of andere manier heb je toch wat verkeerd gedaan. Hier liep ik dus aan bij de laatste test. Gelukkig had ik meer dingen getest, maar een van de dingen kon ik niet testen, omdat het technisch niet (meer) werkte.

Remote testen

Oké, dan. Een hele kleine don't. De eerste test merkte we het gelijk al. Het delen van het scherm duurde al tien (!) minuten. Daarnaast konden wij niet horen wat de screenreader zei en dat was erg vervelend. Supernova werkte niet echt mee, dus daarom wisten we niet precies wat de uitkomsten van de test was. Remote testen is fijn door het besparen van reistijd, maar ik denk wel dat er meer en beter getest kon worden als dit 'gewoon' offline gedaan werd.

Geen aannames doen voordat je test

Eigenlijk is dit niet iets voor tijdens een test, maar meer vooraf. Je kan er zo naast zitten met jouw aannames. Daarom: test je aannames!

Conclusie vak

Criteria

Maak verschillende ontwerpen, versies en varianten van je opdracht. Experimenteer met verschillende vormen van interactie en vormgeving. Wat werkt goed? Wat werkt niet goed?

In de User Scenario is wel aardig te vinden wat er goed werkt en wat niet.

Daarnaast heb ik in test 2 een variant mét en een variant zonder audio gemaakt. Daaruit bleek dat de variant met audio het beste werkt voor Roger en daarom heb ik dit meegenomen in het uiteindelijke ontwerp.

Beschrijf je test-persoon met een User Scenario.

Zie User Scenario.

Test je ideeen en ontwerp 3 keer met de test-persoon. Verbeter je ontwerp op basis van de feedback die je hebt gekregen uit de tests. Documenteer de testen goed.

Zie testverslagen van week 1, week 2 en week 3.

De tests zijn overigens hier te vinden: https://hcd.jchm.dev/tests/

Leg de exclusive design principles uit en beschrijf hoe je die hebt toegepast.

Zie Exclusive Design

Zorg dat je voor de beoordeling in je Readme (of wiki) een conclusie schrijft waar je in gaat op de leerdoelen en criteria en hoe je dit hebt gehaald. Dit is je bewijsvoering voor het vak.

Aanschouw

Overall

Ik vond het vak ontzettend interessant. Zelf ben ik een developer en ben ik eerlijk gezegd niet helemaal van het ontwerpen. Dat neemt niet weg dat ontwerpen voor 'beperkte' mensen onbelangrijk is. Het is eigenlijk weer zo iets waar je nooit echt de tijd voor neemt, maar achteraf toch blij mee bent dat je het gedaan hebt.

Het was echt enorm pijnlijk om te zien hoe Roger met de computer om ging. Dingen werkte niet. Hij kon iets niet vinden. enz. enz. Wat mij met name is bij gebleven, is dat een simpel cijfertje voor contrast of het 'halen' van de WCAG checklist niet voldoende is. Het gaat er niet om dat je website AAA is. Natuurlijk is dat belangrijk en mooi, maar daar gaat het niet om. Het gaat erom hoe mensen jou website ervaren. En zoals ik gezien heb, ervaart Roger de meeste websites als een ramp.

Dit vak (i.c.m. Browser Tech) heeft er best wel voor gezorgd dat ik met 'dit soort dingen' rekening ga houden. Ik deed altijd wel labels bij m'n inputs en keek even of het op elk apparaat het er een beetje oké uit zag, maar nooit echt meer dan dat. Ik ga mezelf niet direct een accessibility expert noemen, maar ik vind dat het als front-end developer noodzakelijk is dat je deze kennis hebt. Ook ben ik me ervan bewust dat ik echt een hoop nog niet weet, dus ik wil graag op de korte termijn mezelf verdiepen in accessibility. Maar wat ik dus geleerd heb: leuk dat accessibility en WCAG, maar testen. Testen. Testen.