Wat doet een UX designer?

UX en Service Design

Een beetje UX designer weet niet precies wat hij of zij is, daar is het vak veel te breed voor. Daarom is al jaren terug de term UX unicorn uitgevonden, dat magische wezen dat alles kan wat maar met ‘user experience’ te maken heeft.

Wat de unicorn voor UX is, is de T-shape voor de rest van de wereld. T-shaped is een metafoor om je professionele vaardigheden te beschrijven waarbij je ‘in de breedte‘ meer dan een expertise hebt (horizontaal), maar binnen die expertises op bepaalde onderdelen gespecialiseerd bent (vertikaal).

Zo’n term is dus op maat gesneden voor een UX designer zou je zeggen, maar veel vind je er toch niet over. Ik kom online alleen het model van Peter Boersma tegen en dat stamt al uit 2004! Zijn T-shaped model voor User Experience Design ziet er zo uit:

We zijn ondertussen een aantal jaren verder, maar qua model is het nog behoorlijk actueel. Het enige onderdeel wat ik er in mis, is ‘Animation design‘, wat niet meer weg te denken is sinds mobiel de standaard is geworden.

Tegelijkertijd is deze indeling zó veelomvattend dat echt niemand verstand van al die onderdelen kan hebben. Grofweg zie ik binnen dit model twee type UX’ers (procesontwerp en applicatieontwerp) én een Online Marketeer terugkomen. Ik zou zelf Marketing uit het model weglaten en het model indikken tot alles wat met ontwerp te maken heeft:

Voila, dit is het spectrum waarbinnen een UX designer zich al jaren begeeft. En dan zijn jullie vast heel benieuwd hoe T-shaped ik dan ben? Hieronder zie je waar ik mij in thuisvoel:

Voila, het is wel duidelijk dat ik een proces designer ben. Waar je mij dan ook het beste voor kunt bellen, is voor het opbouwen van een goed verhaal. En dat komt dan weer omdat ik niet alleen UX designer maar ook striptekenaar ben. Ik ben niet T-shaped maar π-shaped.


UX – Template trends, de ‘Pinterest’

UX en Service Design

Een tweede templatevorm die ik dit jaar veel voorbij zag komen was ‘de Pinterest’. Ik noem hem maar even zo omdat Pinterest verantwoordelijk is voor het grote succes van deze vorm.

Wat is de Pinterest?
De Pinterest is niets anders dan een verzamelpagina. Ze heeft, in tegenstelling tot de one-pager, totaal geen verhaalopbouw. Op deze pagina is het niet de bedoeling dat je ‘zoekt’, maar dat je rondsnuffelt zoals op een rommelmarkt of in een boekenkast.

Voorbeelden? Pinterest dus, maar je ziet deze vorm ook vaak bij thema-sites (kookrecepten) en magazines (mode, lifestyle e.d.).

Wanneer wel, wanneer niet?
Deze vorm is erg mooi voor mensen die rustig rond willen kijken. Maar laten we wel wezen: de meeste mensen hebben geen tijd. Dat is dan ook meteen het belangrijkste bezwaar bij deze vorm.

Gebruik de Pinterest niet wanneer:

  1. je gebruikers snel en gericht naar de juiste informatie op zoek zijn
  2. je een verhaalopbouw op de pagina wilt gebruiken
  3. de informatie zelf te complex en te divers is om zo eenvoudig te verpakken
  4. je als organisatie geen interessant beeldmateriaal hebt.

Ik zag het vaak misgaan dit jaar: pagina’s met nieuwsberichten, opleidingen, banners, tools, allemaal in dezelfde blokjes gegoten. Vervolgens werden die blokjes toch maar weer gegroepeerd door er extra titels tussen te plaatsen. En elk ‘type’ blokje kreeg dan weer extra eigen elementen: tags, iconen, lees meer buttons, profielfoto’s en wat nog meer. Het eindresultaat was steevast hetzelfde: een onoverzichtelijke boel.

Maar de grootste fout die bij deze template wordt gemaakt, is dat eindgebruikers alléén maar op de pagina kunnen doorklikken; waarbij elk blokje niets anders is dan de introductie voor de vervolgpagina.

De Pinterest is geen introductiepagina, maar juist een eindpunt waarbinnen eindgebruikers moeten kunnen kijken, kiezen en delen. Doorklikken is optioneel.

Kies dus alleen voor deze vorm wanneer je content daarbinnen consistent, aantrekkelijk en compleet kan worden weergegeven. Maar deze conclusie zou niemand moeten verbazen; wat voor de Pinterest geldt, gaat voor alle templatevormen op: uiteindelijk is het altijd de kracht van de content die het succes bepaalt.

UX – Probleempraters

UX en Service Design

Soms kun je veel van je dochter van tien leren. Een paar maanden geleden hebben we een nieuwe fiets voor haar gekocht. Ze was er ontzettend blij mee, want de oude fietste veel te zwaar.

