Trappen Naar Nergens

Ontwerpprincipes die Vitruvius 2000 jaar geleden definieerde, zijn nu je belangrijkste AI-tool

Door Scott Hines

Te veel software is tegenwoordig gebouwd zoals het Winchester Mystery House: kamers worden één voor één toegevoegd, trappen naar nergens. Het wordt een mysteriehuis genoemd. Het mysterie zit hem niet in de spoken, maar in de vraag waarom iemand het op deze manier zou bouwen.

Het huis was niet gebouwd om in te wonen. Het was gebouwd voor één persoon, en het werkte voor haar. Maar loop er nu doorheen en je voelt het verschil tussen een ruimte die ontworpen is voor de eigenaar en een ruimte die ontworpen is voor iemand anders.

Een van de trappen van het Winchester Mystery House – gebouwd zonder bouwtekening, nergens heen leidend. © Getty Images (515427836)

Het voelt als een kermisattractie. Het is eigenlijk een herenhuis in San Jose, in het hart van Silicon Valley. Het Winchester Mystery House werd gedurende achtendertig jaar onafgebroken gebouwd door de eigenaresse, Sarah Winchester, zonder masterplan. Kamer na kamer werd toegevoegd zonder dat iemand zich afvroeg hoe mensen zich erdoorheen zouden bewegen. Tegenwoordig is het een toeristische attractie. Mensen betalen om de desoriëntatie te ervaren.

Ze leerde zichzelf architectuur aan de hand van tijdschriften: een amateur met buitengewone middelen, aan niemand verantwoording verschuldigd behalve aan zichzelf. Als een gang verkeerd uitpakte, brak ze die af. Als ze een kamer wilde, voegde ze die toe, ongeacht of die ergens mee verbonden was. Trappen klimmen omhoog tot in het plafond. Deuren komen uit op muren. De disfunctie deed er niet toe, omdat zij de enige gebruiker was.

Softwareteams bouwen dagelijks huizen zoals deze.

Het gebeurt wanneer teams in silo's werken – elk geoptimaliseerd voor zijn eigen roadmap, zijn eigen definitie van 'klaar', zijn eigen lancering. Elke kamer werkt. De verbinding ertussen is verbroken.

Meer dan dertig jaar geleden benoemde Mitch Kapor dit probleem. Kapor had Lotus opgericht en Lotus 1-2-3 ontwikkeld, het spreadsheetprogramma dat de pc tot een zakelijke tool maakte. Hij was geen buitenstaander die de industrie bekritiseerde; hij was iemand die enorm succesvolle software had gebouwd en zei dat we het verkeerd aanpakten.

Zijn "Software Design Manifesto" betoogde dat software een rol nodig had zoals die van de architect, iemand die zich afvraagt hoe mensen zich door de software zullen bewegen voordat de bouw begint.

Ik ontdekte het manifest in Terry Winograds "Bringing Design to Software", een titel die het argument al duidelijk maakte voordat je het boek opensloeg. Het gaf stem aan een reis die ik al aan het maken was. Ik was opgeleid als architect en stapte over naar softwareontwikkeling voordat het internet mainstream werd. De behoefte was hetzelfde, de schaal was wereldwijd. Kapor gaf de rol een naam vanuit de industrie zelf.

Zijn redenering was simpel: als je een huis ontwerpt, praat je eerst met een architect voordat je met een ingenieur praat. Niet omdat ingenieurs niet essentieel zijn, want dat zijn ze wel, maar omdat de eerste vragen niet structureel zijn. Ze gaan over hoe mensen zullen leven. Waar moet de keuken zich bevinden ten opzichte van de eetkamer? Dat komt voort uit het begrijpen van menselijke behoeften, niet uit technische beperkingen. Software, zo betoogde Kapor, had deze stap volledig overgeslagen.

"Een van de belangrijkste redenen waarom de meeste computersoftware zo erbarmelijk is, is dat het helemaal niet ontworpen is, maar slechts geconstrueerd." — Mitch Kapor

