Definitiefase van design thinking

Best practices voor de design thinking define fase

Leestijd: ongeveer 7 min

Design thinking wordt vaak gebruikt door UX- en UI-ontwerpers die proberen om een positieve customer experience te creëren. Design thinking is een creatief en iteratief proces dat draait om een grondig inzicht in het doelpubliek, de consument en de gebruikers voor wie het ontwerp bestemd is. 

Er zijn 5 fases in design thinking, maar elke fase bouwt verder op de voorgaande stap. Dat maakt de tweede fase 'definiëren' extra spannend, omdat die volgt op de eerste fase 'inleven', zodat je kunt beginnen voort te bouwen op je gegevens en zo de resultaten van je basiswerk kunt zien.

We laten je kennismaken met deze tweede stap, de define fase van design thinking, zodat je vol vertrouwen verder kunt gaan met design thinking.

Wat houdt de de design thinking define fase in?

Stel je voor dat je team samenkomt om het grootste marketingprobleem op te lossen. Iemand is echter vergeten te definiëren wat precies het grootste probleem is, waardoor je marketingteam aankomt met oplossingen voor e-mailmarketingprocessen, problemen met marketingconcepten voor sociale media, en manieren om de koffiepauze te verbeteren. 

De definitiefase van design thinking identificeert eerst het probleem dat ontwerpers proberen op te lossen. Zo blijft iedereen gefocust op dezelfde oplossing. Deze fase helpt ook om het probleem zo goed mogelijk te definiëren: het moet breed zijn maar niet te vaag, en klein maar toch ook niet te beperkend. Het is beter als je je probleem kunt samenvatten in één enkele stelling. 

4 fundamentele vragen voor de define fase van design thinking 

Het probleem vanuit verschillende invalshoeken bekijken is de beste manier om het kernprobleem te achterhalen. Dat is echter ook een zware taak die soms te vaag aanvoelt om nuttig te zijn. Gelukkig zijn er richtlijnen om je op weg te helpen. Door een paar fundamentele vragen te beantwoorden, kun je je probleem beter definiëren.

  1. Wie ondervindt het probleem? Dit is je kerngebruiker. Definieer eerst je doelgebruikers, hun wensen en motivaties, en hoe ze omgaan met je product. Zonder te weten welke groep je probeert te helpen, zul je geen waarde kunnen toevoegen aan hun leven. 
  2. Welk probleem heeft je gebruiker eigenlijk? Als je een platform ontwerpt om auto's te kopen, denk je misschien dat het probleem dat je moet oplossen is: hoe kan ik een groter aanbod van koopopties voor auto's aanbieden? Maar misschien heeft je kerngebruiker niet zozeer last van een gebrek aan opties, en eerder van besluiteloosheid. Analyseer de pijnpunten die je tijdens de inlevingsfase hebt geïdentificeerd en bepaal wat de gebruiker echt nodig heeft. Dan kun je ook gaan brainstormen over verschillende manieren om dit probleem op te lossen. 
  3. Waar ligt het probleem? Dit is belangrijk voor UX-ontwerpers, omdat het probleem zich misschien maar bij één specifiek onderdeel voordoet (d.w.z. de mobiele app, de desktopversie of binnen een deel van het product). Dit is een belangrijke stap, omdat dit je toelaat je te concentreren op een bepaald punt. Of, als het probleem zich op meerdere plekken voordoet, begrijp je beter in welke contexten het opgelost moet worden. 
  4. Waarom? Deze vraag is misschien wel de moeilijkste van de vier fundamentele vragen. De vraag is wat het voor je gebruiker zou betekenen als het probleem zou zijn opgelost. Welk voordeel zou de gebruiker eruit kunnen halen? Als we het op grotere schaal bekijken, hoe zou de oplossing van het probleem van de gebruiker een impact hebben op het hele bedrijf? 

Best practices voor de definitiefase

Net zoals er vragen zijn om je te helpen de definitiefase te voltooien, zijn er ook verschillende best practices die je moet volgen als je aan deze stap van design thinking begint. 

Gebruik een standpuntverklaring (Point of View of POV)

Deze ene verklaring is de samenvatting van je werk. Het definieert wie je gebruikers zijn, wat hun behoeften zijn, en alle verrassende elementen of inzichten die je hebt verzameld uit je onderzoek. Dit standpunt kan een formule volgen: (gebruiker) moet (werkwoord) omdat (verrassend element of inzicht)

In bovenstaand voorbeeld over auto's kopen, zou de standpuntverklaring er als volgt kunnen uitzien: "Brian, de besluiteloze autokoper, wil de perfecte auto gepresenteerd krijgen, omdat hij het zelfvertrouwen mist om een grote aankoop te doen." Houd je standpuntverklaring gericht op de gebruiker. 

Vraag 'hoe kunnen we?'

