>>
26-augustus-2015, min. leestijd

Accepteren gebruikers de veranderingen van de applicatie eigenlijk wel?

Eén van de leuke bijkomstigheden als tester is dat je te maken kan krijgen met voorproefjes, waar jijzelf als klant "binnenkort" gebruik van kan maken. Als performance tester is dan met name die performance belangrijk, maar op de achtergrond speelt toch ook je interesse als klant mee. Reacties als "Leuk!" en "Hier zit ik nou echt op te wachten, wanneer staat dit in productie?" zijn mij niet vreemd. In sommige situaties is dat echter ook wel eens tegengesteld. En hoewel het niet mijn vakgebied is, vraag ik me dan toch vaak af welk onderzoek is uitgevoerd om tot het besluit te komen dergelijke functies of veranderingen door te voeren. Hoe belangrijk is een nieuw design en hoe wordt er op die verandering gereageerd? En heb je daar als tester invloed op?

Nieuwe technologieën en ontwikkelingen binnen software development stimuleren aanpassing

Waar vroeger iedereen zijn eigen uitstraling wist te geven aan zijn website, lijken steeds meer bedrijven genoegen te nemen met standaard toepassingen, zoals dat enige tijd geleden voor mijn gevoel is begonnen met e-Commerce en WordPress: standaard frames waarbinnen vrij snel een website in elkaar te zetten is. Hiermee is nog steeds wel een eigen smaak te geven aan jouw product, maar bij het aanhouden van de standaard blijft het allemaal makkelijker te onderhouden en uit te breiden. Met de verplaatsing van internetverkeer van desktops naar mobiel en tablets deden schaalbare (responsive) websites hun intrede. Voor herkenbaarheid worden steeds vaker gelijkende icoontjes gebruikt. Talloze JavaScript libraries bieden inmiddels uitkomst bij de meest uiteenlopende gewenste functionaliteit en stijleffecten. HTML wordt gesplitst en de structuur wordt asynchroon gevuld met de data (AJAX, AngularJS). XML wordt (eindelijk) vervangen door JSON om data compacter over het netwerk te versturen. Tja, mobiele netwerken zijn nou eenmaal niet zo snel als het wireless thuis, om over het verbruik van je databundel verder maar te zwijgen...

Ook de vrijlating van ontwikkelteams in Agile scrumteams geeft ontwikkelaars meer macht om de volgens hen beste en snelste manier te kiezen om te ontwikkelen, zolang het uiteindelijke product maar biedt wat het bedrijf zijn klant wil bieden (en in het eventuele bestaande serverlandschap past).

Wat is de reden achter de vernieuwing?

De reden achter de vernieuwing is meestal hetgeen waardoor de klant uiteindelijk een goed gevoel bij de vernieuwing krijgt of niet. Een volledige refactoring van een product kost een bedrijf vaak veel geld en tijd zonder dat er nieuwe functionaliteit aan het systeem wordt toegevoegd. De klant merkt in die gevallen vaak heel weinig. Waarom dan een refactoring uitvoeren? Redenen kunnen zijn: het aanzienlijk verbeteren van performance, of het vergemakkelijken van het beheer of een product klaarstomen voor gewenste uitbreidingen die dan beter aansluiten. Agile werken lijkt echter ook een extra bijwerking te hebben, zeker bij nieuwe (vervangende) producten: ontwikkelaars gaan aan de slag met wat zij zelf leuk vinden: nieuwe technieken. Dat maakt een product natuurlijk wel helemaal eigen en zorgt ook voor zeer gemotiveerde ontwikkelaars, maar nieuwe technieken betekent ook veel uitzoekwerk en door tijdsdruk van de sprints is het dan niet verwonderlijk als de basis van zo’n product uiteindelijk niet volledig voldoet aan de onderliggende principes van die nieuwe technieken...

Een grote beweging die momenteel gaande is, is om zoveel mogelijk logica op de clients (mobiel, desktop, tablet) zelf te laten plaatsvinden, en zo tevens te besparen op rekenkracht in het serverpark. Ik begrijp dat dit aantrekkelijk is voor bedrijven, maar naar mijn mening is dit uiteindelijk ten nadele van klanten, vooral die klanten die een wat minder krachtige telefoon of PC hebben...

Voor het testen biedt dit wel ook nog de nodige uitdagingen die voor ons als testers wel weer leuk zijn om aan te gaan...

Aversie tegen verandering?

https://www.gv.com/lib/change-aversion-why-users-hate-what-you-launched-and-what-to-do-about-it

Bovenstaande link vond ik zelf een erg interessant stuk over change aversion. Ook de Editor’s Note verwijst naar een reactie en het antwoord daar weer op. Leuk om te lezen. De header-afbeelding is gebaseerd op een infograph die ik via www.marcvandelogt.nl tegenkwam en komt van de volgende website: http://www.frankwatching.com/archive/2015/03/14/zo-belangrijk-is-het-design-van-je-website-infographic/

Conclusie

Ik ga er graag van uit dat ontwikkeling altijd vanuit de wens van de klant plaatsvindt en dat er onderzoek naar gedaan is naar bijvoorbeeld trendontwikkeling en wat klanten motiveert en dat vanuit dat belang de verandering en vernieuwing doorgevoerd wordt. Om te voorkomen dat een grote groep klanten slecht reageert kan je ze vroeg betrekken door de aanpassingen in kleine stappen door te voeren, door (een focusgroep) gebruikers te betrekken (Alpha / Beta testing) en door marketing op het product (aankondigen, reclame, social media).

Ook denk ik dat, als je de juiste weg weet te bewandelen, je als tester altijd je mening kan geven over een product vanuit het oogpunt van een klant. Hoe langer een bedrijf al bezig is om een nieuw product te ontwikkelen hoe meer expert-user ze zijn geworden en hoe meer ze de vernieuwing zelf al hebben geaccepteerd. Zij zijn al verder in die "rouwcurve". Het kan dan geen kwaad om ze met beleid weer even bewust te maken van de novice-beleving van het nieuwe product. Het zijn tenslotte impliciete bevindingen op het product.

Als iedereen denkt dat ze de enige zijn en iedereen blijft stil, wordt er een kans op verbetering verspild. Daarbij: wanneer jouw opmerkingen grond vinden en er ook werkelijk iets mee gedaan wordt, kan jij ook met dat beetje extra trots toezien hoe vervolgens die vernieuwde en aangepaste applicatie in productie wordt genomen, waarna je er zelf ook met plezier gebruik van kan gaan maken!

Deze website werkt het beste met JavaScript ingeschakeld