Vergroot je succes met gebruikersonderzoek

Om onze applicaties zo gebruiksvriendelijk mogelijk te maken is de input van medewerkers natuurlijk essentieel. Zij moeten immers met de nieuwe software aan de slag. De software moet hen ondersteunen in hun werk, ongeacht hun rol. Deze input verzamelen kan via een gebruikersonderzoek. Hoe eerder je deze verzamelt, hoe minder kans op onverwachte – en ongewenste – wijzigingen later in het proces. Er zijn drie fases waarin we de gebruiker kunnen betrekken.

Conceptingfase: productvisie en strategie centraal

In de conceptingfase weten we wat de basisfunctionaliteit is, maar nog niet hoe we daaraan gaan voldoen. In deze fase staat de productvisie en de strategie waarmee die visie gerealiseerd wordt centraal. De productvisie gaat bijvoorbeeld over de marktbenadering, het interactief concept en de manier waarop de software binnen het bestaande applicatielandschap wordt geïntegreerd. Daarnaast ontwikkelen we een strategisch plan waarmee we die productvisie realiseren: de juiste aanpak, functionele prioriteiten en technische randvoorwaarden.

Door met gebruikersgroepen om tafel te gaan krijgen we de eisen waaraan de applicatie moet voldoen helder. Als het moeilijk is om gebruikersgroepen bijeen te brengen, gebruiken we enquêtes. Vaak werken we met design sprints; zo schetsen we in een week tijd een bepaalde oplossing en leggen die voor aan de gebruikers. Door dat een aantal keer te doen komen we heel snel tot een globaal concept.

Een andere techniek die we in kunnen zetten is card sorting. Hierbij plaatsen deelnemers kaartjes – die elk een bepaald informatietype of functionaliteit representeren – hiërarchisch op een groot vel. Vaak zien we dan dat iedereen dat op een andere manier doet. Perspectief op informatie kan per gebruiker verschillen en dat is belangrijk mee te nemen bij de ontwikkeling. De inzichten die een dergelijke card-sorting-sessie oplevert gebruiken we om tot een goed interactief concept te komen.

Implementatiefase: blijf de gebruiker betrekken

In de implementatiefase is het belangrijk de gebruikers te blijven betrekken. Niet alleen door demonstraties te geven, maar juist ook door prototypes in te zetten voor vroegtijdig gebruikersonderzoek. We geven de medewerkers dan een duidelijke opdracht en volgen zijn of haar bewegingen en acties via een schermopname. We vragen hen om hardop na te denken bij het uitvoeren van de opdracht. Zo krijgen we een goede indicatie over of de applicatie aansluit bij de denkpatronen en werkwijze van de gebruiker.

Door agile te werken kunnen we onze constateringen snel verwerken. Het gebruikersonderzoek draagt zo bij aan de stapsgewijze verbetering van de applicatie. En door de gebruiker te blijven betrekken verhoog je de acceptatie bij ingebruikname.

Optimalisatiefase: toetsen en oppoetsen

Is de applicatie eenmaal in gebruik, kom je in de optimalisatiefase. Hierin toetsen we de aannames die we tijdens de implementatiefase hebben gedaan. Via verschillende vormen van usability testing toetsen we of de applicatie begrepen wordt. Schermopnames kunnen oneffenheden in het gebruik van de applicatie aan het licht brengen. En met A/B-tests kun je testen welke variant van een functionaliteit of lay-out prettiger werkt.

Omdat organisaties en situaties veranderen voeren we bij veel van onze klanten een jaarlijks gebruikerstevredenheidsonderzoek uit. Hierin testen we of de software nog steeds aansluit bij de behoefte. Kleine aanpassingen in de werking van de applicatie kunnen een groot effect hebben. Zo houden we je medewerkers blij!

Vrijheid in volgorde van werken bij VUmc

Het is altijd verstandig de gebruiker zo vroeg mogelijk in het proces te betrekken. Toch loopt het weleens anders. Zo maakten we een internationale begrotingstool voor het VUmc. De volgorde waarin dit proces doorlopen werd, leek zo voor de hand liggend dat we hebben besloten eerst een minimal viable product te maken. Werken vanuit zo’n eerste versie van de applicatie kan een heel kostenefficiënte manier zijn om tot je eindproduct te komen.

