Rational design

Digitale producten worden vaak ontworpen als een interventie. Je wilt iets veranderen aan bepaald gedrag bij je doelgroep. Of je wilt je doelgroep helpen om bepaald gedrag vast te houden.

In deze serie posts beschrijf ik een proces om op rationele wijze tot een geschikte oplossing te komen. Ik gebruik hiervoor de nieuwe term “Rational design”. Ik gebruik een nieuwe term zodat ik een leeg canvas heb om mee te werken. Rational design is het iteratief vormgeven van een artefact dat een probleem oplost voor een bepaalde doelgroep, waarbij de verschillende ontwerp stappen in het proces worden gevalideerd en bijgesteld. Het bijstellen van de ontwerpen wordt gedaan om deze effectiever te maken in het oplossen van het probleem.

Centraal in de werkwijze is dat je je werk in een voortdurende feedback loop controleert. Elke keer als je een prototype maakt, heb je dat gemaakt met bepaalde verwachtingen; Je hebt bepaalde hypotheses. In een feedback loop ga je de belangrijkste hypotheses proberen te verifieren.

De werkwijze die ik voorstel heeft parallelen met hoe de methode “the lean startup” gebruikt maakt van hypotheses.

Bij de opzet van dit document ga ik uit van een fases. Deze fases ontleen ik aan het design research framework.

Design gap

Je ontwerpt een nieuw artefact omdat er op dit moment een “design gap” is: er is een probleem of een onvervulde behoefte in het probleemgebied waar je voor werkt: er is een spanningsveld tussen de huidige situatie en de gewenste situatie. Bij de start van een project is het van belang om te komen tot een eerste definitie van het design gap. In het begin zal het niet meevallen om dit te definieren. Zorg er in ieder geval dat de eindgebruiker centraal staat, en dat er een startpunt is. Je hebt nooit minder kennis over een project dan bij de start, zorg ervoor dat je jezelf de ruimte geeft het design gap te verfijnen. Meer over het definieren vind je hier.

Designers paradox

In complexere projecten is het design gap vaak niet helder. Het wordt voor jou als ontwerper dan erg lastig om te bedenken wat je moet onderzoeken, en ook om de richting van de oplossing te bedenken. Deze situatie wordt ook wel de designers paradox genoemd:

“We cannot think about solutions until we understand the problem

&

We cannot understand a problem until we think about solutions”

Een heel mooi voorbeeld van het gevoel van een designers paradox is te vinden in het volgende audiofragment. De auteur Jennifer Egan schreef het boek Manhattan beach. Dit boek speelt zich af begin jaren 40 in New York waarin de Mafia nog een belangrijke rol speelt. Door de oorlog krijgen vrouwen veel meer kansen om te werken. Zo ook de hoofdpersoon: ze gaat werken als marineduiker. Voor de schrijfster was het onderzoek dat ze verichtte voor het boek lastig: wat is nodig voor het verhaal, en wat voor verhaal is er eigenlijk te schrijven over deze situatie?

“I felt really paralysed for some time I really wanted to write about it But I didn’t know enough to write But I also didn’t know what I needed to know So it was a difficult stumbling start That I had to work through by going back and forth between research and writing”

New York Times podcast, 2017

Om uit een designers paradox te komen, zul net als Egan heel concreet moeten worden: je moet ideeen voldoende uit werken zodat ze getest kunnen worden. Door ze uit te werken wordt helderder welke aspecten van het probleem je moet begrijpen, en welke mogelijke oplossingen er zijn.

Prototypes

Om beter te begrijpen wat het probleem precies is, en wat de oplossingsmogelijkheden zijn helpt het om kleine prototypes te maken. Elk hoofdstuk dat Egan schreef zorgte er voor dat ze meer moest weten over de situatie die ze beschrijft, en tegelijkertijd weet ze ook beter wat ze moet weten voor dit specifieke verhaal.

Het prototype:

  • Moet snel te maken zijn
  • Is zodanig ontworpen dat het meer inzicht geeft in de vragen die spelen
  • Is flexibel
  • Goedkoop om te maken
  • Snel te maken
  • Het is geen voorloper van het eindproduct, niet qua concept. En ook niet qua technische basis.

Het prototype levert informatie op. Die informatie “informed” je design. Bij elk prototype heb je een onderzoeksvraag of eventueel hypotheses.

Hypotheses

De hypotheses kunnen verschillende achtergronden hebben.

  • Hypotheses gebaseerd op (wetenschappelijke) literatuur
  • Hypotheses gebaseerd op vorige testen
  • Hypotheses gebaseerd op onderzoek van het team
  • Hypotheses gebaseerd op een “hunch” van de designer

De hypotheses die je formuleert kunnen over verschillende onderwerpen in het proces gaan.

  1. Hypotheses die gaan over het probleemgebied
  2. Hypotheses die gaan over de gewenste situatie
  3. Hypotheses die gaan over het effect van een bepaald “ingredient” in de oplossing
  4. Hypotheses die gaan over een bepaald effect van een design keuze.

Gedurende het project veranderd de samenstelling van het gebied waarop je hypotheses zou moeten hebben. In de beginfase van een project zul je vooral de eerste twee type hypotheses hebben, in een later fase zal dat verschuiven naar de de twee laatste hypothese typen.

Iteraties

In itereaties test je of je prototype voldoet aan de belangrijkste hypotheses. Het zal je niet lukken om alle hypotheses te testen, hier heb je onvoldoende tijd voor en sommige hypotheses laten zich nog niet test. Kies voor de hypotheses die het meest onzeker en riskant zijn. De conclusies van de testen worden weer gebruikt als informatie voor een nieuwe ontwerp fase. Het kan ook de aanleiding zijn voor aanvullend onderzoek.