Discover: UX exploratie met de stakeholders

De architectuur van je digitale oplossing

Een bouwvakker begint niet zomaar een muur te metselen zonder te weten hoe deze in een groter plaatje past. Eerst moet een architect uittekenen waar die muur moet komen te staan. Een architect begint ook niet zomaar met tekenen van die muur. Allerlei factoren zullen zijn ontwerp beïnvloeden. Locatie, doel, wetgeving, materiaalkeuze, etcetera. 

UX-ers zijn in principe de architecten voor je digitale oplossing: we hebben een tool-set en bepaalde methodes om de wensen en behoeftes van alle partijen (eindgebruikers, stakeholders en ontwikkelaars) goed in kaart te brengen. Net zoals de bouwvakker gaan designers en developers dus nog niet meteen aan de slag, want die weten nog helemaal niet wat we ze moeten gaan ontwerpen en ontwikkelen. Er zijn nog geen kaders geschetst. Daarom is de eerste stap (na het verkooptraject) aan UX-design. UX Designers zorgen ervoor dat de kaders en scope, ideeën en visies, must haves en nice to haves gedefinieerd en gedocumenteerd worden in de zogeheten Discovery fase. Eerder hebben we al uitgelegd waarom de Discovery fase zo belangrijk is, nu leggen we uit hoe we dit doen:

1. Discover:

In deze fase gaan we “ontdekken” wat het project voor kaders heeft. Alle al bestaande informatie wordt in kaart gebracht, en nieuwe inzichten worden gecreëerd met behulp van de experts in de organisaties zodat we voldoende onderbouwing hebben voor keuzes die we moeten gaan maken. Deze fase kan onder andere bestaan uit:

• Desk research:

Voordat we onze eerste workshops of interviews starten, onderzoeken we wat de huidige stand van zaken is. Welk onderzoek is er al gedaan? Wat voor content hebben we tot onze beschikking? Welke stakeholders moeten er betrokken worden? Etcetera. Op basis van deze informatie (of gebrek daaraan) richten we onze vervolgstappen pas echt in. 

• Expert review:

Niet elke nieuwe oplossing is een geheel nieuw begin. Soms bestaat er bijvoorbeeld als een oude website en moet deze plaats maken voor een nieuwe. Een analyse van de oude website (UX Review) is voor een bureau een makkelijke manier om al veel informatie op te halen. We kunnen daar bijvoorbeeld al een deel van de huidige datastructuur uit ontleden. We bekijken ook wat er al wel aanwezig is, wat we eventueel kunnen meenemen naar de nieuwe oplossing, en wat er nog mist voor een goede gebruikerservaring in de oude situatie.

• Stakeholder interviews:

Deze extra (optionele) stap zetten we vaak in als we de organisatie en stakeholders die daar werken goed willen leren kennen omdat we een lang traject ingaan. Deze stap doen we ook vooral als het gaat om oplossingen die ten behoeve zijn van de interne organisatie zelf, zoals een intranet. Is de materie erg lastig om voor externen te begrijpen dan kunnen stakeholder interviews ons ook helpen om ons beter voor te bereiden op de vervolgstappen. Als bijvoorbeeld medische informatie lastig is om te begrijpen voor een buitentaander, kunnen interviews helpen om deze te kunnen plaatsen in de uiteindelijke oplossing.

• Doelgroep analyses:

Bij de start van een nieuw project beginnen we meestal met het in kaart brengen van de doelgroep(en). Dit doen we meestal met de creatie van Persona’s. Persona’s zijn virtuele klantprofielen die een deel van je gebruikers vertegenwoordigen. 

Omdat je, zeker bij het ontwikkelen van een nieuwe oplossing, niet weet wat een groep gebruikers nodig heeft, of wat wel en niet werkt voor deze gebruikers, zal je je denkkader moeten verbreden en je moeten verplaatsen in anderen. Voor bureauzijde is dit essentieel om een goed beeld te krijgen van alle potentiële doelgroepen en vooral hun behoeftes, we gaan namelijk straks ook bouwen en ontwerpen voor hen. 

Hoe gedetailleerd zijn Persona's?

Vroeger was een persona vaak heel gedetailleerd (bijv. Susan, 34 jaar oud, ambulant medewerker bij een zorginstelling, heeft een golden retriever, een huis in IJsselstein, gaat op vakantie in Frankrijk, heeft een iPhone, etcetera).Tegenwoordig gaan we daar iets genuanceerder op in. De Golden Retriever is niet zo interessant (in context, voor een website over hondenvoer is de Golden Retriever natuurlijk wel interessant). Wel interessant is dat ze bijvoorbeeld een website zal bezoeken op haar iPhone omdat ze als ambulant medewerker vaak onderweg is, en ze de oplossing nodig heeft voor informatie binnen handbereik.

Een ander manier om gebruikersbehoeften te achterhalen zijn interviews met uiteindelijke (potentiële) gebruikers. Door meerdere gebruikers te vragen wat ze graag zouden willen doen (en hoe) zie je al vaak veel overlap in wensen en behoeftes. Eventueel kan deze nog aangevuld worden met inzichten vanuit stakeholders, dan is het plaatje ook compleet. 