Een vertaling van Vitruvius door een renaissance-architect, circa 1530-1545. Plattegrond en geveltekening samen getekend — de blauwdruk als denktool, niet als afgewerkt product. The Metropolitan Museum of Art, legaat van W. Gedney Beatty, 1941. Publiek domein.

Tweeduizend jaar geleden betoogde de Romeinse architect Vitruvius dat goede gebouwen drie kwaliteiten bezitten: firmitas, utilitas en venustas. Ze zijn gebouwd om lang mee te gaan, ze voldoen aan de behoefte en ze belonen de ervaring van het verblijf erin. Kapor zag dezelfde criteria voor software.

Drie decennia later voelt Kapors argument minder aan als een manifest en meer als een tijdloos principe, een principe dat nog belangrijker wordt in een wereld waarin handelen centraal staat.

Daarom is "hoe mensen zich bewegen door wat we bouwen" geen ontwerpvoorkeur. Het is de basis.

Een blauwdruk is geen specificatie. Het is een gedeeld beeld van hoe mensen zich door het product bewegen dat je aan het bouwen bent: hoe deze functie verbonden is met de volgende, wat er gebeurt nadat iemand een taak heeft voltooid, waar ze naartoe gaan als er iets misgaat. Het zorgt ervoor dat het team zich richt op de gebruiker aan de andere kant, en niet alleen op het product dat vorm krijgt.

En zoals elk blauwdruk moet het verder gaan dan alleen de kamers: de toegangsrechtenarchitectuur, de datagrenzen, de faalscenario's, de vertrouwensinfrastructuur die... Het legt alles plat.

De mensen in het gebouw zijn afhankelijk van die infrastructuur, of ze nu weten dat die er is of niet. Ze zien de fundering niet. Ze vertrouwen er gewoon op dat de vloer niet zal bezwijken.

We hebben al te vaak gezien wat er gebeurt als die laag wordt aangenomen in plaats van ontworpen. Datalekken zijn geen oppervlakkige fouten. Het zijn architectonische fouten – iets wat in de blauwdruk had moeten staan, is er niet in opgenomen.

In een wereld waarin systemen namens mensen handelen en toegang hebben tot hun accounts, bestanden en financiën, zijn de kosten van een fout niet alleen ongemak. Het is blootstelling.

Leiderschap in design is essentieel geworden voor technologische innovatie. Wat Kapor beschreef als een ontbrekende rol is nu ingebed in de hele industrie – in productteams, in engineeringorganisaties, in hoe bedrijven mensen aannemen en ontwikkelen.

In 1996, toen zijn manifest werd gepubliceerd, waren er ongeveer 36 miljoen mensen online. Vandaag de dag zijn dat er 5,5 miljard, verspreid over 18 miljard verbonden apparaten. De discipline is niet zomaar ontstaan. De schaal groeide exponentieel.

Maar de organisatorische uitdaging die Kapor signaleerde, blijft bestaan.

Teams werken nog steeds in silo's en de discipline om leerervaringen te verbinden over de verschillende gebruikerstrajecten heen overleeft zelden de druk om te lanceren. Kapor merkte iets op wat ik gedurende mijn carrière vaker heb gezien: als software mensen in de steek laat, geven ze zichzelf de schuld. "Mensen schamen zich om te zeggen dat ze deze apparaten moeilijk te gebruiken vinden", schreef hij. "Ze denken dat het hun eigen schuld is."

De druk is alleen maar toegenomen. Jenny Wen, Head of Design voor Claude bij Anthropic, beschreef de verschuiving in Lenny's Podcast: planning en prototyping, werk dat ooit 60 tot 70% van de tijd van een ontwerper in beslag nam, is gedaald tot 30 tot 40%. Visiehorizonten die vroeger jaren besloegen, worden nu ingehaald tot maanden. Het blauwdrukwerk verdwijnt niet. Het wordt zo ingekort dat het misschien helemaal niet meer als blauwdruk functioneert.

Maar principes implementeren zichzelf niet. Sarah Winchester kon het zich veroorloven om een gang uit te breken als die mislukte en het opnieuw te proberen. Ze had het budget om eindeloos te blijven innoveren. Dat is een zeldzame luxe.

