UX en Service Design

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

UX – Ontwerp in procenten

UX en Service Design

Het is vaker gezegd: UX ontwerp wordt maar moeilijk begrepen. Veel mensen voelen niet aan dat ontwerp van een moeiteloze gebruikerservaring niet moeiteloos gaat.

Procenten
Zo kreeg ik laatst nog van iemand te horen dat je bij ontwerp 80% hetzelfde kan gebruiken (“best practices”) en dat je dan 20% interactie design of usability bij kan doen om “het verschil’ te maken…

Tja, autobestuurders rijden veel op routine maar je kunt toch echt niet zeggen dat je voor 80% met je ogen dicht kan rijden omdat er maar 20% van de tijd een risicosituatie is waar je het verschil echt maakt. Hoe komt iemand op zo’n idee?

Van scherm naar flow
Ik ga niet op de percentages in, die zijn nergens op gebaseerd. Maar ik snap wel waar die best practices vandaan komen.

image

Natuurlijk zijn er interactiepatronen die zich bewezen hebben: een duidelijk zichtbare hoofdnavigatie bijvoorbeeld. Vreemd genoeg zijn juist dàt de zaken die binnen een design vaak onder druk staan omdat het ‘niet spannend’ genoeg is. Maar het is waar: wanneer heel de wereld de ervaring heeft dat iets op een bepaalde manier werkt, kun je dat beter maar ook zo doen.

Maar waarom is het dan geen kwestie van schermen als een bouwpakket in elkaar klikken?

UX ontwerp is meer dan schermen ontwerpen

UX ontwerp richt zich erop om het gedrag van de bezoeker te beïnvloeden. En dat doe je door informatie en vertrouwen en gebruikersgemak te geven. Dat gaat veel dieper dan een set wireframes produceren. Je kunt het werk het beste te vergelijken met het slim inrichten van een winkel:

image
  • Welke indruk krijgen de bezoekers wanneer ze binnenkomen?
  • Hoe blijven ze geïnteresseerd wanneer ze langs de rekken lopen?
  • Welke routes wil je graag dat ze in de winkel doorlopen?
  • Hoe en waar verleidt je ze tot actie?

En vervolgens test je of de inrichting voor de bezoekers werkt, keer op keer. Een goede UX designer is dan ook de warme combinatie van architect, scenarist en gedragspsycholoog in één.

Teamwerk

Maar een UX ontwerper doet dat niet alleen. Ontwerpen doe je met een team. Wat voor team? De functieomschrijvingen kunnen enorm verschillen, maar in de basis heb je mensen in het team die zich met onderzoek bezighouden (doelgroep onderzoek, informatie analyse en testen) en mensen die ontwerpen (interface, visual design en front end development). De verdeling over mensen hangt af van het soort project en natuurlijk het budget.

Design is kostbaar

Al dat werk kost geld, zeker. Maar het levert ook iets heel belangrijks op: conversie. En dat was toch de reden waarom je als bedrijf überhaubt in een applicatie investeert?

Dus durf te investeren in onderzoek en ontwerp. Durf te meten en te testen. Pas je ontwerp aan wanneer het niet voldeed en test dat opnieuw. Het is de enige echte manier om tot een lonend product te komen.

De UX Unicorn

UX en Service Design

Ik hoorde laatst de naam voor een UX designer die ‘alles’ binnen een bedrijf doet op het gebied van UX design: de UX unicorn.

Laat ik deze blog eens kort houden: een bedrijf wat maar één iemand op het volledige UX spectrum inzet, is een bedrijf wat zich niet met UX design bezighoudt maar een hippe term misbruikt. Aan alle unicorns die in zo’n situatie zitten: sterkte!

UX – Storymapping

UX en Service Design

Ik ben momenteel veel bezig met storymapping. Dit is een mooie vorm om in teamverband wensen en oplossingen in kaart te brengen. Zie het als een backlog waarbij horizontaal wensen op procesniveau worden geordend en vertikaal de prioriteit wordt aangegeven. Zo’n storymap komt er dan zo uit te zien:

De sessie

  1. Ten eerste; gebruik zoveel mogelijk de user story vorm: Als {doelgroep} wil ik {dit kunnen doen} om {dat te bereiken}.
  2. Definieer de doelen die je wil bereiken
  3. Omschrijf per doel de activiteiten om die doelen ook te bereiken. Orden die horizontaal op chronologische volgorde. Voorbeeld: wanneer je schoenen wil kopen, wil je eerst schoenen bekijken en vervolgens bestellen.
  4. Splits de activiteiten weer verder op in deeltaken, bijvoorbeeld ‘de schoen bekijken’, ‘kleuren vergelijken’, ‘de maat checken’, ‘prijs beoordelen’, enzovoort. Al deze taken zijn kleine user stories.

Prioriteiten

Alle taken (de gele briefjes in mijn tekening) vormen de uiteindelijke backlog. Het enige wat je nu nog moet doen is je Minimal Viable Product bepalen. Dat doe je zo:

  1. Orden alle taken naar beneden toe op prioriteit, de belangrijkste bovenaan
  2. Trek een horizontale streep onder alle user stories die absoluut nodig zijn om je eerste versie van het product op te leveren: dat is je MVP.
  3. Daaronder kun je nog meer onderverdelingen maken; dat worden je latere releases, al kan het natuurlijk zijn dat prioriteiten daar nog flink gaan schuiven. Hier kom je dus later op terug.

Dat is het.. mooi he? Ik ben erg tevreden met deze methode. De storymap is voor mij de inhoudelijke verbinding tussen UX en backlog. Er zou veel meer gebruik van moeten worden gemaakt.