Het gevaar van priming
public tech software design algoritmeregister code for nl meetup
25 januari 2021
Zojuist een erg interessante sessie gehad over de mogelijkheid om een “algoritmeregister” te introduceren. Iedereen heeft daar wel iets van een beeld bij, maar bij nadere verkenning blijkt al snel: wat zit er nou eigenlijk in een “register”, en wat valt er eigenlijk allemaal onder de noemer “algoritmes”. Op die manier wordt het verzinnen van een oplossing een soort taalfilosofische exercitie.
Ook in andere projecten waar ik in meedraai komt dit vaak naar boven: een naam zoemt rond, of bepaalde woorden worden vaak gebruikt, en voordat je het weet loopt iedereen rond met het idee dat er al een oplossingsrichting is, terwijl eigenlijk niet eens duidelijk is wat het probleem is. Dit fenomeen staat ook wel bekend als priming.
Doorgaans is er al een besluit aan vooraf gegaan, namelijk dat (in dit geval) een “algoritmeregister” een goed idee is en dat daar dus een project van gemaakt mag worden. Het is niet altijd duidelijk of de opdrachtgever dan heel specifieke ideeën heeft bij wat dat dan inhoud, of meer ziet dat er ‘iets’ moet gebeuren op dat vlak. Dat leidt er toe dat in de uitvoer vaak veel te weinig ruimte wordt ervaren om die opdracht iets vrijer te interpreteren en “het probleem achter het probleem” uit te zoeken. Met als gevolg dat er iets ontstaat wat nooit is ontworpen, wat vanuit interpretaties van een woord en eigen ervaring van teamleden is ontstaan, waar eigenlijk niet duidelijk van is welk probleem het nou precies op welke manier oplost, en waar ook niemand op zit te wachten (inclusief de opdrachtgever).
Soms voelt het vervelend, maar volgens mij blijft het belangrijk om mensen daarop te wijzen. Er op te wijzen dat er daardoor een ontwerp emergeert uit een zak woorden. Waarbij het probleem is dat mensen zich daar allemaal een andere voorstelling bij maken. En dat het niet duidelijk is voor wie welk probleem precies wordt opgelost. Daarmee is het risico levensgroot dat een pad wordt ingeslagen van “tech push”: eerst maken, en daarna kijken hoe we het gaan inzetten.
Doordat dat woord er is, denken mensen dat ze weten waar het over gaat, en stappen ze dus over de stap heen van met elkaar definiëren waar het over gaat. Als ze dat wel zouden doen, dan zouden ze merken dat ze het eigenlijk niet weten. Dat ze er verschillende opvattingen over hebben. En dat ze dus een stap terug moeten: welk probleem is er, hoe zit dat precies, willen we dat oplossen, en zo ja, welke oplossingen zijn er dan mogelijk en welke daarvan willen we proberen? Om daarna pas over te gaan tot: hoe moet die oplossing er precies uit zien.
Design methodes bieden manieren om dit te voorkomen, maar in de praktijk is het dan vaak te laat. Een goede manier om daar dan alnog mee om te gaan is om onder het motto “alles is inspiratie” te zoeken naar doelgroepen met een gerelateerd probleem. Vervolgens kun je met het woord/concept in je achterhoofd oplossingen verzinnen, en daarbij proberen het concept zo ver mogelijk om te buigen richting een oplossing voor dat probleem. Als opdrachtgever is het goed om daar dan expliciet mandaat voor te geven.
Op die manier zorg je voor gebruikers om in co-creatie mee te ontwikkelen. Alle waarde zit ten slotte in het gebruik.
Andere aantekenignen
There be Easter Eggs
20 december 2021
Tijdens mijn studie informatica was ïk gefascineerd door natuurlijke algoritmes of natural computing. Voorbeelden daarvan zijn cellulaire automaten, neurale netwerken, evolutie en zwerm-intelligentie.
De vijf F-strategieën voor Digitale Autonomie
7 november 2024
Welke strategieën kan de overheid ontwikkelen om de (digitale) autonomie van zowel overheid als samenleving te waarborgen? In dit artikel een voorzet in de form van vijf F-woorden.
Designathon Feedback Overheid
10 november 2023
Donderdag 9 en vrijdag 10 november 2023 was er de Hackathon/Designathon "Feedback Overheid" bij Waag en Datalab Amsterdam. Ons team van 4 designers, "FB&4th" (Feedback and Forth), werkte aan het concept "De Feedbak".