Hoe ontwerp je een app die door 17 miljoen Nederlanders wordt vertrouwd?

Ten eerste: werkt Bluetooth wel?

Als zelfs Google en Apple de handen ineen hebben geslagen om het makkelijker te maken om Bluetooth in te zetten voor ‘contact tracing’, dan zal die techniek wel geschikt zijn, zou je denken. Maar wij zijn er erg sceptisch over. Zelfs de (Nederlandse) uitvinder riep dat de techniek er totaal niet voor geschikt is. Vanuit onze ervaringen met Bluetooth-beacons voor onder andere het Rijksmuseum kunnen we dat beamen. Met Bluetooth kunnen we ongeveer meten hoe dicht je bij een zender staat, maar niet zo goed dat we weten of je bij de Nachtwacht staat of het schilderij ernaast. Of Bluetooth in de echte wereld gaat werken zal dus goed onderzocht moeten worden.

Geen technisch probleem, maar een gebruiksprobleem

Maar laten we stellen dat Bluetooth-tracing wel goed genoeg gaat werken. Dan komt het echte probleem: gaat iedereen de app (1) downloaden, (2) actief gebruiken en (3) op hun telefoon houden? Want een ‘contact tracing app’ heeft alleen zin als het door de overgrote meerderheid wordt gebruikt (zestig procent wordt het meest genoemd).

Dat is dus geen technisch probleem, maar een gebruiksprobleem. Ook als de techniek niet perfect is, zal het ontwerp dat nagenoeg wel moeten zijn, ander zal de app alsnog falen. Want slecht ontworpen apps worden weer verwijderd, of überhaupt nooit gedownload. In Singapore en Australië zijn dergelijke apps al uitgebracht, en daar komen ze niet verder dan 20%.

De grootste uitdaging is dan ook om een app te ontwikkelen die door iedereen in Nederland kan en zal gebruikt worden, zo lang als nodig. Dat is een ontwerpuitdaging van de buitencategorie! Hoe ziet zo’n app eruit? Waar moet het aan voldoen, zodat het voor iedereen bruikbaar is? Maar ook: hoe pak je het ontwerp aan? Met welk proces waarborg je kwaliteit, zonder tijd te verliezen?

Vijf uitgangspunten voor een app die iedereen kan vertrouwen

In dit artikel bied ik vijf concrete adviezen die bijdragen aan een app die iedereen kan vertrouwen. Ik hoop dan ook dat de overheid meeleest. En de corona-app zal niet het laatste initiatief zijn om apps in te zetten voor de gezondheid van de bevolking. Mijn adviezen zijn dan ook waardevol voor alle opdrachtgevers die nadenken over het toepassen van digitale middelen, als mogelijke oplossing voor een probleem dat een grote groep mensen betreft. Hier komen ze.

1 - Vind het juiste frame

‘Als je haast hebt, moet je even gaan zitten’. Die uitspraak is ook hier van toepassing. We hebben liever vandaag dan morgen een oplossing, maar als je bedenkt dat we misschien nog wel jaren te maken hebben met Covid-19, dan is haast een relatief begrip. Er kan juist tijd gewonnen worden door stil te staan bij wat nou eigenlijk de opdracht is. Dat klinkt nogal voor de hand, maar zelfs de Autoriteit Persoonsgegevens concludeerde dat de overheid geen duidelijke kaders had bepaald.

Als opdrachtgever moet je beseffen dat vaak de meest bepalende stap in een ontwerpproces niet het ontwerpen van de oplossing zelf is, maar het juist framen van de opdracht. Toen de overheid aankondigde dat ze nadachten over een ‘Bluetooth-app’, lag de focus meteen op de techniek (Bluetooth) en de oplossing (een app). Dat maak ik zelf ook vaak mee, bij opdrachten voor apps of websites. Maar techniek is slechts een middel. Waar het echt om draait, is welk doel die techniek dient, en binnen welke voorwaarden er gewerkt moet worden.

Reframe de opdracht
De eerste stap moet dan ook zijn om de brede vraag ‘hoe kan een Bluetooth-app ons uit de crisis helpen?’ te reframen: op zoek gaan naar de ‘vraag achter de vraag’ en vervolgens een specifiekere invalshoek kiezen. In dit geval zou ik de opdracht zo reframen:

• van: ‘ontwikkel een tracing-app die werkt met Bluetooth’
• naar: ‘ontwikkel een automatisch dagboek waarmee mensen de GGD kunnen ondersteunen als ze besmet zijn’