Dus waarom wil ze deze week per se op die oude fiets naar het schoolkamp? 15 kilometer op een logge fiets waar ze altijd een hekel aan heeft gehad? Ze wuifde al mijn argumenten weg; het moest en zou die oude fiets zijn. Ik werd er gek van. Waarom geloofde ze mij nou toch niet? Daar kwam ik pas achter toen ik ophield met argumenteren en door ging vragen waarom ze dat nou per se wilde..

En wat bleek? Ze was helemaal niet bezig met welke fiets het beste was. Ze was bezorgd dat ze op haar nieuwe fiets niet genoeg spullen mee kon nemen. Alleen omdat op de oude fiets nog fietstassen zaten, wilde ze die hebben! Ze had dus een uitstekende oplossing voor haar probleem bedacht en daarmee was het voor haar klaar.

Ik denk dat het in het bedrijfsleven er ook heel vaak zo aan toe gaat. Begin dus, wanneer je een probleem bij een oplossing signaleert, eerst met vast te stellen of de ander het over de oplossing van hetzelfde probleem heeft. Dat scheelt een hoop communicatieproblemen :).

UX – Design Principes

UX en Service Design

Ik gaf afgelopen week een workshop aan het SintLucas in Noord Brabant. Een klein jaar geleden had Evident met deze school de strategielijn voor de ‘Online Creative Community’ ontwikkeld en deze week pakten we daarop door. We gingen in een week tijd niet alleen een plan van aanpak voor de Community bepalen, maar ook een conceptontwerp voor een eerste applicatie maken. Een ambitieus plan en ik had serieus mijn twijfels toen ik er aan begon, maar de week was erg leuk en succesvol. Daarvoor waren er twee redenen:

  1. De werkgroep bestond uit fijne, gedreven mensen.
  2. En we hebben sterk de nadruk op Design Principes gelegd

Wat zijn Design Principes?

Design principes zijn richtlijnen die je helpen bij het ontwerpen van je product. Kort gezegd, leg je daarmee vast op welke manier de eindgebruiker je product gaat ervaren. Dat is belangrijk voor een enkel product, maar het wordt nog belangrijker wanneer je meerdere producten binnen een platform gaat ontwikkelen. Wanneer je de samenhang daartussen wil garanderen, dan moeten er regels zijn waar iedere ontwikkelaar zich aan moet houden.

Ik zie Design Principles als ontwerpregels op strategisch niveau. Voorbeelden? Kijk maar eens bij Android, Windows of bij Apple.

Toen ik in de werkweek uitlegde wat Design Principles zijn, kreeg ik natuurlijk ook kritische opmerkingen. Terecht, want of je nou Android, Windows of Apple gebruikt, je komt altijd programma’s tegen die niet bepaald aan de regels voldoen. Wat voor nut hebben zulke principes nou wanneer bedrijven zich er niet aan houden? Zijn ze niet een beetje ‘idealistisch’?

Misschien wel, er zijn altijd factoren waardoor een product niet wordt wat je ervan had verwacht. Maar dan nog heb je er veel aan om zulke principes vastgelegd te hebben. Je hebt namelijk niet alleen spelregels nodig om een spel te spelen maar ook om om over het spel te kunnen praten.

Design Principes dienen vooral de communicatie

Dat laatste is hetgene wat ik deze week als het meest bijzondere heb ervaren. De groep op SintLucas bestond uit directieleden, docenten, studenten en mensen uit het bedrijfsleven. Ik was verrast hoe vaak ze de design principes aanhaalden om richting aan discussies te geven, weerstand weg te nemen en beslissingen te nemen.

Daarbij werd ook heel duidelijk dat er twee het belangijkste waren:

De eerste stap

Design principes zijn geen garantie voor een fantastisch product, maar ze zijn wel een voorwaarde. Die eerste voorwaarden zijn bij SintLucas benoemd, ik ben heel benieuwd wat er verder gaat komen. Meer weten over Design principes? Op designprinciplesftw.com vind je een geweldige set om op verder te werken: UXaxioms.

UX – Ontwerpers in het agile tijdperk

UX en Service Design

Hebben jullie het al gemerkt? De functionele ontwerper is verdwenen. Door de enorme populariteit van ‘agile’ worden er geen functionele ontwerpen meer geschreven. Wat doen die mensen dan nu? Veel functionele ontwerpers zijn scrummaster geworden. Waren ze eerst de architecten van een ontwerp, nu lijken ze meer op een coach die het team en de klant inhoudelijk houvast biedt.

Een agile aanpak biedt veel voordelen: teamwerk, snel schakelen, niet kapot ontwerpen, gemakkelijker van inzicht kunnen veranderen. Allemaal hartstikke mooi, maar ik hoor weinig mensen over de nadelen praten:

  • Geen tijd om eens rustig over je aanpak na de denken.
  • Daardoor geen duidelijke visie op de lange termijn
  • Geen gestructureerde documentatie voor wanneer een project twee jaar later opnieuw wordt opgepakt en alle mensen uit het oorspronkelijke team zijn verdwenen.

