Branches
Uitgelichte oplossingen
Pixelpillow
Burgemeester van Roijensingel 11
8011 CT Zwolle
8011 CT Zwolle
Welkom bij Pillowtalk, de podcast waarin we op zoek gaan naar de ultieme gebruikerservaring in het digitale domein en daarbuiten. Hoi, ik ben Milan van der Brugge, nog steeds account director bij Pixelpillow. En ik host deze podcast. Naast me zit vriend, collega, compagnon, zwembuddy Joel Cox. Joel Cox is technisch verantwoordelijk bij Pixelpillow en mede-eigenaar. En ik ben Gert-Jan, ik ben art-director en ook mede-eigenaar van Pixelpillow. Vandaag gaan we het hebben over hoe design thinking zich verhoudt tot bijvoorbeeld het werken volgens het waterval principe. Kortom, genoeg te bespreken. Wij zijn als bureau dagelijks bezig met het ontwerpen van geweldige gebruikerservaringen. En daarom hebben we een fascinatie voor de vraag, wat is de ultieme gebruikservaring? De gangbare naam voor de gebruikerservaring is in jargon user experience, oftewel UX. En elke podcast beginnen we met de UX fuck-up van de week.
Recent was er wat online rumoer over de nieuwe Airpods Pro van Apple. Deze nieuwe, dure versie met noise cancelling trok de aandacht. Apple heeft een speciale pagina voor dit product gelanceerd, vol met de gebruikelijke indrukwekkende visuals.
Op de productpagina wordt informatie dynamisch weergegeven tijdens het scrollen, waarbij verschillende elementen en animaties op het scherm verschijnen. Dit ontwerp heeft gemengde reacties uitgelokt: sommigen zijn gecharmeerd van deze visuele flair, terwijl anderen het juist als hinderlijk ervaren. Mijn eigen indruk is dat de website, zoals vaak bij Apple, er visueel aantrekkelijk uitziet, hoewel er ook enkele kanttekeningen zijn.
Hoewel de presentatie van het product op zich indrukwekkend is, alsof het op een podium wordt gezet, merk ik dat sommige aspecten van de gebruikerservaring als storend kunnen worden ervaren. Een veelgehoorde klacht is dat het lijkt alsof Apple de controle over de scrollfunctie van de computer overneemt, wat een gevoel van irritatie kan opwekken.
Persoonlijk sta ik ambivalent tegenover deze aanpak. Aan de ene kant waardeer ik de creativiteit die Apple toont, vooral omdat de website in essentie gericht is op het bieden van een unieke ervaring. Aan de andere kant begin ik me te ergeren wanneer de interactie tussen het scrollen en de animaties inconsistent wordt. Dit leidt tot een bijna RSI-achtige ervaring, waarbij je je eigen vinger niet meer vertrouwt.
Mijn ervaring met het bekijken van de pagina op een groot scherm, zoals mijn MacBook Pro, is ook niet altijd vlekkeloos. Er zijn momenten waarop de pagina hapert, wat suggereert dat de optimalisatie wellicht meer gericht is op mobiele apparaten en tablets. Dit blijkt ook uit het feit dat de problemen minder prominent aanwezig zijn op mobiele apparaten en iPads.
Tot slot, ondanks de gemengde gevoelens over bepaalde aspecten van de website, blijft het een indrukwekkend ontwerp. Het is echter jammer dat de interactieve elementen soms de natuurlijke controle over het scrollen wegnemen. We nodigen onze luisteraars uit om hun eigen ervaringen en UX 'fuck-ups' te delen via pillowtalk.nl en ons te volgen op Instagram onder de naam Pillowtalk the podcast voor updates over nieuwe afleveringen.
Hey, deze week gaan we het hebben over design thinking. We beginnen met een kleine inleiding van wat dat nou precies is. Er zijn allerlei termen in de omloop zoals service design, human centered design, user interface design en user experience design.
Het kan verwarrend zijn met zoveel verschillende termen. Design thinking is eigenlijk een methode waarbij de mens, de gebruiker, centraal staat. Het gaat om een systematische benadering om te inventariseren en te verifiëren wat de werkelijke behoeften zijn van de gebruiker. Het doel is om een match te vinden tussen technologische mogelijkheden, business doelstellingen, en wensen van de gebruiker. Wanneer een oplossing al deze aspecten raakt, is design thinking succesvol toegepast. Het is meer een mindset dan een vaste methodiek; de concrete toepassing kan variëren. Het gaat meer om het uitgangspunt dat je de mens centraal stelt, dat je het valideert of het technologisch haalbaar is en of je bedrijf of gebruiker er daadwerkelijk beter van wordt.
We bespreken een aantal stellingen. De eerste is: ‘Iedereen is een ontwerper’. Is dat waar? Ja, in zekere zin wel. Ontwerpen is niet alleen hoe iets eruit ziet, maar vooral hoe iets werkt en problemen oplost. Wij zien ontwerpen als problemen oplossen, nadenken over hoe iets werkt. Ja, dat kan eigenlijk iedereen, denk ik. En ik denk dat de meeste mensen dat in hun dagelijkse bezigheden ook gewoon doen. Er zijn heel veel beroepen waar je problemen oplost. Alleen bedenken wij dan een vorm waarmee je dat vaak visueel en vooral functioneel oplost. In digital design gaat het vaak meer over functionaliteiten dan vorm, in tegenstelling tot bijvoorbeeld drukwerk. Daarbij is de vorm vaak wat belangrijker. Als je een boek maakt bijvoorbeeld. Een boek is een boek. Je kunt wel alternatieven bedenken, maar dan ervaren mensen het al snel niet meer als een boek.
Terug naar de stelling, is het goed om uit te diepen wat we met iedereen in dit geval bedoelen? Het is tegenwoordig gebruikelijker dat een project samen met een klant wordt gedaan, zoals een klantportaal of productconfigurator. Dit was niet altijd het geval; klanten dropten een opdracht bij een bureau en wachtten op de ‘big reveal’. Dit proces accepteert een klant tegenwoordig niet meer, wat ook terecht is.
Maar wie bedoelen we met ‘iedereen’? Dit betekent letterlijk iedereen, van klanten tot kinderen. Als je een oplossing voor een probleem kunt bedenken en vormgeven, kun je jezelf in zekere zin een ontwerper noemen. Kinderen kunnen bijvoorbeeld verrassende en originele oplossingen bieden tijdens brainstormsessies.
Vroeger was niet iedereen een expert in internetgebruik, maar nu wel. Mensen zitten de hele dag online. Daarom is het belangrijk om transparant te zijn in ontwerpbeslissingen. Vroeger kon je nog wegkomen met bepaalde beslissingen zonder gedegen onderbouwing, maar dat is nu niet meer het geval. Het is een beetje alsof je iemand beduveld. Als je inderdaad de enige expert in de kamer bent, dan is het nogal makkelijk om te zeggen dat die knop rechtsonder moet. Terwijl dat helemaal niet de goede keuze is.
Ik herinner me mijn tijd bij Clockwork, een internetbureau, waar we voor grote klanten werkten, zoals een redesign voor Wehkamp. Toen was er weinig onderzoek vooraf en werd er vooral gefocust op het maken van iets moois. Dit proces omvatte geen datagebruik of onderzoek naar gebruikersbehoeften. Dan werd dat gebouwd en ging het online. Er werd alleen door Wehkamp zelf getest en gemonitord. Daar was ik niet zo bij betrokken.
De interactie tussen ontwerp en klant was heel anders dan nu. In 2008 was de catalogus nog een belangrijk onderdeel van ontwerp. De art director van print had toen nog veel invloed. Dit is een goed voorbeeld van hoe snel de industrie is veranderd. De focus lag toen vooral op beeldgebruik en reclamecampagnes. Nu is er natuurlijk veel meer concurrentie. Je moet je ergens op onderscheiden. Toen was dat een groot online warenhuis. En nu moet je je toch op een of andere manier onderscheiden. En daardoor is het juist om de klant of gebruiker erbij te betrekken. Op die manier kun je wat meer diepte aan het domein geven. Nou, die eerste stelling hebben we wel behandeld.
De tweede stelling: ‘Door design thinking te gebruiken weet je altijd precies wat een gebruiker nodig heeft’. Dit is een interessante stelling om te bespreken. Joël, wat vind je daarvan? Design thinking biedt zeker meer mogelijkheden om te ontdekken wat een gebruiker nodig heeft, en brengt deze behoeften naar voren.
In het verleden gingen ontwerpprocessen vaak uit van aannames over gebruikersbehoeften. Tegenwoordig wordt vaker gevraagd: "Waarom heb je een app nodig?" Dit is een essentiële vraag die niet altijd een uitgebreid onderzoek vereist, maar wel gesteld moet worden.
Zelfs als de klant al onderzoek heeft gedaan, is het belangrijk dit te verifiëren. Ons eerste onderzoek kan aantonen dat gebruikers misschien iets anders nodig hebben dan een app. Dit betekent niet dat de vraag fout is, maar mogelijk is het gekozen kanaal niet juist.
Bij Pixelpillow is design thinking een integraal onderdeel van onze werkwijze, gevolgd door een agile aanpak voor techniek. Hoewel je niet altijd precies weet wat een gebruiker nodig heeft, kom je door design thinking wel dichterbij.
Je hoeft niet te starten met een perfect product. Begin met een gevalideerde aanname en ontwikkel dit verder door feedback en finetuning. Het is een 'sanity check' om vroeg in het proces te bepalen of de inspanning de juiste richting op gaat.In gesprekken met potentiële klanten gebruik ik vaak de metafoor van 'schieten met hagel' versus 'schieten met scherp'. Het is belangrijk om gericht te werk te gaan, gebaseerd op onderzoek en gebruikersfeedback, in plaats van willekeurig verschillende opties te proberen.
Je snapt ik bedoel. Het is gewoon zonde om al die moeite te steken in iets waarvan je niet zeker weet of het gaat werken. Over de vraag of design thinking altijd precies onthult wat de gebruiker nodig heeft, is men niet zeker. Wel is duidelijk dat het een groot deel van de gebruikersbehoeften aan het licht brengt, wat zeker de moeite waard is.
Even kijken, we hebben nog een stelling: ‘Samen met de klant een team van specialisten vormen is beter dan een full service zijn’. En wat bedoel ik daarmee? Je kan beter een samengesteld team van specialisten een project, bijvoorbeeld een website, laten ontwikkelen, dan dat je dat bij een bureau neerlegt die alles gewoon doet. Dus de klant heeft een vraag, gaat naar een bureau en daar zeggen ze ‘kom maar hier, wij gaan alles fixen’.
Ik denk dat het lastig is om voor full service een opdracht te vinden waar dan weer precies alle disciplines in huis zijn die daarvoor nodig zijn. Elke opdracht heeft zijn eigen behoeftes en eigen type specialisten of vakmensen nodig. En dan moet je wel een hele grote club zijn, wil je dat allemaal in huis hebben. Dus ik neig er naar te zeggen dat een team van specialisten beter is, mits de specialisten goed samenwerken.
Het is heel waardevol, vooral bij complexe onderwerpen, om de kennis binnen de organisatie van de klant aanwezig is, te integreren. Het is namelijk uitdagend om jezelf op korte termijn volledig te verdiepen in de specifieke aspecten en nuances van een organisatie, de markt waarin deze opereert, en het assortiment van hun producten. Wanneer er binnen de organisatie iemand is die intern toegang heeft tot essentiële informatie, en weet hoe deze informatie effectief boven water te krijgen binnen het kader van design thinking, voegt dit aanzienlijk meer waarde toe. Deze personen kunnen snel de benodigde informatie uit de juiste hoeken van de organisatie halen. Dit heeft een aanzienlijk positieve invloed op de kwaliteit van het eindproduct.
Men kan proberen om kennis en specialisatie op te bouwen, maar vaak is deze expertise al aanwezig bij de klant. Hierdoor wordt het klantenteam een essentieel onderdeel van het specialistenteam. Dit geldt vooral voor bepaalde typen opdrachten. Persoonlijk ben ik van mening dat dit vooral van toepassing is op productontwikkeling en meer functionele, productgerichte projecten, in tegenstelling tot productwebsites.
Neem bijvoorbeeld onze ervaring met het NEN, het Nederlandse Normalisatieinstituut. Daar ben ik al ongeveer 3,5 tot 4 jaar werkzaam. Hoewel ik veel kennis heb opgedaan, durf ik niet te zeggen dat ik het product volledig begrijp, van binnen en van buiten. Vooral de domeinkennis, zoals de werking van normen, is complex. Sommige mensen daar werken al meer dan twintig jaar en hebben een diepere kennis die je als externe partij nooit volledig kunt evenaren.
Als het gaat om reclame of campagnes, neigen bedrijven eerder naar een full-service bureau dat een creatief team in een 'pressure cooker' zet voor fantastische resultaten. Maar voor duurzame ontwikkeling van een product, zoals NEN of NEN Connect, is dit niet de juiste aanpak. Bij dit soort projecten is veel meer specifieke kennis nodig dan wat een tijdelijk samengesteld team kan bieden. Voor campagnes is het vooral belangrijk om een goed gevoel voor de doelgroep te hebben, meer dan voor de klant zelf.
Bijvoorbeeld, Tele2 reclames zijn gericht op een zeer specifieke doelgroep. Dit vereist een team dat goed begrijpt wat deze doelgroep aanspreekt. Bij productontwikkeling is diepgaande kennis van de organisatie cruciaal, dus moet de organisatie nauw betrokken zijn bij het project.
De volgende stelling ligt wel heel erg tegen de vorige stelling aan. Op het moment dat jij je in kan leven in de gebruiker, is het heel belangrijk om .. Het gaat om een hele functionele vraag. Je hebt al heel snel dat je precies moet snappen wat de gebruiker voor problemen tegenkomt. En als dat meer een campagne- of marketinggeoriënteerde actie is, dan is dat toch al een heel ander verhaal. Dan moet je de doelgroep vreselijk goed kennen. Maar dat is inderdaad meer op een emotioneel level dan op een functioneel level.
Dan rijst de vraag: wat definieert een ontwerper? Een goede visueel ontwerper hoeft misschien niet exact de functionele wensen van een gebruiker in een applicatie te begrijpen, maar moet wel aanvoelen wat een persoon beweegt. In ontwerpopleidingen, die vaak vier jaar duren, bevindt men zich in een wereld waarin docenten en klasgenoten ook ontwerpers zijn. Het werk dat gepresenteerd wordt, is dus voor gelijkgestemden. Veel ontwerpers kiezen na hun opleiding voor een carrière in de culturele sector, wat aansluit bij hun interesses. Het ontwikkelen van empathie voor een andersoortige gebruiker kan tijd en interesse vergen, maar is essentieel voor succes als ontwerper. Zonder empathie kom je niet ver als ontwerper, als je je niet kunt verplaatsen in de ander.
Dit is een interessant punt om verder uit te diepen. Zoals ik al eerder aangaf, passen wij deze methoden toe in onze werkzaamheden. Wij gebruiken design thinking voor het ontwerpproces en hanteren een agile aanpak voor technische ontwikkeling, wat enigszins lijkt op scrum. Hierover hebben we al eerder gesproken en artikelen geschreven.
We werken in principe agile, met enkele elementen van scrum, maar niet volledig. De kernvraag is echter of deze combinatie ons bevalt. Is het een goede match?
Om de definitie van agile kort te noemen: het gaat om kortcyclisch werken om snel feedback te verwerken. Dit sluit nauw aan bij design thinking, waarbij het doel is om snel te itereren om te testen of iets voldoet aan de behoeften. Ik denk dat deze combinatie zeker een 'match made in heaven' is. De integratie van beide werkt erg goed samen en versterkt elkaar. Vaak bevindt design thinking zich wat later in het proces, vooral voor technische aspecten, maar het kan ook later in het proces weer van pas komen. Als je door de exploratieve fase heen bent, kunnen nieuwe inzichten eisen dat je bepaalde tools uit design thinking opnieuw toepast.
In de kern zijn beide methoden manieren van werken die zeggen: gebruik je gezond verstand en ga regelmatig terug naar de gebruiker voor wie je het doet. Beide benaderingen benadrukken het belang van cyclisch werken, wat ruimte biedt voor voortschrijdend inzicht en verfijning.
Hoe sluiten deze methoden op elkaar aan? Vroeger hadden we ontwerp en watervalmethodiek, waarbij eerst het ene werd afgerond voordat met het andere werd begonnen. In de context van agile en scrum hoor je vaak de term 'sprint nul', wat impliceert dat je eerst een ontwerp maakt dat daarna technisch wordt gerealiseerd. Is dit veranderd met de adoptie van agile?
Ik denk dat agile op een hoger niveau staat dan design thinking. Agile gaat puur over iteratief werken, terwijl design thinking dit ook deels uitvoert. Agile kan worden gezien als een overkoepelende term, en design thinking als een manier om bepaalde problemen op te lossen met specifieke tools. Dus in die hiërarchie staat agile conceptueel gezien iets hoger. We zijn in essentie agile en gebruiken design thinking als een reeks tools om op een agile manier gebruikersbehoeften en problemen te identificeren. Dat lijkt me de beste manier om het te verwoorden. Of denk jij er anders over?
Nou, ik zit te denken dat, kijk, je hebt altijd een bepaalde basis nodig voordat je überhaupt bij gebruikers dingen uit kunt gaan vragen. Bijvoorbeeld een ontwerp moet er zijn en ook al wel vrij veel voordat je het echt goed kunt uitvragen. Dus je hebt toch altijd, heb ik het gevoel, een vrij groot deel van het werk doe je vooraf en kun je ook niet allemaal iteratief doen, want het zou te complex worden.
Maar volgens mij leent dit agile deel zich heel goed voor als je ook gaat doorontwikkelen. Dus als de basis eenmaal staat en dan blijf je gewoon je product ontwikkelen en elk stukje wat je verder ontwikkelt kun je heel goed iteratief doen en dan kun je ook de gebruiker volgens mij heel goed bij betrekken. En dan heb je dat design thinking telkens toegepast. Ik heb het gevoel dat daar heel veel winst valt te behalen, want je kunt dan ook gaan meten wat de gebruiker doet. Je kunt interviews houden en je kunt vervolgens ook kleine verbeteringen doorvoeren zonder dat je telkens op meerdere vlakken tegelijk aan het schakelen bent, omdat je op dat moment een aantal keuzes gewoon al gemaakt hebt. Hoe het eruit ziet ligt dan misschien al wel redelijk vast en je kunt je dan juist, heb ik het gevoel, veel meer focussen op die gebruiker en itereren en telkens een beetje beter maken.
We hebben nog één stelling en dat is 'design sprints zijn niet geschikt voor websites’. En dan misschien nog beter gezegd het ontwerpen van websites. Misschien even toelichten wat design sprints zijn. Design sprints zijn eigenlijk een bepaald format waarin je design thinking kan toepassen, groot gemaakt door Google met Jake Glep. Een ex-medewerker van Google, of tijdens een periode bij Google heeft hij dat volgens mij gedaan. En volgens mij kan dat inmiddels in anderhalf uur, een design sprint. Hij begon met vijf dagen en er zijn nu al drie dagen. Volgens mij is twee of drie dagen nu al bijna de standaard. Maar in ieder geval laten we nog even van die vijf dagen uitgaan. Het idee is dat je dan die fases die in design thinking zitten.
Dus je gaat eerst een idee, of eigenlijk het probleem formuleren, design challenge. Ideeën genereren, vervolgens die bij de gebruiker valideren. En dat in vijf dagen. De vraag is nu hoe design sprints vaak worden gebruikt, vooral voor het valideren van ideeën in start-ups, en in de lean startup methodologie. Echter, er rijst twijfel over de geschiktheid van deze methode voor het ontwerpen van websites.
Daarbij is er ook de vraag of het überhaupt mogelijk is, of dat wij het gewoon niet kunnen. Ik denk dat design sprints niet zo geschikt zijn voor websites, omdat het doel meestal is om één enkel idee of concept te valideren, vaak iets functioneels zoals een tool. Websites hebben vaak veel meer aspecten die getoetst moeten worden.
Het lijkt erop dat design sprints mogelijk beter geschikt zijn voor latere fases van een project, waarbij specifieke functionaliteiten toegevoegd worden op basis van gebruikersbehoeften. Bijvoorbeeld, voor een autodealer kan een websitefunctie zoals een kentekenchecker voor onderhoudshistorie een onderdeel zijn dat goed in een design sprint past. Zo'n specifieke component kan waarschijnlijk in een kortere tijd gevalideerd en doorontwikkeld worden.
Design sprints worden ook vaak gebruikt in non-profit en goede doelen sectoren. Ze zijn bedoeld om een specifiek probleem op te lossen en vereisen een duidelijk geformuleerd probleem. Bijvoorbeeld, een garage die problemen heeft met late klanten kan een specifieke oplossing genereren in een design sprint.
Voor het compleet van de grond af aan ontwerpen en bouwen van een nieuwe website is één week in een design sprint vaak niet voldoende. Een website lost doorgaans veel problemen op, wat niet binnen één design sprint kan. Bij projecten zoals voor Engie, waarbij het ontwerpen en valideren van concepten al drie weken duurde, blijkt dat design sprints niet altijd passend zijn voor complexe websiteprojecten. In grote organisaties is het ook niet altijd haalbaar om een heel team een week lang aan een sprint te wijden.
Nou jongens, we gaan afronden. Tot de volgende vlog. Doei.
