## [Gode dage skal tælle sig selv](/da/node/286) *Indsendt af Lennart den fre, 18 sep 2026 - 20:05* [ ![Gode dage skal tælle sig selv](/sites/default/files/styles/max_1300x1300/public/2026-09/composite_12.png.avif?itok=NXJu9fs4)](/sites/default/files/2026-09/composite_12.png) *Om de designvalg, der afgør, om et system til vaneændring bliver brugt i tredje uge — eller kun i den første.* Vi har to lister derhjemme. Den ene hedder Less, den anden More. På Less står ting, vi gerne vil have færre af: skænderier, fravær. På More står ting, vi gerne vil have flere af: fælles cykelture. Listerne har længe ligget i Google Tasks, hvor de gjorde præcis det, en liste gør: de mindede os om, at vi havde besluttet noget. Ikke om vi holdt det. Så jeg byggede en lille side, der viser listerne med en streak på hvert punkt. Det tog en formiddag sammen med en AI-kodeagent. Det interessante var ikke koden. Det var de beslutninger, der skulle træffes undervejs — og hvor mange af dem der viste sig at handle om mennesker, ikke om tal. ## Less og More er ikke det samme regnestykke Den første fejl, jeg var ved at begå, var at behandle de to lister ens. På **Less** er det, man registrerer, et brud: der var et skænderi i dag. Alle de andre dage er gode dage, og dem skal man ikke registrere. De skal tælle sig selv. Et system, der kræver, at man trykker "i dag gik det godt" hver aften, bliver brugt i en uge. På **More** er det omvendt. Det, man registrerer, er aktiviteten: vi cyklede. En dag uden registrering er en sprunget dag. Her *skal* man huske at trykke, ellers brydes streaken — og det er ikke en fejl i designet, det er hele pointen. Vanen er at gøre det. Samme skærm, samme knap, modsat logik. Den ene belønner fravær af handling, den anden kræver handling. ## Kun hele dage tæller Der var et skænderi i går. Hvor mange dage har vi så været uden? Mit første svar var én — i dag. Men i dag er ikke slut. Det rigtige svar er nul i dag og én i morgen, når dagen faktisk er gået godt. Ellers tæller systemet på noget, der endnu ikke er sket. For More gælder det modsatte: har vi cyklet i går, men ikke endnu i dag, lever streaken stadig til midnat. Den brydes først, når en hel dag er gået uden. Det lyder som en detalje. Men det er forskellen på et tal, man stoler på, og et tal, man begynder at forhandle med. ## Et nul siger ingenting Når en streak er brudt, står der "0 dage i træk". Det er sandt, og det er ubrugeligt. For More viser siden derfor noget andet, når streaken er væk: "3 dage siden sidst". Det tal kan man handle på. Og for Less det samme spejlvendt: har der været fravær tre dage i træk, er det ikke bare "0 dage uden". Så står der i rødt "3 dage i træk". Det var i øvrigt ikke min idé. Den kom fra spørgsmålet "burde vi ikke bare måle dage siden sidste gang?" — hvor svaret blev, at det er det rigtige tal, når streaken er brudt, og det forkerte, mens den lever. Så nu viser siden begge, hver på sit tidspunkt. ## Knappen skal sige, hvor du er En knap, der hedder "+1", fortæller dig, hvad den gør. Den fortæller dig ikke, hvordan det går. På More skifter knappen navn: **Get going**, når der ikke er nogen streak. **Keep it up**, når streaken lever, men dagen i dag mangler. **Yeah!**, når dagen er reddet, og man bare tæller en tur mere. På Less hedder den **Not again**, når der ikke er meget at miste, og **Oh no!**, når der er gået en uge eller mere. Og den kan kun trykkes én gang om dagen — en dag er brudt eller ikke brudt. Man kan derimod cykle to gange samme dag, så dér tæller alle tryk med i antallet, mens streaken kun ser på dage. Knappen er blevet det sted, man aflæser status. Det havde jeg ikke planlagt. ## Registrér ikke det, der allerede er registreret Fravær stod allerede i min dagbog. Jeg skriver noter med lidt struktur i toppen, og når der er fravær, står det dér. At skulle trykke på en knap *også* ville være dobbeltbogføring, og dobbeltbogføring går i stykker på den dag, man glemmer det ene sted. Så fravær er et automatisk punkt: systemet læser datoerne fra dagbogen og har ingen knap. Hvilke punkter der er automatiske, står i noterne til opgaven i Google Tasks — så nye kan tilføjes fra telefonen uden at røre koden. ## Gem det, der skete. Regn resten ud. Hvert tryk gemmes som en hændelse i en log, der kun kan skrives til, aldrig rettes i. Fortryder man et tryk, slettes intet; der lægges en fortrydelse oven på. Streaks, rekorder og "dage siden" gemmes ingen steder. De regnes ud, hver gang siden vises. En sprunget dag på More er for eksempel aldrig gemt som en sprunget dag — det er et hul mellem to cykelture. Havde jeg gemt den, ville den være forkert, i det øjeblik nogen fortrød en registrering fra dagen før. Er det ikke dyrt at regne alt ud hver gang? Jeg målte i stedet for at gætte: med tre tusinde dages data tager det omkring ti millisekunder. Med de mængder, en familie producerer, er det ingenting. Listerne bliver i øvrigt i Google Tasks, hvor de altid har været. Min egen maskine sender en kopi af de to lister til siden hvert femte minut. Google-nøglerne forlader aldrig maskinen, og resten af mine opgaver sendes ikke med. ## Hvad en leder kan tage med Det her er et familieprojekt, men beslutningerne er de samme, som når en virksomhed indfører nøgletal: 1. **Spørg, hvem der skal registrere hvad.** Et mål, der kræver, at folk melder "alt gik fint" hver dag, bliver ikke vedligeholdt. Lad det gode tælle sig selv, og registrér afvigelserne. 2. **Vælg det tal, man kan handle på.** "0" er sandt og ubrugeligt. "3 dage siden sidst" er en opfordring. 3. **Gem hændelser, ikke konklusioner.** Et gemt nøgletal er forkert i det øjeblik, grundlaget ændres. En gemt hændelse er sand for altid. 4. **Lad være med at bede folk indtaste noget, der allerede står et andet sted.** Hent det. Jeg har før skrevet om, at [min morgenbriefing ikke har brug for en AI-agent](https://docujai.com/da/node/283). Det her er samme erfaring fra en anden kant: AI'en skrev det meste af koden på en formiddag. Men det, der gør systemet brugbart, er ikke koden. Det er beslutningerne om, hvad der skal tælle, hvem der skal trykke, og hvad et nul betyder.