Bruikbaarheids- en gebruikerservaringbeoordelingen als onderdeel van kwaliteitsborging
Als je denkt dat goed ontwerp duur is, moet je eens kijken naar de kosten van slecht ontwerp.
Dr. Ralf Speth, CEO, Jaguar Land Rover
In het afgelopen decennium is gebruikerservaring de echte onderscheidende factor geworden tussen goede en geweldige applicaties.
De technische kant van software bouwen is min of meer een opgelost probleem. De echte mogelijkheden voor buitengewoon succes met softwareproducten liggen in UX. De volgende killerapplicatie zal een interface hebben die direct bruikbaar is. Dit heeft geleid tot een op onderzoek gebaseerde, op UX gerichte aanpak voor productontwikkeling.
De resultaten van deze focus spreken voor zich.
Zo levert volgens een onderzoeksrapport van Forrester elke dollar die in UX wordt geïnvesteerd $100 aan rendement op. Daarnaast blijkt uit een onderzoek dat over een periode van 10 jaar de financiële prestaties van ontwerpgedreven bedrijven die de S&P met 219% overtreffen.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Er is ook het legendarische verhaal over hoe het simpelweg wijzigen van de tekst op één knop een e-commercebedrijf in één jaar $300 miljoen extra omzet opleverde!
Ondanks al deze hype en ophef zijn er voor elke applicatie met een geweldige gebruikerservaring meerdere applicaties die op dat gebied tekortschieten of ernstig tekortschieten. De verschrikkelijke zijn gemakkelijk te herkennen: ze geven je de neiging een gat in het scherm van je laptop te slaan of je mobiele apparaat door een raam te gooien. Darwin neemt die applicaties voor zijn rekening.
De echte uitdaging wordt gevormd door apps met een matige UX. Dat zijn de ervaringen die spreekwoordelijk een “splinter in je geest” zijn en waarvan je met geen mogelijkheid kunt bedenken waarom je ze niet prettig vindt!
Ik hoor je al zeggen: “We weten dit allemaal; ik lees The QA Lead nota bene, dus wat heeft dit met mij te maken?” Daar kom ik zo op.
Het belang van UX
In mijn beginjaren als manager van engineeringteams werkten we aan een groot softwareoplossingsproject voor een van onze klanten. Dit maakte deel uit van een grotere digitale transformatiestrategie die voor die klant werd geïmplementeerd. Het was een typisch engineeringteam dat voornamelijk bestond uit softwareontwikkelaars en QA-engineers die Scrum gebruikten met sprints van 2 weken.
Er was een klein UX-team, maar voor het grootste deel werd dit team gedeeld tussen projecten. Doorgaans namen de UX-medewerkers tijdens de beginfase van het project deel aan de dagelijkse teamvergaderingen, maar zodra de klant het visuele ontwerp had goedgekeurd, droegen ze alle sjablonen voor het visuele ontwerp en de gebruikersstromen over en gingen ze aan andere projecten werken.
Tijdens de eerste sprintdemo leek de klant zich vooral zorgen te maken over het feit dat het visuele ontwerp en de gebruikersinterface niet exact overeenkwamen met de ontwerpsjablonen. Er was ook een verschil tussen de voorgestelde functionaliteit en wat daadwerkelijk was geïmplementeerd.
Begrijp me goed, het verschil was niet groot, maar hoe vaak we onze klant ook probeerden gerust te stellen dat het UX-aspect tijdens een van de latere sprints zou worden bijgewerkt, uit zijn lichaamstaal bleek dat hij er niet blij mee was.
Gelukkig nam de QA-lead van ons team het woord, zei dat dit een anomalie was en dat het niet opnieuw zou gebeuren. Vervolgens deed ze iets geweldigs. Ik zet het hier uiteen:
- Ze nam zelf het initiatief om haar UX-kennis bij te spijkeren door zich intensief in te lezen.
- Vervolgens voerde ze zelf een basale heuristische UX-evaluatie uit van de opgeleverde functionaliteit, overlegde ze met de UX-medewerkers en vroeg ze hun hulp waar dat nodig was.
- Ze maakte nieuwe taken aan in JIRA om het verschil tussen wat was beloofd en wat was opgeleverd vanuit UX-perspectief te verhelpen.
- Ze plande een gesprek met onze UX-directeur en kreeg zijn goedkeuring om een nieuw proces in te voeren waarbij de visuele aspecten van de applicatie tijdens elke sprint werden verbeterd, in plaats van pas aan het einde.
- Tot slot zorgde ze er ook voor dat onze QA-medewerkers de basisprincipes van UX begrepen, zodat ze in het oog springende problemen konden signaleren en het team konden helpen deze vroegtijdig aan te pakken.
De kers op de taart? Tijdens de volgende sprintdemo straalden de product owner en de klant van oor tot oor en na een paar maanden werd onze QA-lead gepromoveerd tot QA-manager! 😉
Romantische versus klassieke perspectieven op de werkelijkheid
Deze hele gebeurtenis zette me aan het denken over de enorme kloof tussen de manier waarop wij binnen engineering naar een applicatie kijken en de manier waarop klanten en gebruikers ernaar kijken. Robert Pirsig schrijft in zijn baanbrekende boek Zen en de kunst van het motoronderhoud over twee perspectieven op de werkelijkheid: het klassieke en het romantische.
Volgens Pirsig bekijken mensen met een dominant romantisch perspectief dingen en beoordelen ze die op basis van hoe ze eruitzien. Ze zijn vooral geïnteresseerd in hoe dingen zijn en geven er niet om hoe ze werken: de onderliggende orde. Dit is de artistieke helft van de tegenstelling tussen kunst en wetenschap.
Aan de andere kant onderschrijven wij, ingenieurs & wetenschappers, het klassieke perspectief, waarbij schoonheid ligt in de mechanismen die aan de uiterlijke vorm ten grondslag liggen. Ingenieurs kunnen schoonheid zien in Python-code of onder de motorkap van een auto, wat er voor mensen aan de romantische kant lelijk uitziet.
Zoals met alles het geval is, gaat het hier uiteraard niet om een binaire classificatie, maar om een continuüm waarbij de meesten van ons in dominante mate de voorkeur geven aan een van beide perspectieven.
Deze manier om de wereld in te delen heeft enkele interessante gevolgen:
1. Het dominante perspectief van de meeste mensen is standaard óf klassiek óf romantisch, niet beide.
2. Mensen - denk aan interne of externe klanten - met een romantisch perspectief zijn veruit in de meerderheid ten opzichte van mensen met een klassiek perspectief. Als je ooit de rol van technische ondersteuning voor familie en vrienden hebt moeten vervullen, weet je wat ik bedoel!
3. Zeer weinigen kunnen van modus wisselen en zelfs voor hen is dat een activiteit die inspanning vergt.
4. Werkelijkheid = klassiek + romantisch. Ze sluiten elkaar niet uit. Beide zijn essentiële aspecten van het geheel. Schoonheid is functioneel. Functionaliteit kan mooi zijn.
Neem bijvoorbeeld bloemen. Ze hebben zulke prachtige patronen dat ze geen enkele functie lijken te hebben. Toch heeft de schoonheid die we in bloemen zien een onderliggende structuur die in de wiskunde verankerd is: de Fibonacci-reeks bepaalt de structuur en patronen die we in bloemen zien. Structuur en etherische schoonheid gaan in de natuur hand in hand.
En het gaat niet alleen om schoonheid. De rangschikking van de zaden in een zonnebloem volgt de Fibonacci-reeks en de gulden snede om zoveel mogelijk zaden in de bloem te kunnen plaatsen. Dezelfde principes zijn van toepassing op engineering en gebruikerservaring.
Dit brengt ons uiteindelijk bij de kern van dit artikel: professionals in kwaliteitsengineering zijn bij uitstek in staat om van beide ogenschijnlijk concurrerende perspectieven gebruik te maken.
De rol van software-QA in UX / bruikbaarheid
Als testprofessional heb je veel meer ervaring met interfaces dan de gemiddelde ontwikkelaar of gebruiker.
Je hebt zo veel applicaties grondig en herhaaldelijk (tot vervelens toe!) getest dat je mogelijk het niveau van hogere-orde- oftewel 4D-denken hebt bereikt als het om UX gaat, net als de spreekwoordelijke schaakgrootmeester die in stellingen denkt, in tegenstelling tot ondergetekende, die moeite heeft om te bepalen welk stuk hij vervolgens moet verplaatsen! ;-)
Daarom valt er, ondanks de massale verschuiving naar automatisering—zonder twijfel een geweldige ontwikkeling—iets te zeggen voor enige handmatige tests. Als mensen een applicatie gaan gebruiken, is het immers logisch om vanuit het testen ook een menselijk perspectief mee te nemen.
Een UX- / bruikbaarheidsbeoordeling uitvoeren als testengineer
Als kwaliteitsborging rekening moet houden met UX, moet dat al naast de ontwerpfase beginnen, dus aan het begin van de levenscyclus. Hieronder staan de stappen die je kunt volgen om de UX-beoordeling in je tests op te nemen en een QA-polymaat te worden!
Bruikbaarheidsheuristieken voor het ontwerpen van gebruikersinterfaces
Maak jezelf vertrouwd met de 10 algemene principes voor interactieontwerp van Jakob Nielsen. Deze richtlijnen vormen een betrouwbaar referentiepunt voor elke bruikbaarheidsbeoordeling. Neem deze principes mee in je gesprekken met het UX-team en in je testplan. Je kunt ook een van de vele basiscursussen over bruikbaarheid en UX-ontwerp volgen.
Leer de principes van toegankelijkheid
U hebt in het verleden misschien toegankelijkheidstests uitgevoerd als onderdeel van uw testplan, maar als u de principes achter toegankelijkheid—waarneembaar, bedienbaar, begrijpelijk en robuust—begrijpt, beschikt u over het vermogen om te zien wat anderen mogelijk missen.
Het UX-team is uw nieuwe ontmoetingsplek
Blijf geen onbekende: leer het UX-team van het project kennen. Werk met hen samen. Deel uw testplan met hen en vraag om feedback over wat u vanuit UX-perspectief kunt opnemen.
De voordelen van deze interactie werken twee kanten op, omdat uw testplan het ontwerpteam inzicht geeft in de haalbaarheid van de ontwerpfuncties die zij willen voorstellen. Als QA-leider moet uw interactie met het UX-team net zo nauw zijn als die met de ontwikkelaars.
Neem analyses op in uw testplan
De gebruikersanalyses van het product dat u test, zijn een goudmijn aan informatie voor testers. Analyses kunnen u helpen risicogebieden en gebruikersgedrag te identificeren. Deze inzichten kunnen u op hun beurt helpen om oplossingen zo vroeg mogelijk in de levenscyclus van het product te identificeren en prioriteren.
Schuif zo ver mogelijk naar links
Het product dat u test, is net een baby. U moet ervoor zorgen dat het vanaf het allereerste begin van de conceptie van het product de benodigde hulp krijgt. Ga helemaal terug naar het begin.
Vóór de ontwikkeling
Test tijdens de ontwerpfase zodra er een prototype beschikbaar is. Gebruik uw ervaring met applicaties en uw kennis van bruikbaarheidsprincipes en toegankelijkheidsrichtlijnen om te controleren of er wijzigingen moeten worden aangebracht VOORDAT het product naar de ontwikkelingsfase gaat.
Als QA nog geen onderdeel is van de ontwerpfase, zorg er dan indien mogelijk voor dat dit wel gebeurt.
Gericht handmatig testen
Doorloop tijdens het handmatig testen de volledige gebruikerservaring van het product, van begin tot eind. Richt u op het stellen van de juiste vragen en denk zowel als een gebruiker als een QA-ingenieur.
Begin door een stap terug te doen en het product vanuit een breder perspectief te bekijken. Bevalt de ervaring u?
Bekijk het product vervolgens nauwkeuriger. Is het gemakkelijk te gebruiken? Zijn de processen duidelijk en intuïtief? Zijn ze omslachtig en traag? Zijn er overlappingen of dubbele handelingen die de gebruiker kunnen ergeren? Is het ontwerp op verschillende schermformaten bruikbaar ?
Tot slot
De toekomst van werk behoort toe aan mensen met meerdere sets complementaire vaardigheden die voor machines vrijwel onmogelijk over te nemen zijn (maar bekijk mijn artikel over AI in testautomatisering om een beeld te krijgen van wat ze kunnen).
Een veelzijdige QA-professional worden met UX-vaardigheden kan een geweldige manier zijn om uw natuurlijke capaciteiten en ervaring te benutten, veel extra waarde toe te voegen zonder al te veel inspanning te leveren of te ver buiten uw expertisegebied te treden.
Is dit iets waar u enthousiast van wordt? Of denkt u dat UX slechts zijdelings met dit vakgebied te maken heeft? Laat het me weten in de reacties hieronder.
Als u klaar bent om meer te leren, kunt u deze podcast lezen/beluisteren: HOE OPEN-SOURCESOFTWARE INTEGRATIE IN AUTOMATISERINGSTECHNIEK VEREENVOUDIGT (MET JAMES WALKER EN SANJAY KUMAR)