In dit geval bleek echter tijdens het gebruikersonderzoek dat de manier van werken van de ene gebruiker compleet tegengesteld was aan die van de ander. We hebben toen de applicatie zo geherstructureerd dat de medewerkers veel vrijer zijn in volgorde van werken. Dit bewijst dat gebruikerstesten is alle drie de fases het beste en meest gebruikersvriendelijke resultaat geeft.

Nieuwsgierig naar gebruikersonderzoeken?

Benieuwd hoe we het leven van jouw mensen makkelijker kunnen maken? Neem vrijblijvend contact op met of bel met +31 (0)88 – 26 27 376.

Jelle van den Berg

Van Excel naar applicatie: de conversie

In het vorige blog over dit onderwerp schreef ik over de motivatie voor bedrijven om af te stappen van verslaglegging in Excel. Excel is weliswaar een ultiem flexibele tool om te beginnen met bijvoorbeeld een productieplanning, maar naar mate de sheets groeien, wordt Excel steeds minder handzaam.

Ambrero helpt regelmatig klanten om de stap naar een maatwerk-applicatie te maken. In deze blog neem ik je mee naar de ervaringen die we bij deze transities hebben opgedaan.

We starten de ontwikkeling altijd met de analyse van de tot dan toe gebruikte Excelsheets: om welke data gaat het eigenlijk? Zijn de gegevens over verschillende sheets verdeeld, en waarom is dat data op die manier georganiseerd? We komen daarbij de meest fantastische situaties tegen: Excel-toepassingen waarbij bijvoorbeeld diverse bronbestanden via VB-scripts aan elkaar geknoopt zijn en uitmonden tot volledige boekwerken aan tekst. Geen wonder dat de gevolgen van wijzigingen niet altijd meer duidelijk zijn.

Een breakdown van de informatie

Vast onderdeel van deze analyse is om te kijken of er overeenkomsten zitten tussen de diverse sheets. Zijn de sheets steeds op dezelfde manier opgebouwd? Of worden er standaardformules gebruikt? Recent kregen we 90 verschillende templates onder ogen, elk met een eigen opmaak. Het hele zwikkie moest worden vertaald naar een app. Hoe documenteer je dat? Hoe zorg je voor een goede instructie aan de ontwikkelaars?

“Uit 90 Excelsheets konden we 20 standaardcomponenten achterhalen.”

Wat bleek? Uit de 90 Excelsheets waren een stuk of 20 standaardcomponenten te ontcijferen. En die waren stuk voor stuk prima te documenteren. Zo sloegen we 2 vliegen in 1 klap: we konden de ontwikkeling opdelen in vastomlijnde, documenteerbare stukken werk, en daarnaast hadden we direct een breakdown van de applicatie op basis waarvan we de functionele en technische structuur van de applicatie konden ontwerpen.

Terughoudende eerste reacties

Als je al jaren dezelfde Excelsheets voor je hebt dan is het even schrikken als je opeens draadmodellen voor je neus krijgt die in niets op Excel lijken. Mensen houden niet van verandering, zeker niet als je daarmee de controle dreigt kwijt te raken. Want dat is wat er gevoelsmatig gebeurt wanneer je als gebruiker het comfort verlaat van een scherm dat volledig vertrouwd aanvoelt en waarin je alles naar hartenlust kunt aanpassen. Je wordt geconfronteerd met het gevoel dat veranderingen straks niet meer mogelijk zijn – of in elk geval minder vanzelfsprekend.

Een vraag die we in vrijwel elk project van dit type krijgen is of het ook mogelijk is om gegevens te kopiëren en plakken. ‘Want dat kan toch ook in Excel?’ Een dergelijke uitspraak illustreert hoeveel waarde er wordt gegeven aan de werkwijze waaraan de medewerkers gewend zijn. En dat vinden we niet meer dan logisch: natuurlijk wil je als bedrijf zelf de controle houden en de mogelijkheid hebben om te allen tijde wijzigingen aan je processen door te voeren. De ervaring leert echter dat het creëren van zeer flexibele software arbeidsintensief (en dus kostbaar) is, en dat het bovendien consequenties kan hebben voor de gebruiksvriendelijkheid van de applicatie.

