Dark patterns: dokumentation af designvalg

“Dark patterns” er en samlebetegnelse for design, der skubber brugeren i en bestemt retning: en forudvalgt afkrydsning, en knap til at afslå, der er svær at finde, en nedtælling, der starter forfra, eller en opsigelse, der kræver mange flere klik end tilmeldingen. I civile tvister om forbrugeraftaler, markedsføring og samtykke kan det blive afgørende, hvad brugeren faktisk så. Det er sværere at dokumentere, end det lyder. Moderne hjemmesider og apps viser ikke den samme side til alle, og designet ændres løbende. Denne artikel handler om, hvordan advokaten får dokumenteret designet, som det var, og ikke som det ser ud i dag. Tvister om tilmelding og opsigelse af abonnementer er beskrevet i Abonnementsfælder: tilmelding, vilkår og opsigelse.

Hvorfor det er svært

Et skærmbillede af en side viser én version, set af én bruger, på ét tidspunkt. Men en moderne løsning er sjældent én version:

A/B-test. Brugerne deles op i grupper, som ser forskellige varianter af den samme side.
Feature flags. Funktioner slås til og fra for bestemte brugere, lande eller perioder uden ny udgivelse.
Personalisering. Indhold og rækkefølge afhænger af brugerens historik, enhed eller placering.
Løbende udgivelser. Designet kan ændres flere gange om ugen.
App og web. Den samme tjeneste kan se forskellig ud i appen, på mobilens browser og på en computer.

Spørgsmålet er derfor ikke kun “hvordan så siden ud?”, men “hvilken version så netop denne bruger, på denne enhed, på dette tidspunkt?”.

Bevistemaer

En tvist om designvalg kan typisk deles i fire bevistemaer:

Designet. Hvordan så skærmbilledet eller forløbet ud, trin for trin?
Eksponeringen. Hvilke brugere så hvilken variant, og i hvilken periode?
Hensigten. Hvad var formålet med designet, ifølge virksomhedens egne overvejelser?
Effekten. Hvordan påvirkede designet brugernes valg?

Hvilke af disse temaer der har juridisk betydning, afhænger af sagen og reglerne. Teknisk har hvert tema sine egne kilder.

Kilder hos virksomheden

Virksomheden bag løsningen har normalt langt den bedste dokumentation, selv om den ikke er samlet til formålet:

Kildekode og versionsstyring, der viser, hvordan forløbet var bygget på et bestemt tidspunkt.
Designfiler i designværktøjer, ofte med versionshistorik og kommentarer.
Konfiguration af A/B-test og feature flags, der viser, hvilke varianter der var aktive, for hvem og hvornår.
Analysedata, der viser, hvor mange brugere der så hvilken variant, og hvad de valgte.
Samtykkelogs fra cookie- og samtykkeløsninger, der viser, hvad brugeren valgte, og hvilken version af banneret der blev vist.
Interne mails, chats og præsentationer om designvalg og resultater af test.
Udgivelseshistorik, der viser, hvornår en ændring gik i drift.

Det er ofte kombinationen, der giver svaret. Versionsstyringen viser, hvordan varianten var bygget. Konfigurationen viser, hvem der fik den. Analysedata viser, hvad de gjorde. → Logdata som bevis for aftaleindgåelse online

Kilder udefra

Den part, der ikke har adgang til virksomhedens systemer, må dokumentere udefra:

Skærmoptagelser af hele forløbet, ikke kun enkelte skærmbilleder, så antallet af trin og placeringen af valgmuligheder fremgår.
Gentagne optagelser fra forskellige enheder, browsere og lande, hvis varianter er mistænkt.
Sidens kildekode gemt sammen med optagelsen.
Arkiverede versioner fra et uafhængigt webarkiv, med de begrænsninger, de har ved dynamisk indhold. → Wayback Machine i retten: bevisværdi og indsigelser
Kvitteringer og mails, som brugeren modtog efter forløbet.

En skærmoptagelse bør starte, før forløbet begynder, og vise uret eller et andet uafhængigt tidspunkt. Den bør gemmes i den originale fil og sikres med en hashværdi. Notér browser, enhed, land og om brugeren var logget ind.

Effekten: hvad analysedata kan og ikke kan vise

Analysedata fra en A/B-test kan vise, at én variant fik flere brugere til at vælge et bestemt tilvalg end en anden. Det kan være et stærkt bevis for, at designet påvirkede valget. Men tallene skal læses med forsigtighed:

Analyseværktøjer registrerer ikke alle brugere. Brugere, der afviser cookies eller bruger blokering, kan mangle.
Grupperne i en test er ikke altid fordelt tilfældigt eller lige store.
En forskel i tal kan skyldes andre ændringer, der skete samtidig.
Dashboards viser ofte afrundede eller sammenfattede tal, som ikke kan efterprøves uden de underliggende data.

Bed derfor om de underliggende data og om en beskrivelse af, hvordan testen var sat op, og ikke kun om et skærmbillede af et dashboard. → Stikprøver i store datamængder

Spørgsmål til klienten

Er klienten forbrugeren eller en, der har set forløbet, bør advokaten tidligt spørge: Hvornår skete det, på hvilken enhed og i hvilken browser eller app? Var klienten logget ind? Har klienten gemt kvitteringer, mails eller egne skærmbilleder? Er forløbet stadig tilgængeligt, så det kan optages nu, og ligner det det, klienten husker?

At få virksomhedens data

Hvis klienten er forbrugeren eller en konkurrent, ligger de stærkeste kilder hos modparten. En begæring om edition bør beskrive kilderne konkret: designfiler for et bestemt forløb, konfiguration af en bestemt A/B-test, analysedata for en bestemt periode, og udgivelseshistorik for de relevante komponenter. “Al dokumentation om designet” er sjældent en brugbar formulering. → Editionsbegæring set fra IT-siden

Konfigurationen af A/B-test og feature flags ligger ofte hos en ekstern tjeneste og kan have begrænset historik. Det taler for at bede om bevarelse tidligt.

Når klienten er virksomheden

Når klienten er virksomheden bag løsningen, er opgaven at kunne vise, hvad brugerne faktisk så. Det kræver ofte, at en udvikler eller en sagkyndig genskaber forløbet fra versionsstyringen, som det var på det relevante tidspunkt. En sådan genskabelse bør dokumenteres omhyggeligt: hvilken version af koden, hvilken konfiguration og hvilke data der er brugt. Ellers vil modparten med rette kunne indvende, at genskabelsen viser i dag og ikke dengang.

Interne mails og præsentationer om designvalg vil ofte indgå i et editionskrav. Det er bedre, at advokaten kender dem først. → Skønsmandens adgang til systemer og data