Er is hier een schrijnende ongelijkheid. Slechts een handjevol bedrijven kan het zich permitteren om het huis te repareren nadat het al gebouwd is. Google is er daar één van. Ze hebben dit expliciet als principe gepubliceerd: "prioriteit voor landingen boven lanceringen", omdat ze hebben gezien wat er gebeurt als incentives de lancering belonen en de gebruikerservaring daardoor verbrokkelt. En ze kunnen het minder aantrekkelijke werk financieren: refactoring, consistentie, prestaties, toegankelijkheid, de verbindende schakels die ervoor zorgen dat het geheel onvermijdelijk aanvoelt in plaats van toevallig. Alphabet genereerde alleen al in 2025 $73,3 miljard aan vrije kasstroom.

De meeste bedrijven hebben die luxe niet. Niet de financiële buffer, niet de talentenpool, niet de tijd. Dus als je het ontwerpproces overslaat, ben je niet gedurfd bezig. Je stelt de rekening alleen maar uit. Je betaalt er later voor in de vorm van technische problemen, een hogere belasting voor de support en, nog gevaarlijker, klanten die wrijving ervaren en vertrekken omdat het makkelijker is dan de interne problemen van je organisatie op te lossen.

De kosten zijn meetbaar. Gartner ontdekte dat 96% van de klanten die veel moeite moeten doen om een klant te bereiken, minder loyaal worden, vergeleken met slechts 9% bij een soepele ervaring. Amerikaanse bedrijven verliezen naar schatting $168 miljard per jaar aan vermijdbare klantverlies. Klanten die hun ervaring het hoogst waarderen, geven 140% meer uit.

Het probleem met Winchester is niet alleen een slecht ontwerp. Het is het vertrekpunt voor klanten.

Soms is een schets op een servetje voldoende om overeenstemming te bereiken over hoe je mensen het beste kunt bedienen. Het plan moet aansluiten op de situatie. Wanneer je een hypothese test, wanneer leren vereist dat iets in de praktijk wordt getest, is precisie voorbarig. En wanneer je iets bouwt dat over teams en door de tijd heen moet blijven functioneren, vormt dat gedeelde begrip je fundament.

Frank Gehry schetste de ideeën, en teams verfijnden en bouwden het gebouw © Alamy

Ik heb gezien wat er mogelijk wordt wanneer teams investeren in die basis. Bij Google leidde ik het gebruikersonderzoek en het ontwerp voor het samenvoegen van gefragmenteerde betaalervaringen in één platform, wat later Google Pay werd. Bij Meta brachten we gefragmenteerde zakelijke tools samen in Meta Business Suite, waardoor miljoenen kleine bedrijven een product-marktfit bereikten.

Verschillende bedrijven, dezelfde kans: het maken van een blauwdruk zet geërfde complexiteit om in impact.

De druk om te kopiëren maakt dit moeilijker. Wanneer een concurrent iets op de markt brengt en het management vraagt: "Waarom hebben wij dat niet?", voelt het maken van een blauwdruk als een luxe.

Kopiëren is een variant op dezelfde fout. Je importeert de kamer van iemand anders zonder te begrijpen hoe die aansluit op je eigen huis, of dat hun huis überhaupt dezelfde plattegrond had.

Amazon had een uitspraak die mijn kijk hierop heeft gevormd: "We zijn niet geobsedeerd door concurrenten. We zijn geobsedeerd door klanten." Klantgerichtheid dwingt je om aan de blauwdruk te werken. Concurrentiegerichtheid zorgt ervoor dat je die kunt overslaan.

Toen de ontwikkeling traag verliep, werden onduidelijke intenties gaandeweg gecorrigeerd. Wrijving creëerde ruimte voor reflectie. De blauwdruk kon vaag zijn, omdat de constructie hem zou aanscherpen.

Dat is nu minder het geval. AI kan complete producten in een paar uur genereren. Als je blauwdruk onduidelijk is, krijg je een goed gebouwd huis waarvan de kamers niet met elkaar verbonden zijn, en dat ook nog eens snel.

