26 år efter styrer de gale stadig dårekisten — de er bare blevet bedre til at skjule det

Gennem en ven fik jeg fat i et personligt signeret eksemplar af The Inmates Are Running the Asylum — de gale styrer dårekisten — den bog, der mere end nogen anden har formet den måde, jeg tænker software på. Alan Cooper er blandt andet manden bag Visual Basic, og han er virkelig et af mine idoler.

På titelbladet havde Cooper skrevet:

I hope you enjoy this 26-year-old book. Its main message is that good user experience is not a design problem but is rather a power struggle.

Jeg læste bogen første gang et godt stykke inde i min karriere inden for produktledelse, mens jeg tog Pragmatic Marketing-kurser. Det er den bog, der lærte mig forskellen på at bygge det, udviklerne synes er interessant, og det, der rent faktisk løser et virkeligt problem for markedet.

Ikke længe efter satte jeg for alvor den lærdom på prøve. I et softwarefirma, jeg arbejdede for, havde organisationen et problem, som ingen havde lyst til at sige højt: man forstod ikke vigtigheden af brugeroplevelsen, eller hvorfor den skulle komme først. Udviklingen foregik konsekvent indefra og ud. Nye features fandt man på ved at samle de skarpeste udviklere i et lokale og vente, til der kom noget genialt ud af det — ikke ved at lave Markedsundersøgelser eller sætte sig ind i de problemer, kunderne rent faktisk havde. Design kom til sidst — en gang maling oven på. Først byggede man backenden, og bagefter satte man nogen til at gøre den pæn.

Som produktchefer ville vi gerne lave om på den rækkefølge, og vi kom ingen vegne med at argumentere for sagen på møderne. Så vi købte femten eksemplarer af Coopers bog, gav ét til hver chef og lead developer i huset og gjorde den til obligatorisk læsning.

Det, der kom ud af det, var en ny proces. Før havde det hele været udviklerbeslutninger, det ene efter det andet: ingeniørerne besluttede, hvad der skulle bygges, hvordan det skulle virke, og hvordan det skulle se ud. Nu blev det til tre adskilte trin. Produktledelsen identificerede de reelle bruger- og markedsproblemer, satte tal på dem og afgjorde, hvilke af dem der var værd at løse først. UX-folkene fandt ud af, hvordan de problemer så rent faktisk skulle løses for dem, der havde dem. Og først derefter fandt udviklerne ud af, hvordan man fik teknologien til at gøre det. Firmaet blev siden bedst i klassen, når det gjaldt brugeroplevelse — ikke fordi nogen blev dygtigere fra den ene dag til den anden, men fordi ingen længere havde lov til ubemærket at springe direkte til tredje trin.

Så da der landede et signeret eksemplar med Coopers bemærkning om en “magtkamp”, var det spørgsmål, bogen rejste, ikke bare teoretisk for mig. Jeg havde allerede én gang brugt rigtig mange kræfter på at få den kamp til at falde ud på en bestemt måde. Og nu, hvor Claude, Codex, Claude Design, Lovable, v0 og vibe coding er kommet ind i billedet, ville jeg gerne vide: har det problem, jeg kæmpede for at løse, endelig løst sig selv?

Det umiddelbare svar

En af Coopers centrale iagttagelser er, at de mennesker, der bygger software, er grundlæggende anderledes end dem, der bruger den. Han har døbt den test, der afslører det: Jetway-testen. Alle, der går om bord på et fly, passerer et punkt, hvor de i princippet kunne dreje til venstre ind i cockpittet eller til højre ind i kabinen. At dreje til venstre betyder, at man må forstå hvert eneste instrument og selv har både kontrollen over flyet og ansvaret for at få det ned igen. At dreje til højre betyder, at man giver helt afkald på begge dele og til gengæld får en plads, en drink og vished om at komme frem uden at skulle forstå noget mere kompliceret end læselampen.

Jeg er uden tvivl en af dem, der drejer til venstre. Det er de fleste udviklere også. Coopers pointe var aldrig, at det gør os dårlige til vores arbejde. Pointen var, at vi bliver ved med at bygge cockpits til folk, der aldrig har ønsket sig andet end kabinen. Udviklere kan holde til kompleksitet, abstraktion og konfiguration i et omfang, som almindelige brugere aldrig vil finde sig i, og når vi designer efter vores egne mentale modeller — hvilket udvikling indefra og ud stort set garanterer — så er det dem, der skal bruge resultatet, der kommer til at betale prisen.

Generativ AI ser ud til at opløse det problem ved roden. I stigende grad kan den, der har problemet, selv bygge softwaren. Ingen udviklers mentale model kommer i vejen, for der er ingen udvikler imellem længere. Så hvad sker der med en bog om magtkampen mellem udviklere og brugere, når alle kan blive begge dele?

Det umiddelbare svar er, at problemet forsvinder.