Ambrero Blog van Excel naar conversie

Behoud van gemak en flexibiliteit

Toch willen we de transitie naar een nieuwe applicatie natuurlijk zo soepel mogelijk maken. Uiteindelijk gaan er mensen misschien wel dagelijks mee werken, dus dan is er alles aan gelegen om te luisteren naar de input van de doelgroep. Gebruikers die gewend zijn om in Excel te werken hebben speciale verwachtingen op het gebied van gemak en flexibiliteit: vaak is de wens voor inhoudelijke flexibiliteit groot, maar is qua vorm juist standaardisatie gewenst. Als softwarebedrijf proberen we daar op drie manieren op in te spelen:

  1. De meest gebruikte functies maken we toegankelijk via het toetsenbord. Navigatie via pijltjes (zoals je ook in Excel kunt) en navigatie via shortcuts kunnen de acceptatie door medewerkers vergemakkelijken.
  2. Om tegemoet te komen aan de wens om inhoudelijke wijzigingen in de applicatie aan te brengen, proberen we zo veel mogelijk instellingen en dergelijke te vatten in bewerkbare stamgegevens. Zo kan de gebruiker in elk geval invloed uitoefenen op de inhoud van selectielijsten, formules, de volgorde waarmee invoervelden gepresenteerd worden, en de eventuele andere wensen.
  3. Waar mogelijk maken we functionaliteit om de applicatie via Excel-imports te configureren. Onlangs maakten we bijvoorbeeld een applicatie waarin vragenlijsten een centrale plek hebben. Door import- en exportfuncties te maken kon het beheer van deze vragenlijsten volledig binnen Excel worden gedaan. Daarmee ontstond een handige combinatie van opslag en verwerking binnen een gecentraliseerde webapplicatie en de flexibiliteit van Excel.

Acceptatie van de nieuwe software

Waar de initiatiefnemers van de nieuwe software, vaak managers of beheerders, al vanaf het begin van de conceptontwikkeling een beeld hebben van verbeteringen die ze met de nieuwe software beogen, kost dat voor de eindgebruiker soms wat meer tijd. Een nieuw interactief concept moet vaak even ‘landen’.

In een maatwerk applicatie zorg je er natuurlijk voor dat de software precies aansluit bij het werk van de gebruiker. Het is daarom belangrijk om de medewerker zo vroeg mogelijk te betrekken. Bij Ambrero proberen we daarom al in een vroeg stadium een demo-baar prototype te hebben. Een belangrijk moment, want een positieve indruk kan de acceptatie in één klap probleemloos maken. De eerste glimlach van de eindgebruiker is voor ons goud waard: dan weet je dat het goed zit!

“De eerste glimlach van de eindgebruiker is goud waard.”

Die eerste glimlach kan verschillende redenen hebben. Een prettige User Experience bijvoorbeeld, of het besef dat de input die de medewerker in een eerder stadium heeft gegeven binnen het prototype is verwerkt. Maar de grootste kans op acceptatie is het moment waarop de medewerker ziet hoeveel frustratie de nieuwe applicatie gaat wegnemen: de snelheid waarmee het systeem reageert, of het gemak waarmee gegevens kunnen worden ingevoerd. Gebruikersvriendelijke software die tijdwinst oplevert!

De stappen van conversie naar een applicatie

Ik heb je meegenomen in een aantal stappen die we nemen om te komen tot een applicatie en de aandachtspunten die wij hierbij zien. Hier nog even alle fases, die wij volgen, op een rij.

  • Analyseren van de tot nu toe gebruikte Excel sheets; wat zijn de overeenkomsten?
  • Het in kaart brengen van de ideale processen van de verschillende gebruikersgroepen.
  • Deze input vertalen naar draadmodellen en een prototype.
  • Het toetsen van het prototype bij de eindgebruikers en verzamelen van feedback.
  • Ontwikkelen van (de eerste versie) de applicatie.
  • Migratie van de bestaande data, dus de informatie uit de 90 Excelsheets overzetten naar de applicatie!