Een voorbeeld van Persona's:

Voor de ontwikkeling van Dyslexie Centraal kwamen we tijdens een persona workshop achter het aantal doelgroepen die de website moest ondersteunen. Uiteindelijk konden we daar maar liefst vijf hoofddoelgroepen definiëren: 

1. Jongeren met Dyslexie (Voortgezet Onderwijs) 
2. Ouders van kinderen en jongeren met Dyslexie (Basisonderwijs en Voortgezet Onderwijs)
3. Leraren met dyslectische leerlingen in hun klas
4. Begeleiders voor deze leraren 
5. Beleidsmakers

Initieel keken we zelf, met de kennis die we toen (niet) hadden, primair naar doelgroepen twee en drie. En zonder een doelgroepanalyse en stakeholder input waren we misschien ook alleen voor deze gaan ontwerpen. De kennis van doelgroepen die we in deze discover fase hebben opgedaan, hebben we direct meegenomen in het vormgeven van de nieuwe website.

• “User needs” / gebruikersbehoeften:

Nu je weet voor wie je de digitale oplossing maakt, ga je ook in kaart brengen wat deze doelgroepen graag willen kunnen doen. De behoeften van ouders in het bovenstaande voorbeeld zijn bijvoorbeeld deels anders dan die van een leerkracht. En beide moeten ze kunnen doen waar ze voor gekomen zijn. Deze behoeften noemen we user needs.

Willen mensen informatie lezen? Hulpmiddelen downloaden? Een vraag kunnen stellen? Een verwijzing krijgen naar een andere instantie die ze kan helpen met een bepaald probleem? 

Je zult de oplossing dus moeten inrichten op alle doelgroepen en hun behoeften en deze allemaal zo goed mogelijk verwijzen naar de voor hen relevante informatie of handelingen. Soms ook informatie op een verschillend niveau. Een jongere met dyslexie heeft een andere manier van consumeren en handelen dan een beleidsmedewerker.

• ”Business goals” / organisatiedoelstellingen en digitale KPI’s:

Vaak wordt er een grote investering in geld en tijd gedaan door de organisatie en je wilt wel kunnen bewijzen dat de uiteindelijke oplossing meerwaarde heeft voor alle partijen. Iedere organisatie heeft doelstellingen die ze probeert te realiseren. Verkoop van producten of services, verlenen van diensten, informatievoorziening, preventie, etcetera. Praktisch worden deze vaak vertaald in business goals. Het is handig als die later ook meetbaar gemaakt kunnen worden. Maar dan moet je ze eerst wel definiëren.

Business Goals die ook nog eens een overlap vertonen met user needs zitten in de zogenaamde sweet spot. Deze sweet spot zal de harde kern worden van de uiteindelijke oplossing, omdat deze de meeste impact voor alle betrokkenen heeft. 

• Customer Journey:

Nadat we deze stappen hebben gezet staat er vaak nog een hele hoop vragen open omtrent het “dagelijks gebruik” van de oplossing. De behoeften van een gebruiker zijn concreet. Hoe, waar, wanneer hij deze wil of gaat vervullen is ook belangrijk

Een bezoek aan bijvoorbeeld een website is idealiter vaak niet eenmalig (afhankelijk van de doelstelling). Het is dus relevant om in kaart te brengen waarom een gebruiker terug komt, wanneer die dat doet, en hoe. Elke keer als een gebruiker je oplossing gebruikt kan hij er ook vanuit een andere invalshoek terecht komen. 

Neem als simpel voorbeeld het boeken van een vakantie, dat zou zo kunnen gaan voor een specifieke gebruiker:

• Browsen (oriënteren op website)
• Bekijken (content pagina's, media)
• Beslissen (reviews en concrete facilitaire informatie)
• Boeken (check-out)

Dit is een voorbeeld van een hele simpele lineaire customer journey. Maar vaak is een customer journey helemaal niet zo duidelijk of zijn er nog veel meer of minder stappen. Een andere gebruiker pakt het misschien wel anders aan, zoals:

• Wachten op aanbieding van reisorganisaties (nieuwsbrief, mailings, social media)
• Boekt dezelfde camping nog een keer voor volgend jaar (check out)

Als je hier geen rekening mee houdt, en dus je communicatie op en om het platform niet in orde hebt, gaat de klant misschien wel naar een organisatie die de gebruiker wél op tijd en goed benadert. De eerste journey doen de meeste mensen bijvoorbeeld vaak na de Kerstperiode, de tweede al veel eerder na een goed aanbod in november, etcetera.

Klanten met in principe dezelfde behoeften (een gezinscamping in Zuid Frankrijk) kunnen dus op een heel andere manier daar terecht komen. Je oplossing zal dit alle twee moeten (kunnen) faciliteren, anders mis je een deel van je potentiële doelgroepen. 

In het volgende deel van deze blog reeks zullen we stap twee: define exploreren.