Det tror jeg ikke, det gør.

Pænt er ikke brugervenligt. Brugervenligt er ikke nyttigt.

Førhen kunne man se på software, at den var bygget af udviklere — grå formularer, rå databaseterminologi, et dusin afkrydsningsfelter uden en eneste forklaring. Den manglende æstetik var på sin vis ærlig: den røbede med det samme, at ingen havde gjort sig store tanker om brugeren.

Claude Design kan tage nøjagtig den samme konceptuelle model og give den fremragende typografi, flotte kort, runde hjørner og smagfulde animationer — virkelig flot, på få minutter, og med alle 2026-softwarens visuelle konventioner på rygraden.

Dårekisten anno 2026 har runde hjørner, fremragende typografi og smagfulde animationer.

Men visuelt design er ikke interaktionsdesign. Og selv fremragende interaktionsdesign er ingen garanti for, at man løser det rigtige problem.

Det er præcis det samme træk, som jeg så udspille sig i mit gamle firma, bare forstærket. Dengang byggede man backenden først og satte bagefter en designer til at gøre den præsentabel — et forløb, der tog et sprint eller to, og som var synligt nok til, at nogen en gang imellem standsede op og spurgte, om den underliggende model overhovedet var den rigtige. I dag tager “gør den præsentabel”-trinnet omkring halvfems sekunder, og resultatet er så godt, at næsten ingen standser op og stiller det spørgsmål længere.

Lad os sige, at en revisor fortæller: “Jeg har brug for en skærm, hvor jeg uploader to Excel-filer, ser dem side om side, får forskellene fremhævet og trykker på en knap for at afstemme dem.” Claude kunne bygge en glimrende udgave af præcis det. Men måske har den bedste løsning slet ingen afstemningsskærm — måske afstemmer systemet løbende transaktionerne i baggrunden og kun lægger de tre tilfælde på bordet, som der reelt er tvivl om.

Revisoren forstår sit problem bedre, end nogen udvikler gør. Det har aldrig været til diskussion. Men at forstå et problem indgående er ikke det samme som at kunne forestille sig den bedst tænkelige løsning på det. Folk beskriver løsninger ud fra de arbejdsgange og de programmer, de allerede kender, for det er det eneste sprog, de har.

Flaskehalsen har flyttet sig

Generativ AI er ekstremt god til at implementere den løsning, man beder om. Det er ikke det samme som at forstå, hvilket problem der er værd at løse, eller hvordan en arbejdsgang grundlæggende burde laves om. Mellem de to ting er der en kløft, og den betyder mere nu end før. Grunden er ubehagelig: AI har gjort det dramatisk billigere at bygge løsninger. Den har ikke gjort det tilsvarende billigere at forstå problemer. Snarere tværtimod: billig implementering gør det gamle problem værre.

For tyve år siden var det dyrt at bygge den forkerte software. Kravspecifikation, design, udvikling, test og udrulning skabte alle sammen friktion, og noget af den friktion tvang organisationen til at standse op og spørge, hvorfor den overhovedet var i gang med at bygge noget. I dag: “Claude, byg mig et dashboard til fakturaafstemning” — og kort efter står der en fungerende applikation.

Det er virkelig imponerende. Det er også sådan, man bygger det forkerte hurtigere end på noget tidspunkt i softwarens historie. Flaskehalsen har flyttet sig fra kan vi bygge det her? til bør vi bygge det her, og hvad skal det egentlig kunne? — og det gør produkttænkning og reel forståelse af brugerne vigtigere, ikke mindre.

Det er værd at være præcis om, hvad der egentlig er blevet billigt. AI har klemt tredje trin ned til næsten ingenting — udviklingstrinnet i den proces, jeg var med til at indføre dengang. De to første har den overhovedet ikke rørt. At finde ud af, hvilket problem der reelt er værd at løse, er præcis lige så svært, som det var i 1999. At finde ud af, hvordan det problem bør løses for dem, der har det, er præcis lige så svært. Det eneste, der har ændret sig, er, hvor fristende det nu er at springe direkte til en fungerende prototype og så stiltiende betragte de to første trin som afklarede.

Magten bliver omfordelt

Jeg vender hele tiden tilbage til Coopers håndskrevne linje: god brugeroplevelse er en magtkamp, ikke et designproblem. AI gør ikke en ende på den kamp. Den ændrer, hvem der har magten i kampen.

I 1999 havde programmørerne enorm magt, fordi de kontrollerede implementeringen — de var de eneste, der kunne gøre noget som helst til virkelighed. I dag bliver den magt omfordelt. Designere kan selv bygge det, de tegner. Produktchefer kan selv lave prototyper. Direktører kan bygge deres egne værktøjer. Fageksperter og almindelige brugere kan vibe-code en applikation til præcis det problem, de står med.