Agile en UX

Maar niet alleen de functionele ontwerper is omgeschoold, ook de interactie designer en visual designer worden anders ingezet. Ze zijn nu allemaal onderdeel van het team waarbinnen gezamelijk de beslissingen worden genomen. En ook daar zitten voor mij een paar pijnpunten:

  • Hoeveel tijd hebben ontwerpers binnen een sprint?(Ik ken weinig situaties waarin ze full time betrokken zijn, dat is te duur)
  • Hoe zwaar weegt hun expertise binnen een team? (Nu lijkt het erop, dat ze er vooral bij zitten voor wanneer de programmeurs iets nodig hebben)
  • Hoeveel tijd en ruimte hebben ontwerpers om eens even na te denken, om uberhaubt een visie te ontwikkelen?

Bezint eer gij sprint

Dat moment om na te denken is natuurlijk wel benoemd: soms wordt dat sprintX genoemd, anderen wijzen naar sprint0. Maar hoe ze het ook noemen, de invulling ervan blijft vaak vaag (iets met een Minimum Viable Product en prioriteiten stellen). De intentie is ten slotte om zo snel mogelijk ‘echt’ te beginnen.

En daar zit volgens mij een groot probleem: de gedachte is namelijk dat je pas echt begint, wanneer je code schrijft. Een denkrichting uitproberen, daar een prototype van maken en het idee testen? Veel te duur! Dan ‘heb je nog niks’… Er wordt dus te weinig ruimte gemaakt voor sprints waarin aannames testen belangrijker is dan de ontwikkeling van het eindproduct. Jammer, want het loont echt wel om te testen of je gebruikers je ontwerp wel wíllen gebruiken.

Niets nieuws onder de zon, maar wel nieuwe kansen

Maar dat is niets nieuws natuurlijk. Er werd vroeger wel veel tijd besteed aan het ontwerp en documentatie, maar ook toen werd niet gekeken of een idee echt werkte totdat het online stond (en dan nog…).

De agile aanpak sluit in wezen veel beter aan op User Centered Design dan de watervalmethode. We kunnen met deze aanpak sneller ideeën ontwikkelen, sneller testen, sneller bijstellen, allemaal geweldig! Agile is juist bedoeld om van inzicht te kunnen veranderen, neem daarom conceptontwikkeling daarbinnen serieus:

  • Geef toe dat je het allemaal nog niet weet!
  • Durf te experimenteren en te varieren!
  • Test je ideeën!
  • Durf ideeën weg te gooien!

De toekomst

Hoe ontwikkelen we over twee jaar software? Ik heb eerlijk gezegd geen flauw idee. Misschien wordt agile weer even hard de kast in geduwd als het er nu is uitgetrokken. Ik verwacht dat het gebrek aan documentatie in ieder geval hard gevoeld zal worden. De functioneel ontwerper komt daarom wel terug, niet alleen als coach maar ook als verslaggever; de journalist van het project.

Welke rol UX ontwerpers, visual designers en interactie designers gaan hebben, vind ik moeilijker te voorspellen. Maar ik hoop dat ze het allemaal heel druk zullen hebben met conceptontwikkeling in een agile werkvorm.

UX – Software gebruikers

UX en Service Design

Laatst liep ik een dagje mee bij een bedrijf om te kijken wat de werknemers daar op een dag doen. Ze maken gebruik van een oude applicatie die ze dolgraag willen vervangen.

Het was geweldig om te zien hoe de mensen rondom alle problemen van de software heen werkten, ik hoorde de hele tijd ‘maar dat is geen probleem hoor’. Wanneer mensen dat zeggen, weet je namelijk zeker dat er een probleem is. Maar mensen vinden altijd manieren om hun werk voor elkaar te krijgen. Sterker nog: als je zo met software om kan gaan, ben je specialist!

Maar die ervaring en gewenning van gebruikers levert bij het ontwerpen voor een nieuwe applicatie ook een barriere op: wanneer je oplossingen voor problemen bedenkt, betekent dat dat de doelgroep opnieuw moet gaan leren. Ik ken niemand die dat graag doet, inclusief mijzelf.

Gebruikers kunnen zelfs meteen een afkeer van het systeem krijgen, ook al zou het, na een leercurve, beter werken.

Daarom de volgende kleine aanbevelingen:

  1. Geef gebruikers de gelegenheid en tijd om een systeem te leren. (Jawel, dit wordt heel vaak vergeten)
  2. Richt je ontwerpproces niet op de ideale werkwijze, maar op de werkelijkheid (oftewel: staar je niet blind op de logica van een proces op zich)
  3. Sta tijdens het ontwerpen steeds stil op wat een oplossing eigenlijk oplevert: soms zijn de praktische oplossingen van de gebruikers echt beter dan de logische oplossingen binnen het systeem