Een normaal portfolio laat werk zien. Visueel, plaatjes, dat soort dingen. Als je werkt voor grotere opdrachtgevers mag je vaak niet, of maar gedeeltelijk laten zien wat je gemaakt hebt. Daarom zit dit portfolio iets anders in elkaar.
Je leest mijn beleving van UX, de stappen die daar volgens mij bij horen en de dingen die ik in dat kader gedaan heb. Het is dus meer tekstueel dan visueel, maar geeft nog steeds een goed beeld van mijn werk en werkwijze.
DESIGN IS ALL ABOUT CONTEXT
Geef het beestje maar een naam. Het maakt mij niet uit of je het hebt over user centered design, human centered design, user experience, customer experience of service design. Ook design thinking mag in de grote blender. Voor mij zijn het allemaal termen die op het zelfde neerkomen: zorgen voor gewenste, gebruiksvriendelijke (en liefst ook mooie) software op basis van onderzoek. Onderzoek vooraf, om te kijken welke behoeftes er leven en hoe die matchen met bedrijfsdoelen. Onderzoek tijdens ontwerp om te kijken wat de belangrijkste features zijn en hoe die moeten (samen)werken met andere onderdelen of met het echte leven. Onderzoek achteraf om te kijken of we bereikt hebben wat we wilden bereiken, en waar nodig bij te sturen.
Dus ja: user of human centered. Ja, het gaat om gebruikers (of klanten en customers, want dat zijn ook gebruikers). Nee, de gebruiker is niet altijd zelf de klant. In het geval van bijvoorbeeld een zorgverzekering kan het prima een naaste van de klant zijn die gebruikt maakt van je software. Is helemaal niet raar. Ja, het gaat ook om service design. Mijn werk gaat namelijk verder dan alleen een stukje software maken. Die software daar zit een wereld omheen, en als je daar geen rekening mee houdt gaat je software uiteindelijk anders gebruikt worden dan je verwacht.
Kortom: ik maak graag nuttige software die mensen daadwerkelijk willen gebruiken, op basis van goede onderbouwing door onderzoek bij de doelgroep zelf en een heldere vertaling naar bedrijfsdoelen en -processen. Is de software daarin het moeilijke gedeelte? Vaak niet.
Gelukkig helpen methodes als Design Thinking om de onderbouwing breder uit te leggen. Stakeholders betrekken in bijvoorbeeld een design sprint is meer waard dan een presentatie ooit kan bereiken. Het begrip van wat de beoogde software gaat betekenen en hoe het in het dagelijkse leven past is belangrijk. Dat is wat UX voor mij betekent.
Wat ik doe is software ontwerpen. Dat klinkt alsof je aan een bureau zit met een computer voor je neus, een beetje lijntjes trekken en kleurtjes kiezen. Dat doe ik ook, maar dat is maar een heel klein deel van het werk. Het grootste deel zit in het achterhalen van wensen en noodzaak, van samenhang met andere dingen (ook technisch), het doorgronden van opdrachten en projecten (welk doel wordt gesteld, wat moet er gebeuren), het leren kennen van de gebruikers, schetsen schetsen en schetsen, praten praten praten, meten meten meten, complexe dingen simpel maken, en de rest van de tijd ben ik lijntjes aan het trekken en kleurtjes aan het kiezen. In het proces van software ontwerpen en maken betekent dat ongeveer het volgende.
Bij elke opdracht is dit onderdeel van het werk. Bij het UMCG zelfs een groot deel van het werk, omdat de projecten daar gaan over wetenschappelijk onderzoek waarbij de focusgroepen noodzakelijk onderdeel van de onderbouwing zijn.
Onder andere bij het UMCG veel gedaan, maar ook bijvoorbeeld bij UWV, Menzis en TKP.
Altijd. Bij elk project. Schetsen op papier zijn de basis van elk ontwerp dat ik maak, en de check bij gebruikers levert enorm veel op.
Is vooral relevant in grotere / complexe omgevingen, dus bij Menzis en DUO. Bij het UMCG, de RUG en TKP waren de projecten meer op zichzelf staand.
Detail: het is nooit in steen gebeiteld, maar altijd een richting die bijgesteld kan worden. Scrum en Kanban zijn prima werkwijzes om hier goed mee om te gaan. Dit heb ik onder andere bij het UMCG, de RUG, Menzis en DUO gedaan.
Dat wil zeggen: de schetsen en ideeën die er zijn uitwerken in iets meer software-achtige vorm. Ook altijd, net als het maken van papieren prototypes. Dit is de volgende stap in het ‘echt’ maken.
Met een groep belanghebbenden (zowel vanuit de opdrachtgever als de doelgroep) de belangrijkste punten te tackelen en uit te werken. Helaas altijd in afgeslankte vorm, maar bij UMCG en Menzis wel gedaan. Het blijft lastig om de belangrijke mensen te mogen claimen. Alle losse onderdelen van een design sprint zijn bij Menzis en UMCG de revue wel gepasseerd.
Low fi is heel geschikt om rondes onderzoek mee te doen naar de features en de flow van een product, high fi is noodzakelijk zodat ontwikkelteams weten wat ze moeten maken. Immer en altijd. De laatste fase van ‘echt’ maken.
Ontwerpen bijstellen, kleine tweaks doen, prioriteiten achterhalen, card sorting voor termen en groeperen van onderwerpen, A/B-testen voor optimalisatie). Dit kan op tientallen manieren. Het is maar net wat er op welk moment nodig is. Bij elk project. Bij sommige opdrachten is het een vast onderdeel, bij andere projecten hangt het af van eigen intitiatief, maar ik lanceer geen software zonder dat de belangrijkste punten getest zijn met gebruikers.
Een product aanpassen of iets nieuws lanceren moet je voorbereiden. Mensen zijn niet heel goed in verandering, en worden in sommige gevallen zelfs getraind om niet op afwijkende dingen te klikken (phishing, iemand?). Daarom is een zachte landing van de vernieuwingen nodig, en dus ook een samenwerking met mensen die goed zijn in communicatie. Bij Menzis bestond een groot deel van mijn werk uit de afstemming met communicatieadviseurs en marketeers. Ook bij DUO en TKP kwam samenwerking met deze disciplines vaak om de hoek kijken.
Designers kunnen heel goed mooie dingen bedenken, maar het is wel fijn als die mooie dingen ook gemaakt kunnen worden. Als het technisch haalbaar is, maar ook als het past binnen het datamodel en de services die we kennen. Als de software voldoet aan privacy- en veiligheidseisen. Als de software toegankelijk is. Allemaal zaken waarbij het nodig is om met techneuten af te stemmen. Altijd. Ik kan zelf programmeren, dus weet hoe het is als iets onmogelijks op je bord gegooid wordt met de opdracht ‘maak maar’. Dat wil ik niemand aandoen, dus ik wil zeker weten dat mijn ontwerpen haalbaar zijn. De volgorde van afstemming met bouwteam versus afstemming met gebruiker is soms lastig, maar door goed duidelijk te maken wat de status van iets is lukt het altijd om geen valse verwachtingen te scheppen.
Je kunt iets namelijk nog zo gedetailleerd uitwerken, er komt altijd een moment waarop de praktijk toch anders blijkt te werken. In dat geval moet je met ad hoc antwoorden kunnen komen die geen afbreuk doen aan het eindresultaat, maar de developer van dienst wél verder helpen. Ongoing. Ik werk graag in teams en op locatie, dus iedereen die me nodig heeft kan me vinden.
Je wilt achteraf kunnen bepalen of mensen de software gebruiken zoals je dat voor ogen hebt. Web-analisten zijn hier goed in. Dit zou altijd onderdeel moeten zijn van het werk. Bij sommige projecten (Menzis, TKP) is het standaard, bij andere klanten is het wenselijk maar nog niet zo ingeburgerd. Ik doe in elk geval altijd een poging om het voor elkaar te krijgen.
De genoemde meetplannen zijn hier de basis voor, maar ook andere patronen kunnen boeiend zijn. Herken je afwijkende patronen? Dan is het tijd voor verdiepend onderzoek om te kijken naar de context hiervan. Bij het UMCG ben ik hier onder andere mee bezig. Bij DUO is een apart web-analyse team, waar je samen plannen mee kunt optuigen en meten. Bij Menzis was het een continue samenwerking met analisten en performance marketeers.
Werkt het zoals verwacht? A/B-testen voor optimalisatie. Ook dit is bedoeld om bevestiging te zoeken van het gemaakte. Kan gedaan worden op basis van ontdekte afwijkende patronen, maar ook generiek om te kijken hoe je doelgroep met echte software omgaat. Dit deden we bij UWV bijvoorbeeld na elke grote release. Daar splitsten we een usability onderzoek op in 2 delen: 1 deel controle van gemaakte software en 1 deel checken van nieuwe features.
Zie je dat je met je software niet bereikt wat je dacht? Of merk je nieuwe mogelijkheden op? Dan is dit eigenlijk het moment om weer vooraan in de cirkel te beginnen, door onderzoek te doen en opnieuw te gaan designen. Is het maar een klein iets? Dan los je het concreet op.
In veel corporate instellingen is rapportage een standaard onderdeel van het werk. Projecten en programma’s moeten regelmatig updates geven over voortgang. Soms alleen binnen de organisatie, soms ook daarbuiten. De Excel-manier doorbreken door met echte feedback van gebruikers te rapporteren levert vaak een boel meer reactie op dan een spreadsheet met cijfers. Het maakt de cijfers ‘echt’, door ze te vertalen naar de menselijke realiteit. Bij Menzis en DUO deed ik dit in sommige gevallen.
Het lijkt hierboven alsof bepaalde werkzaamheden alleen in één fase gedaan mogen worden. Dat is niet zo, vaak lopen werkzaamheden door elkaar heen. Het gebeurt net zo vaak dat je op verschillende horizonnen aan het mikken bent. Je maakt concrete ontwerpen voor de komende weken, doet onderzoek voor de komende 3 maand, en bent bezig met een roadmap en focusgroepen voor over een jaar. Is niet gek, maar vergt wel een flexibele geest om daar goed mee om te gaan.
Klinkt een beetje hoogdravend, maar ik heb alle onderdelen van UX wel te pakken gehad in de loop der jaren. In sommige dingen ben ik goed (complexe trajecten en processen doorgronden, en vertalen naar simpele software), bij andere dingen is er heus wel een betere te vinden (web-analyse, visual design). Maar ik weet wat er waarom nodig is op welk moment, en hoe we dat kunnen organiseren. Het grootste nadeel: ik wíl UX niet in mijn eentje doen. Een eenzame UX’er levert namelijk nooit het beste eindresultaat op. UX is een vrij centrale rol in software ontwikkeling, die soms nog het meeste raakvlakken heeft met een tolk. Je vertaalt de echte wereld naar de proceswereld, naar ontwerpen, naar techniek en (ook niet onbelangrijk) andersom. Als dat zorgt dat verschillende mensen elkaar begrijpen ben je al goed op weg naar succes.
CONTEXT IS ALL ABOUT DESIGN