Deze reframing verlegt de aandacht van oplossing (een app) naar doel (ondersteuning van de GGD) en van iets technisch (Bluetooth tracing) naar iets dat veel mensen kunnen snappen (een automatisch dagboek).

Een concept dat iedereen kan uitleggen
Wat je niet begrijpt, kun je ook niet echt vertrouwen. Terwijl het eigenlijk heel simpel is: die app is dus een dagboek. Waarin wordt bijgehouden bij wie je allemaal in de buurt bent geweest (wat niet per se letterlijk ‘contact’ was). Maar in plaats van dat je dat zelf handmatig moet doen, doet de app dat voor je, geheel automatisch. Je vergeet niemand, en je hoeft anderen niet te kennen want het is volledig anoniem. Oude pagina’s worden vanzelf verwijderd. En net als een fysiek dagboek, is het jouw dagboek, waarvan je de inhoud pas overhandigt als het nodig is (wat hopelijk nooit is) en nooit zonder jouw toestemming. Een slim dagboekje met superkrachten dus, waarover jij altijd de baas blijft. Dat is niet alleen een duidelijker maar ook een positiever frame. De overheid zou dat in de communicatie en uitleg over de app steeds moeten benadrukken. Vanuit dit dagboek-frame is het veel makkelijker om een begrijpbare app te ontwikkelen, van de user interface tot de campagne, en van de teksten tot de naam van de app. Want bij een eenvoudig concept hoort ook een sterke naam.

Een goede naam geeft betere verwachtingen
De meeste voorstellen en bestaande apps hebben namen die niet per se de juiste associaties, en bovendien de verkeerde verwachtingen kunnen opwekken. Namen als Covid-19 Alert (een van de appathon-voorstellen) en COVIDSafe (Australie) leggen de nadruk op de ziekte (niet leuk) en creëren met ‘safe’ en ‘alert’ schijnveiligheid (een alert is geen garantie voor besmetting, en géén alert is geen garantie voor geen besmetting). Namen bedenken is een vak apart, dus de overheid doet er slim aan om naamspecialisten aan te haken. De beste naam heb ik nu niet, maar wat ik wel weet, is dat ‘GGD-Support’ of ‘Afstand-Dagboek’ een heel ander gevoel oproept dan ‘Covid-19 Alert’.

2 - Privacy by design

Dat veiligheid en privacy tegenstellingen zijn is een misvatting. Privacy is tenslotte ook een vorm van veiligheid. Maar hoe ontwerp je een app die persoonlijke gegevens verwerkt en tegelijk absoluut je privacy waarborgt? Dat is niet zo makkelijk, maar wel degelijk mogelijk, als je verder kijkt dan alleen het functionele.

Principes heb je om moeilijke keuzes te maken
Wel of niet een extra bevestiging vragen aan de gebruiker? Wel of niet het tijdstip van een contactmoment tonen? Als je twijfelt tussen twee ontwerpvarianten, wil je principes hebben om op terug te kunnen vallen. Daarom ben ik, als ontwerper én als burger, groot voorstander van het toepassen van ‘privacyprincipes’, zoals de uitgangspunten van Veilig Tegen Corona. Deze kunnen zelfs rechtstreeks toegepast worden in het ontwerp.

Principes zijn alleen principes als ze heilig zijn, en gebruik je dus vooral om moeilijke keuzes te maken. Ook als ze je (ogenschijnlijk) niet goed uit komen. Neem gebruiksgemak. Uiteraard moet de app daarin uitblinken. Maar tegelijk is gemak niet alles. Waarom is Zoom zo’n privacy-shitshow? Omdat bij de ontwikkeling ervan te veel focus is gelegd op gemak, zonder verder te kijken naar mogelijke nadelige gevolgen. Een password op een videocall instellen is misschien een vervelend stapje, maar blijkt wel degelijk belangrijk, nu vele online meetings worden gezoombombd.