Als je eenmaal je standpuntverklaring hebt, kun je mogelijkheden bedenken om het probleem van de gebruiker op te lossen binnen het ontwerp. Bestudeer je standpuntverklaring en brainstorm over onderwerpen die voortkomen uit het probleem. Maak vervolgens van die subonderwerpen en kwesties een vraag door er 'Hoe kunnen we...' aan toe te voegen. Als we bijvoorbeeld de bovenstaande standpuntverklaring gebruiken, zouden een paar 'Hoe kunnen we'-vragen er als volgt kunnen uitzien:

  • Hoe kunnen we bepalen welke auto Brian eigenlijk wil?
  • Hoe kunnen we het zelfvertrouwen van Brian opkrikken?
  • Hoe kunnen we de financieringsmogelijkheden het beste presenteren?

Met je 'Hoe kunnen we'-verklaringen moet je veel mogelijke oplossingen kunnen bedenken, ook oplossingen die vreemd of niet haalbaar lijken. Het gaat erom een reeks oplossingen te genereren, zodat je oplossingen kunt kiezen die heel waardevol lijken en er prioriteit aan kunt geven. 

afbeelding definitiefase

Gebruik de 5x waarom methode

 

De methode met 5 waaroms werd door Toyota ontwikkeld als onderdeel van hun training om tot de hoofdoorzaak van een probleem te komen. Het gaat erom een eerste vraag te stellen en vervolgens bij elk volgend antwoord te vragen 'waarom'. Bij ons voorbeeld van Brian, zou het er dus zo kunnen uitzien:

  1. Waarom heeft Brian geen zelfvertrouwen om een nieuwe auto te kopen? Omdat hij overweldigd is door de opties.
  2. Waarom zijn de opties zo overweldigend voor hem? Omdat hij denkt dat hij niet genoeg over auto's weet om een goede beslissing te nemen.
  3. Waarom denkt hij dat hij niet genoeg over auto's weet? Omdat hij niet weet welke vragen hij moet stellen als hij een auto gaat kopen. 
  4. Waarom weet hij niet welke vragen hij moet stellen? Omdat hij niet weet wat het belangrijkste voor hem is als het om een auto gaat.
  5. Waarom weet hij niet wat het belangrijkste voor hem is op het vlak van auto's? Omdat hij er nog nooit over heeft moeten nadenken.

Brians gebrek aan zelfvertrouwen zou dus kunnen komen omdat hij niet weet wat hij eigenlijk wil. Een oplossing zou een quiz kunnen zijn die Brian helpt zijn topprioriteiten voor een auto te bepalen.

Stapel waarom en hoe

Deze methode wordt gebruikt om allerlei gebruikersbehoeften in kaart te brengen, en wat er kan worden ondernomen om aan die behoeften te voldoen. Om te beginnen stel je een fundamentele vraag en vervolgens vraag je een paar keer waarom, totdat er een abstractere verklaring naar voren komt, met de kern van wat de gebruiker denkt en voelt. Vervolgens werk je terug vanaf die abstracte verklaring door bij elke verklaring te vragen 'hoe'. Het is de bedoeling dat je uiteindelijk een hiërarchie van de behoeften van je gebruiker hebt, die je kan helpen bij het formuleren van verschillende oplossingen.

Verzamel en ontleed user stories

Door user stories te ontleden in een user story map, kun je beter bepalen welke taken en activiteiten het meeste ongemak opleveren voor je gebruiker, en vervolgens oplossingen bedenken voor dat ongemak. 

Als je bijvoorbeeld weet dat Brian een hekel heeft aan inloggen op websites, kun je alternatieve oplossingen overwegen voor het traditionele wachtwoord. Het visualiseren van een user story map zal je helpen ontdekken waar er kansen liggen.

stappenplan voor project
Voorbeeld userstorymap (klik op de afbeelding om online aan te passen)

Analyse en synthese

Zodra je je probleemstelling hebt, kun je die in stukken opsplitsen. Kijk dan naar elk stukje en bedenk er oplossingen voor. 

Dat zijn alle tools en best practices waarmee je kunt bepalen welk probleem je oplost en waarom dat waardevol is voor de klant.

Bevorder design thinking met je eigen team vandaag nog in Lucidspark.

Probeer het nu

Probeer design thinking vandaag nog uit met Lucidchart.

Aan de slag

Nu populair

Zoom’s Lucidspark Zoom App integration

Verbeterde samenwerking met Lucidspark en Zoom

Over Lucidspark

Lucidspark is een virtueel whiteboard waarmee u en uw team kunnen samenwerken rond de beste ideeën. Het bevat memobriefjes, tools voor vrijestijltekenen en een oneindig groot tekenvel om dat volgende grote idee vast te leggen. En het is gemaakt voor teamwerk. Het is een soort zandbak waarin uw team ideeën kan uitwisselen en samen in realtime kan innoveren.

Mogelijk gemaakt door de makers van Lucidchart, vertrouwd door miljoenen gebruikers over de hele wereld, waaronder 99% van de Fortune 500-bedrijven.

Aan de slag

  • Prijzen
  • Individueel
  • Team
  • Bedrijf
  • Contact met sales
PrivacyJuridischCookies

© 2022 Lucid Software Inc.