Conclusie

Als ontwikkelaar van gebruiksvriendelijke maatwerksoftware kijken wij natuurlijk altijd met een schuin oogje naar applicaties die zijn ontwikkeld op basis van een standaard raamwerk als Excel. Feitelijk staan we soms echter met bewondering te kijken hoe ver bedrijven de grenzen van Excel hebben weten op te rekken.

De vertaalslag van de vaak grote hoeveelheden gegevens naar een webapplicatie of mobiele app is een secuur proces dat start met een grondige informatieanalyse. Bij de vertaling die vervolgens plaatsvindt is het belangrijk om de oorsprong in het achterhoofd te houden: het is soms beter om Excel te omarmen dan om heel eigenwijs alles anders te willen doen. Door de gebruikers vroegtijdig te betrekken kun je erachter komen op welke vlakken flexibiliteit gewenst is en op welke vlakken juist niet. En als je al die facetten weet te verwerken binnen de nieuwe software dan is een succesvolle adaptatie vrijwel gegarandeerd!

Jelle van den Berg

UX design als sleutel tot gebruiksvriendelijkheid

Er is geen interface die zonder UX design kan. User experience design is de manier om behoeften van gebruikers om te zetten naar een werkbaar scherm, voor computer, smartphone of waar dan ook. Belangrijk als je geld wilt verdienen met je website, als je iets te vertellen hebt, je werknemers efficiënt wilt laten werken en wilt zorgen dat bedrijfsprocessen worden vergemakkelijkt. Maar wat komt er bij kijken?

Hier bij Ambrero kijken we altijd eerst naar de wensen van de klant. Wat is het eerste idee, wat is het uiteindelijke doel? Soms is er veel (offline) data beschikbaar, die in kaart moet worden gebracht. Hoe kunnen we deze gegevens gebruiken voor schermen? Hoe ontsluit je deze informatie en hoe maak je dit inzichtelijk en doorzoekbaar? UX design bestaat uit het vatten van deze wensen (soms geschreven in user stories) in begrijpelijke schermen. Als UX designer begin je na het in kaart brengen van de gegevens met het uitdenken van een flowchart: op welke manier komt de gebruiker bij de gewenste data? Dit leidt tot enkele onderdelen in de applicatie of website, die logisch aanvoelen en snel te vinden zijn, maar altijd met de eindgebruiker centraal. Sommige applicaties hebben te maken met verschillende typen gebruikers. Het is belangrijk dat je daarmee rekening houdt, want niet iedereen mag of kan alle data zien.

Een voorbeeld ter illustratie

Als voorbeeld kunnen we een applicatie nemen waar leerlingen van een middelbare school hun cijfers van vakken kunnen inzien. We hebben in deze fictieve software te maken met drie verschillende doelgroepen. Ten eerste de leerlingen, die graag hun resultaten snel moeten kunnen vinden. Daarnaast de docenten, die de resultaten eenvoudig moeten kunnen invoeren en groepen leerlingen kunnen indelen. En de applicatiebeheerders, die bijvoorbeeld docenten kunnen uitnodigen en onderhoud aan het systeem kunnen plegen. Logische sectie voor zo’n applicatie zouden kunnen zijn:

  • een overzicht van vakken en resultaten voor de leerling
  • een pagina met groepen en leerlingen, behorende bij de docent
  • schermen voor de docent om snel veel resultaten en leerlingen te kunnen invoeren
  • een scherm om docenten te kunnen toevoegen voor de beheerder