Geen black box, maar transparantie en controle
Veel digitale technologie tegenwoordig is een ‘black box’. Het doet handige dingen voor je, maar je hebt geen idee wat er binnenin de software gebeurt. Dat is niet gunstig voor ons vertrouwen in techniek. Veel beter is het als je als gebruiker letterlijk kunt zien wat een app doet. Als bedrijf is Uber bepaald niet het toonbeeld van vertrouwen. Toch kunnen we wel wat leren van de interface van de app. Want waarom geeft die plattegrond me meer vertrouwen dan de taxicentrale die ik vroeger belde? Omdat ik precies kan zien waar mijn taxi is en welke rating de chauffeur van anderen kreeg. Misschien zal niet iedereen het willen inzien, maar ik wil in de app kunnen zien welke data er wordt opgeslagen, ook al zeggen de anonieme codes me niets. Als ik geen tijdstippen zie, weet ik ook dat het tijdstip van een contactmoment niet wordt bijgehouden, maar alleen de datum. En als ik gegevens die ik eerder wel zag, juist niet meer zie, weet ik dat ze verwijderd zijn. Ik vertrouw immers ook pas dat die gênante foto niet meer op mijn telefoon staat, als ‘ie weg is uit de camera roll (en uit ‘recently deleted’).

De app moet niet alleen openheid geven, maar ook controle. Komt mijn Uber niet opdagen? Dan cancel ik ‘m lekker, en zoek ik een nieuwe. Deze controle verwacht ik ook bij de corona-app. Misschien ben ik thuis wel bang dat mijn telefoon het signaal van de buurman oppikt, waardoor er 'valse contactmomenten' worden geregistreerd. Dan wil ik het automatisch loggen van nabije telefoons tijdelijk kunnen uitzetten, tot ik weer naar buiten ga. Door bewust ‘data design patterns’ toe te passen, zoals die uit de uitstekende Data Patterns Catalogue, is het heel goed mogelijk om de gebruiker daadwerkelijk controle en data-transparantie te geven.

Tijdelijkheid kun je inbouwen
Een contract voor onbepaalde tijd is alleen fijn als het je baan of je partner betreft, voor de rest willen we nergens aan vastzitten in het leven. Kunnen we erop vertrouwen dat de overheid de app wel weer stopzet na een tijdje? Dat hoeft niet, want tijdelijkheid kun je inbouwen. Bijvoorbeeld door de app automatisch te laten uitschakelen na elke twee maanden, tenzij de gebruiker de app opnieuw activeert. Zie het als een proefabonnement op een krant, dat automatisch wordt stopgezet in plaats van stilzwijgend verlengd wordt. Als de app vraagt om vertrouwen, moet de app ook vertrouwen geven.

3 - Inclusief ontwerp is meer dan criteria afvinken

Vertrouwen begint met respect voor elke gebruiker. Toegankelijkheid en de nieuwere, bredere term ‘Inclusive Design’ worden vaak nog gezien als het afvinken van een lijstje criteria, zoals standaarden voor leesbaarheid en contrast. Die zijn absoluut belangrijk, maar waar inclusiviteit in de kern om draait is dat je niemand wilt uitsluiten. De app is niet alleen een manier om iets tegen de crisis te doen, maar ook een kans voor de overheid om te laten zien dat ze er écht voor iedereen zijn, jong en oud, arm en rijk, blank en zwart. Zodat de app niet nog een manier wordt waarop minderheden harder worden getroffen door de pandemie.

Iedereen heeft een ‘beperking’
Ontwerpen voor diverse gebruikers begint met een divers team. Hoe diverser het team van ontwerpers en ontwikkelaars, hoe groter de kans dat verschillende perspectieven en achtergronden meegenomen worden. Het laatste dat we willen is een (onbedoeld) racistische zeep-dispenser. Het feit dat het expert-team dat de overheid gekozen heeft uit acht blanke mannen bestaat, is niet hoopgevend. Inclusive Design begint namelijk met het besef dat degenen die de app ontwikkelen zelf niet de gemiddelde gebruiker zijn. Die gemiddelde gebruiker bestaat niet eens. Ook al is Nederland een van de meest digitale landen ter wereld, toch is er een grote groep die moeite heeft met digitale middelen. Of een fysieke beperking heeft. Of laaggeletterd is. Of een oudere telefoon heeft met een klein scherm. Of geen Nederlands begrijpt. Of simpelweg gestresst is door het lange thuiszitten, waardoor je aandacht er niet helemaal bij is als je de app voor het eerst opstart. Als we al deze groepen bij elkaar optellen, blijkt dat bijna iedereen wel een of andere ‘beperking’ heeft waar het ontwerp rekening mee moet houden.