Hier is een terechte tegenwerping: AI-gestuurde producten zijn niet-deterministisch. Je kunt niet elke toestand simuleren. Maar dat miskent waar de blauwdruk voor dient. Je voorspelt niet elke uitkomst. Je bepaalt hoe agenten zich tot elkaar verhouden, welke context ze delen, wat er gebeurt als er één faalt. Hoe minder voorspelbaar de kamers zijn, hoe belangrijker de gangen worden.

De belofte van AI is snelheid. Sneller leveren, sneller bouwen, sneller itereren. Maar snelheid is alleen waardevol als je in de juiste richting beweegt. Een blauwdruk vertraagt dat niet. Het is juist wat de snelheid betekenis geeft. Zonder blauwdruk beweeg je niet sneller. Je komt alleen maar eerder op de verkeerde plek terecht.

De data bevestigen dit. Een MIT-studie naar 300 AI-implementaties in het bedrijfsleven toonde een consistent patroon aan: falen werd niet veroorzaakt door de kwaliteit van het model, maar door de aanpak.

Teams voegden AI toe aan bestaande workflows zonder eerst het proces opnieuw te ontwerpen. De technologie werkte, maar het huis niet. Dat is het probleem met de blauwdruk, op een schaal van miljarden dollars.

Stel je voor dat agenten namens jou handelen. De ene boekt je vlucht, de andere reserveert een hotel, een derde controleert je agenda, en elk voert zijn taak uit. Maar niemand had bedacht hoe ze zouden samenwerken. De vlucht landt om middernacht, de hotelreceptie sluit om tien uur en je agenda toont een ontbijtafspraak waar je nooit bij zult zijn.

Wanneer de uitvoering de intentie overtreft, krijg je geen beter huis, maar een snellere puinhoop. Afbeelding gegenereerd met ChatGPT / OpenAI. Gemaakt door Scott Hines.

De agenten waren niet kapot. Ze werden gewoon nooit geïntroduceerd. Elk systeem deed precies waarvoor het ontworpen was, op zichzelf staand.

Maar wanneer orchestratie werkt, is het op de beste manier onzichtbaar. Denk aan wat er gebeurt als je een Uber bestelt. Een systeem voorspelt de vraag in de stad, een ander bepaalt de prijs op basis van het aanbod, een derde koppelt je aan een chauffeur die rekening houdt met afstand, verkeer, richting en voorkeuren van de chauffeur, en een vierde optimaliseert de route in realtime. Elk onderdeel levert data aan de andere, waardoor feedbackloops ontstaan die met elke rit verbeteren. Vijftien miljoen ritten per dag, gekoppeld in milliseconden. Je ziet hier niets van. Je ziet alleen een auto aankomen. Google Foto's werkt op dezelfde manier: je vraagt het niet om je mooiste momenten te onthouden; het doet het gewoon. Dat is wat er gebeurt als de kamers op een rij staan.

Zo ziet goede orchestratie eruit: agenten die op de achtergrond werken terwijl jij op je bestemming aankomt. Het ontwerp kwam eerst. En in het hart van dat ontwerp staat een vraag die verrassend moeilijk te beantwoorden blijkt te zijn: wat wil deze persoon nu eigenlijk? Amazon noemt het intentiedetectie: het vermogen van de orchestratielaag om het doel van een gebruiker correct te interpreteren voordat deze naar de juiste agent wordt doorgestuurd. Als het werkt, voelt de ervaring naadloos aan. Als het mislukt, is de kettingreactie direct: verkeerde agent, verkeerd antwoord, toenemende frustratie. Het correct beantwoorden van die vraag is nu een fundamentele technische uitdaging, geen bijzaak meer bij het ontwerp.

Klantenservice met agenten is het tegenvoorbeeld. Je begint vol hoop, maar al snel word je van de ene agent naar de andere gestuurd: "bestelgegevens", "retouren", "technische hulp". Niemand herinnert zich je. Elke deur leidt naar een nieuwe kamer en je weet niet zeker of er een uitgang is. Je belandt in een kast, zonder context, zonder uitweg, en je verbreekt de chat. De volgende keer ga je ergens anders winkelen.