Met deze secties zijn we er natuurlijk nog niet. Je kunt je voorstellen dat een docent alleen zijn eigen groepen mag inzien, dus krijg je een rechtenstructuur die alleen bepaalde data ophaalt voor specifieke gebruikers. Daarnaast moeten alle doelgroepen nog kunnen in- en uitloggen (inclusief een ‘wachtwoord vergeten’ functionaliteit) en zouden meldingen dat er nieuwe cijfers zijn toegevoegd erg handig zijn, bijvoorbeeld per e-mail. Je ziet dat een eenvoudige wens, leerlingen moeten hun resultaten kunnen inzien, al snel leidt tot veel onderdelen binnen een applicatie, die snel complex kunnen worden. Dit is natuurlijk helemaal afhankelijk van de gewenste diepgang en hoeveelheid data. Vaak worden deze verschillende onderdelen daarom beschreven volgens de Agile methode in user stories: hapklare stukken functionaliteit, die individueel worden uitgedacht en uitgetekend. Daarna kan het ontwikkelteam met behulp van de wireframes een goede inschatting maken van de hoeveelheid werk om de applicatie daadwerkelijk te bouwen.

Wireframes zeggen meer dan 1000 woorden

Een van de user stories zou kunnen zijn: “Als leerling wil ik graag snel een overzicht van mijn resultaten zien”. Met behulp van de beschreven gegevens in de story, kan er een wireframe worden gemaakt. Er is bijvoorbeeld beschreven dat vakken in semesters zijn ingedeeld, er zowel proefwerken als examens zijn en dat bepaalde resultaten zwaarder kunnen wegen dan andere. Dit soort gegevens neemt de UX designer in nauw overleg met de klant mee tijdens het uittekenen van het wireframe. Het is een draadmodel van een scherm dat klaar is om gebouwd te worden, zelfs wanneer er nog niet ingelogd kan worden of er een menu is. Alleen de benodigde onderdelen worden getekend – de rest komt later, wanneer er meer wensen duidelijk zijn en andere stories in behandeling worden genomen. Een wireframe is ideaal voor gerichte feedback van de klant, die daarmee continu de controle houdt over zijn project.

UX design is in feite het oplossen van problemen – in het invoeren en ontsluiten van gegevens, met behulp van de elementen die daarvoor beschikbaar zijn. We tekenen de locatie van gegevens, knoppen, opties en formulieren uit, zodat het team weet wat er gebouwd gaat worden. Na enkele (of tientallen!) schetsen, werkt de UX designer met behulp van tools als Axure of het online UXPin een aantal wireframes uit. Een goed middel om de klant en, na goedkeuring, het ontwikkelteam te laten zien wat we van plan zijn om te bouwen.

Ambrero Blog - UX design voorbeeld wireframe

Een voorbeeld van een wireframe voor Rodeo. Vaak worden alleen grijstinten gebruikt, zodat de aandacht uitgaat naar de plaatsing en functionaliteit van onderdelen. Dit scherm verbeeldt het toevoegen van uren in de applicatie.

In het functioneel ontwerp, het uittekenen van wireframes met wellicht enkele annotaties, wordt de vorm van de applicatie al heel goed duidelijk. We zien waar het menu komt, welke onderdelen daar in staan en hoe de schermen zijn opgebouwd. Met een wireframe geef je ook gebruikersinteractie aan: wat gebeurt er als je op een knop klikt of met je muis op een regel gaat staan? De opvolging van schermen is hier heel belangrijk en kunnen zelfs als opmaat dienen naar een interactief prototype van de applicatie. Daarmee kan de opdrachtgever van begin tot eind door de applicatie klikken, zonder dat er een regel code is geschreven. Daarmee komt de software al in een vroeg stadium van het project tot leven! Sommige projecten lenen zich er zelfs voor om gebouwd te worden op een ‘draadmodel-manier’. Zonder grafische schil is de applicatie dan te gebruiken. Het design, dat meestal na het functioneel ontwerp komt, wordt dan pas na ontwikkeling toegepast.

Met goed UX design zal de docent straks veel minder tijd kwijt zijn met het invoeren van cijfers voor al zijn leerlingen. En zal de beheerder met een druk op de knop meerdere docenten kunnen uitnodigen om te werken met het systeem. En leerlingen? Die zitten minder lang in spanning voordat ze het cijfer van die belangrijke wiskundetoets weten. Want dit systeem is wel heel makkelijk in gebruik!

Erwin Rietveld