Voortdurend gebruiksonderzoek
De enige manier om zeker te weten dat de app ook werkt voor mensen die er niet de hele dag aan ontwikkeld hebben is om hem te testen met representatieve gebruikers. Er zal dus veel en vaak getest moeten worden, met diverse respondenten. Met één usabilitytest ga je dat niet redden. (Sowieso is het een misvatting dat je met één gebruikstest met 5 tot 8 gebruikers voldoende getest hebt). Testen is iets dat je voortdurend moet doen, vanaf dag één, en daar nooit meer mee stopt, ook niet na de lancering. Bovendien wil je niet alleen het ontwerp en de techniek testen, ook de communicatie. Beginnen met het schrijven van de Veelgestelde Vragen is bijvoorbeeld een goed idee, in plaats van dat je die vlak voor lancering gaat opstellen. Met gebruiksonderzoek wil je vroeg fouten kunnen ondervangen die je niet kon voorzien. Gelukkig kun je veel fouten voorkomen, door het ontwerp écht eenvoudig te maken (maar da’s nog niet zo makkelijk).

Eenvoudige taal, in meerdere talen
Als je dit leest heb je waarschijnlijk een goed begrip van de Nederlandse taal. Maar wist je dat het woord ‘besmetting’ voor een groot deel van de bevolking al een moeilijk woord is? En ‘traceren’ is al helemaal geen normaal woord. Om begrijpelijke taal te schrijven voor een zo groot mogelijk deel van de Nederlandse bevolking moeten teksten geschreven worden op B1, of zelfs A2-niveau (B1 wordt begrepen door 80% van de bevolking, met A2 heb je 95%). Heel veel woorden vallen dan af, zoals je op deze site kunt checken. Toegankelijk schrijven is echt een vak apart, dus hopelijk zitten er goede copywriters in het team van de overheid. Maar óók vertalers. Want niet iedereen in Nederland spreekt Nederlands. Naast Nederlands en Engels, zou de app echt méér talen moeten ondersteunen, zoals Duits, Pools, Turks en Arabisch. Dat moet goed haalbaar zijn als de app weinig tekst bevat. Maar met alleen teksten die iedereen begrijpt kom je er niet, want tekst is niet de belangrijkste informatiedrager.

Visueel, in een betrouwbare stijl
Visuele prikkels komen het snelst binnen in ons brein. Voordat we één letter gelezen hebben, heeft ons brein al een oordeel geveld: is de app betrouwbaar? Wat gebeurt er op dit scherm? Wat wordt van mij verwacht?

Daarom een ontzettend voor de hand liggend advies, dat toch heel moeilijk blijkt te zijn om toe te passen, als we naar bestaande apps en voorstellen kijken: maak de app zo visueel mogelijk. In de appathon zag ik veel schermen voorbij komen met veel tekst. En ontwerpen die er wel verzorgd uitzagen, maar in een onbekende stijl. De app zou korte teksten moeten combineren met bijvoorbeeld illustraties en een bekende en daardoor vertrouwde stijl moeten hebben. Die van de Rijksoverheid ligt het meest voor de hand, met een look & feel die past in het rijtje overheid.nl en de Berichtenbox-app.

De uitspraak ‘de gebruiker heeft geleerd om je website te gebruiken op andere websites’ geldt ook voor apps. Dit is dan ook niet de app om nieuwe mobiele patterns in uit te proberen. De native controls (knoppen, navigatie-elementen, etc) van Android en iOS moeten zoveel mogelijk worden toegepast, wat ook nog eens beter is voor de accessibility.

4 - Ontwerp vooral ook de negatieve scenario’s

De belangrijkste test voor een auto is hoe die crasht, niet hoe je instapt en ermee wegrijdt. Natuurlijk moet de ‘onboarding’ heel goed ontworpen zijn, anders zullen gebruikers al afhaken voordat de app zijn werk kan doen. Maar dat is randvoorwaardelijk. De écht interessante use cases zijn hopelijk zeldzame, maar tegelijk cruciale gevallen om voor te ontwerpen.

Hoe je een melding krijgt maakt alles uit
Niet alleen moet iedereen de app installeren, iedereen moet ook de acties opvolgen die geadviseerd worden. We hebben gezien met de anderhalvemeterregel dat advies opvolgen nog niet zo makkelijk is. Daarom is het cruciaal dat de melding die je krijgt, als je in de buurt was van iemand bij wie besmetting is vastgesteld, en de stappen erna, goed ontworpen worden. Ga maar na:

• De melding moet opvallen tussen de vele notificaties die je op een dag krijgt
• De melding moet niet verkeerd begrepen worden
• De gebruiker moet niet onnodig ongerust worden of in paniek raken
• De gebruiker moet de geadviseerde handelingen begrijpen, kunnen overzien en niet uitstellen
• De gebruiker moet gemotiveerd zijn om de handelingen uit te voeren, waaronder het delen van gegevens
• De gebruiker moet de handelingen correct en succesvol uitvoeren

Er zijn dus meerdere punten waarop dit mis kan gaan, met als gevolg dat anderen niet op de hoogte worden gebracht. Zie het maar als een checkoutfunnel van een webshop waarbij de conversie 100% moet zijn. Goede teksten zijn dan essentieel. Er is nogal een verschil tussen

"Let op! U bent mogelijk besmet met Corona!"

en

"U bent eergisteren gedurende 20 minuten in de buurt geweest van iemand bij wie de GGD zojuist besmetting met het coronavirus heeft vastgesteld. Kijk wat u kunt doen."

Toegegeven, de tweede zin is wat lang voor een eerste melding, maar het is wel feitelijk wat er aan de hand is. Niet mooier dan het is, maar ook geen onnodige onrust. De truc is om precies die woorden te kiezen die iedereen begrijpt en aanzetten tot actie.

Hoe zullen mensen de app verkeerd begrijpen?
Kun je je nog herinneren dat Wim Kok een muis vasthield als een afstandsbediening? Als een product door heel veel mensen gebruikt wordt, zullen er altijd mensen zijn die het ‘verkeerd’ gebruiken. Als het bij mondkapjes kan gebeuren, zal het ook bij de app gebeuren. Een goede oefening is om te bedenken wat verkeerde interpretaties zouden kunnen zijn. Een app die iets doet met meldingen en draadloze signalen, kan misschien wel de indruk wekken dat je direct een waarschuwing krijgt als je langs iemand loopt met corona. Alsof de smartphone lichamen ‘scant’ op de ziekte en er een alarm afgaat als iemand besmet is. Of dat je de telefoon over je eigen lichaam beweegt om te kijken of je het zelf hebt. Dat klinkt misschien raar, maar er zijn ook mensen die denken dat 5G corona veroorzaakt. Er zijn geen ‘domme’ gebruikers, alleen ontwerpen die niet goed genoeg zijn doordacht. De toolkit ‘Ethics for Designers’ biedt goede oefeningen om hierover na te denken.

Maak misbruik heel moeilijk
Naast onopzettelijk verkeerd gebruik kunnen er ook kwaadwillenden zijn die de app willen misbruiken. Voor de lol, uit verveling, of echt uit terrorisme. Met Zoom hebben we kunnen zien wat er gebeurt als er niet wordt geanticipeerd op misbruik van software. Ook daar moet rekening mee worden gehouden, met zo’n grote gebruikersgroep. Zo is het essentieel dat je als gebruiker niet zelfstandig in de app kunt aangeven dat je corona hebt. Anders zou er na ‘Zoom-bombing’ zomaar ook ‘Corona-bombing’ kunnen ontstaan: mensen die opzettelijk zoveel mogelijk andere telefoons gaan ‘besmetten’. Misbruik kan nooit helemaal voorkomen worden, maar we kunnen het kwaadwillenden wel heel moeilijk maken, door op ze te anticiperen. Als je naar buiten gaat, laat je ook niet de sleutel in de deur zitten, toch?

5 - Open iteratie en validatie

Een goed ontwerp is niet alleen een kwestie van wat je ontwerpt, maar ook van hoe je dat aanpakt. Met zo’n groot en impactvol project is een goed proces belangrijker dan ooit. De appathon leek een valse start, maar de vele kritiek geeft ook aan wat er wél goed aan was: het stelde de overheid in staat om snel te leren en liet de bevolking meekijken. Dat moet vastgehouden worden en hopelijk wordt het zelfs de nieuwe standaard voor overheidsaanbestedingen. De overheid heeft geen geweldige track record, als het gaat om grote ict-projecten. Ik hoop dat dit project een keerpunt is en dat er meer kennis bij de overheid terecht komt, met name over hoe je digitale projecten aanpakt. Twee punten zijn hierbij met name van belang, als de overheid toonaangevend wil zijn.