De meeste productiefouten in agentsystemen zijn geen modelfouten. Het zijn architectuurfouten, de verbindingen tussen agenten, niet de agenten zelf. Weer die kamers.

Goed ontworpen agentsystemen hebben een orchestratielaag, iets dat het doel van de gebruiker vasthoudt en de subtaken coördineert. Maar die laag ontwerpt zichzelf niet. Iemand moet de afhankelijkheden in kaart brengen, de overdrachten definiëren en bepalen welke context elke agent van de anderen nodig heeft. Serviceontwerpers noemen dit de backstage. In een agentgestuurde wereld speelt het grootste deel van de ervaring zich achter de schermen af. Zoals een designanalyse uit 2026 het stelde: we ontwerpen geen schermen meer voor gebruikers, we ontwerpen intelligentie die voor hen handelt. De interface is naar de achtergrond verplaatst. Dat geldt ook voor het ontwerpwerk.

Kapor begreep dit al toen schermen het medium waren. Het principe blijft van kracht nu het medium verschuift naar agents. Teams die diezelfde nauwkeurigheid toepassen op de orchestratie, die de backstage net zo bewust ontwerpen als ze ooit de interface ontwierpen, zullen ervaringen creëren waarin mensen daadwerkelijk willen vertoeven.

Het ambacht verdwijnt niet. Het verschuift van constructie naar intentie.

De tools zullen steeds sneller worden en sommige interfaces zullen wellicht verdwijnen. Wat niet zal verdwijnen, is het menselijke werk van begrip: gedrag observeren, klantreizen in kaart brengen, vragen hoe mensen zich daadwerkelijk door hun omgeving bewegen. r levens. Er is geen kortere weg naar het gesprek waarin iemand je laat zien wat ze echt nodig hebben, in plaats van wat je aannam dat ze wilden.

Dat is het werk van de blauwdruk. Naarmate de bouw versnelt, verdwijnen de kosten van het overslaan ervan niet. Ze stapelen zich op.

De vraag van Kapor, of we een gedeeld begrip hebben van hoe mensen zich zullen bewegen door wat we bouwen, werd geformuleerd voor een conferentie in 1990. Het is nog steeds de juiste vraag.

Het afdwingen ervan is het echte werk. Wanneer teams worden beloond voor het opleveren van functionaliteiten, voelt de vraag hoe mensen zich door de hele ervaring bewegen als wrijving. Dat is het niet. Het is de blauwdruk. Zonder die blauwdruk ontwerp je niet als een architect. Je voegt gewoon kamers toe.

De blauwdruk beantwoordt de vraag vóór de bouw begint: hoe zullen mensen zich hierdoorheen bewegen?

Er wordt in de hele branche fantastisch werk verricht door mensen die dezelfde vraag stellen. En er zijn nog steeds gebroken ervaringen, teams die kamer na kamer toevoegen zonder afstand te nemen en het geheel te overzien.

Het Winchester House staat er nog steeds. Trappen die nergens heen leiden, deuren die naar muren leiden. Het werkte voor de vrouw die het bouwde. Tegenwoordig is het een toeristische attractie. Mensen betalen om de desoriëntatie te ervaren, om rond te dwalen in iets dat nooit met hen in gedachten is ontworpen.

De meesten van ons bouwen voor mensen die we nooit zullen ontmoeten. Dat is de kans: een plek bouwen waar ze willen wonen.

Scott Hines

Mitch Kapors "A Software Design Manifesto" werd in 1990 gepresenteerd op Esther Dysons PC Forum. Het verscheen als het openingshoofdstuk van Terry Winograds Bringing Design to Software (Addison-Wesley, 1996).

Designing Impact is een serie van Scott Hines over werk dat blijvend is – waarom sommige ideeën en innovaties de wereld blijven vormgeven lang nadat de mensen die ze bedachten er niet meer zijn, en wat er nodig is om op die manier te bouwen.