Men at fordele magten over implementeringen er ikke det samme som at fordele produktindsigten. Det er to forskellige greb, og kun det ene er blevet dramatisk billigere.

Der findes en skarpere udgave af det her, som er værd at dvæle lidt ved. Forestil jer, at I vibe-coder noget udelukkende til jer selv: udvikler og bruger er endelig den samme person, så Coopers indvending burde ganske enkelt forsvinde. Og et stykke tid gør den det også. Men når man har siddet tredive timer inde i sin egen datamodel, sin egen terminologi, sine egne konfigurationsvalg og sine egne særheder, er der ting, som man ville være nødt til at forklare for alle andre, men som nu føles fuldstændig indlysende for en selv. Og så giver man programmet videre til en anden.

Man er blevet ekspert i sin egen implementering. Man er havnet i dårekisten igen. Man har bare selv bygget den denne gang.

De gale har fået en forstærker

Beder man en generativ model om “en admin-grænseflade til styring af brugere, roller og rettigheder”, får man tabeller, filtre, dialogbokse og pænt designede badges — rigtig godt arbejde. Men det egentlige problem er måske noget langt mindre: Anna skal kunne godkende fakturaer, mens Peter er på ferie. Brugere, så roller, så rettigheder, så ressourcer, så CRUD-skærme (create, read, update, delete) er ofte bare implementeringsmodellen, der siver direkte ud gennem grænsefladen. Modellen bliver ikke bedre af at være smuk.

Generative modeller har også lært konventionerne i eksisterende software ekstremt godt. Beder man om et CRM, får man noget, der ligner et CRM. Beder man om projektstyringssoftware, får man kort, statusser, ansvarlige og dashboards. Det er imponerende — og det bekræfter samtidig helt stilfærdigt antagelsen om, at software skal se ud, som software nu engang ser ud. Noget af den bedste produkttænkning, jeg har mødt, begynder med at afvise den antagelse og stille det sværere spørgsmål: hvorfor skal det her overhovedet se ud som software?

Intet af det skyldes, at modellen er doven. Det skyldes, at modellen selv er en af de gale. Coopers udviklere sad fanget inde i deres egne tekniske mentale modeller og greb efter det, der føltes indlysende for dem, i stedet for det, markedet faktisk havde brug for. En agent sidder fanget på nøjagtig samme måde, bare med forstærkeren skruet helt op — den har suget formen til sig fra hvert eneste CRM, hvert eneste admin-panel og hvert eneste dashboard, nogen nogensinde har sendt på gaden, og den griber uvilkårligt efter den form, på samme måde som et lokale fuldt af skarpe udviklere griber efter det, der begejstrer dem. Den har ikke bygget dårekisten. Den har på én gang arvet hver eneste dårekiste, der nogensinde er bygget, og den har som udgangspunkt ingen grund til at træde uden for den form og spørge, om der overhovedet skal bygges noget til netop det her problem.

Hvor det stiller os

Forvent ikke, at agenten stiller spørgsmålet for dig. Den eksekverer glimrende inden for de konventioner, den er trænet på. Men at spørge, om det her problem overhovedet kræver software, der ser sådan ud, er ikke noget, den er bygget til. Det er stadig et arbejde for en, der rent faktisk har gjort sig umage med at forstå de mennesker, der har problemet.

Behandl et hurtigt build som en hypotese, ikke som et svar. Den hastighed, der gør AI værdifuld, er den samme hastighed, der gør det muligt at springe det trin over, hvor nogen spørger, om I nu også løser det rigtige problem. Sæt det trin bevidst ind igen, for der er ikke længere noget andet, der fremtvinger det.

Hold øje med de forstærkede gale. En smuk CRUD-skærm er stadig en CRUD-skærm. Glem typografien, og spørg, hvilken konceptuel model der egentlig styrer grænsefladen, og om en bruger nogensinde ville beskrive sit problem på den måde.

Femten eksemplarer af en bog løste ikke mit gamle firmas UX-problem i sig selv. Det, der løste det, var at dele én opgave op i tre trin, så ingen længere ubemærket kunne skubbe “find problemet” og “design, hvordan det løses” ind under “byg tingen”. Det handlede i virkeligheden aldrig om, hvor mange vi var — det krævede strengt taget aldrig tre forskellige jobtitler. Det krævede disciplin: at de tre trin blev ved med at stille hvert sit spørgsmål, og at hvert spørgsmål blev taget alvorligt af den eller det, der stod for trinnet. De agenter, der bygger for os i dag, er ekstremt gode til det tredje. På de to første har de som udgangspunkt ikke meget at bidrage med. Et problem er ikke løst, før det er løst for dem, der har det. AI har ikke fjernet behovet for den disciplin. AI har bare gjort det meget nemmere at springe den over.

Hvis I ikke har læst bogen: The Inmates Are Running the Asylum holder bedre, end man har ret til at forvente af en 26 år gammel tech-bog.