Validated Learning om met onzekerheid om te gaan
Er zijn ontzettend veel onzekerheden in zo’n app-project, maar hoe ga je daarmee om? Wat is het beste ontwerp? Wat gaat werken? De ‘lean’ manier is om Validated Learning toe te passen. Je prioriteert je werkzaamheden niet op wat je denkt dat het meest waardevol is of het meeste werk, maar op wat de grootste onzekerheden zijn. Het testen van prototypes en proof-of-concepts zijn slechts enkele middelen om onderzoek te doen. Dit kan ook laagdrempeliger. Denk aan interviews, street-scans of het bespreken van schetsen met gebruikers. Zolang het maar veel, vaak en breed toegepast wordt. Door onderzoek enerzijds en ontwerp en ontwikkeling anderzijds voortdurend met elkaar af te wisselen, tackle je heel gericht steeds kleinere onzekerheden, totdat er zo weinig onzekerheden overblijven dat de app gelanceerd kan worden. Dat vergt dus niet alleen technische en ontwerpspecialisten, maar ook regisseurs van het proces.

Open source ontwerp en peer reviews
Je kunt het publiek laten stemmen op de beste en mooiste app, maar het gaat hier niet om de finale van The Voice. Ontwerpen is geen democratisch proces. ‘Design by committee’ is dan ook een garantie voor falen. Toch denk ik dat de ontwerp-gemeenschap in Nederland wel kan bijdragen aan een beter ontwerp. Onder developers is het gebruikelijk dat code ‘open source’ is. Zodat iedereen er van kan profiteren, maar vooral ook zodat andere developers feedback op de code kunnen geven en mogelijke fouten kunnen detecteren. Dat principe kun je ook toepassen op het ontwerp van de user interface. Enkele Nederlandse ontwerpers hebben op eigen initiatief al zo’n 'open user interface’ gepubliceerd. Het feit dat een aantal van hen is uitgenodigd om in het expert-team van de overheid te zitten, is dan ook bemoedigend.

En het ziet ernaar uit dat ze dit ‘open source ontwerp’ willen doorzetten. Maar hoe onderscheid je de echt waardevolle bijdragen van alle ruis? Ik zou het zien als goed georganiseerde ‘peer reviews’. Onder wetenschappers is het heel normaal om je werk te laten beoordelen door de wetenschappelijke gemeenschap. Het is zelfs dé manier om tot robuuste kennis te komen. Je wilt dus niet feedback van het hele internet, maar alleen van (geselecteerde) andere ontwerpers, die weten waar ze het over hebben. Die geen open commentaar geven, maar op gerichte vragen feedback geven. Dus niet: ‘Wat vinden jullie van dit home-scherm?’, maar: ‘Dit is de flow waarin de gebruiker wordt gevraagd om Bluetooth te activeren: waar(door) zouden gebruikers kunnen afhaken?’ Nederland heeft een ontzettend sterke design-gemeenschap. Als dit proces goed georganiseerd wordt, ben ik ervan overtuigd dat onze gezamenlijke brainpower kan bijdragen aan misschien wel de beste corona-app van de wereld.

Komt de app er?

Het aandragen van adviezen vanaf de zijlijn is makkelijk, dat moet ik toegeven. Toch hoop ik dat de genoemde uitgangspunten toegepast worden. Hoe dan ook zal ik het app-proces op de voet blijven volgen, al was het maar omdat ik een geïnteresseerde, kritische burger ben. Of de app er echt komt durf ik nog niet te zeggen. En als ‘ie er al komt, is het maar de vraag of het helpt. In IJsland, waar bijna 40% de lokale corona-app heeft geïnstalleerd, lijkt het niet veel bij te dragen en ook wetenschappers van de Universiteit Utrecht zijn niet overtuigd dat het effectiever is dan andere, minder ingrijpende maatregelen.

Misschien is het zelfs wel beter als die app er niet komt. Dat we geen technologie nodig hebben om een crisis aan te pakken. Zou dat niet mooi zijn? Dat we later kunnen zeggen: weet je nog, de coronacrisis in 2020? Aanvankelijk dachten we dat we een app nodig hadden om terug naar het normale leven te keren, maar uiteindelijk besloten we om duizenden mensen, die door de crisis hun baan waren verloren, aan te nemen bij de GGD. Het was zelfs het begin van een hele andere manier om naar ons zorgstelsel te kijken...

Mijn laatste advies aan de overheid is dan ook: val niet voor de 'sunk cost fallacy' en durf het hele project te stoppen als blijkt dat het niet gaat werken. Want de meest geavanceerde technologie, maar ook het beste ontwerp, kunnen nooit een crisis oplossen. Dat kunnen alleen mensen. Alleen samen.

Patrick Sanwikarja is User Experience Director bij Fabrique.