Varför AI slår sönder pipelines för produktdesign (och hur teamen löser det)

Plattar dina AI-verktyg omärkligt till din produkts UX eller tjänstekvalitet? När du inför AI i produktarbetsflöden är den största risken inte att AI förstör din design. Risken är att den långsamt jämnar ut den.

Jag gav fyra ledande modeller ett exempel på Google Labs DESIGN.md och bad dem skapa en ”nästa”-pil i 44×44 och 88×88 px. Alla fyra följde varje token som specifikationen angav: färg, linjetjocklek, ändkappor, skarvar, arbetsyta, ingen fyllning. De var också överens om två saker som specifikationen aldrig nämnde – pilspetsens vinkel och hur linjeändarna skulle utformas.

Se DESIGN.md, formatet för designregler som Google har gjort tillgängligt som öppen källkod.

Det här är inget benchmarktest, men det visar ett problem: En specifikation kan vara tillräckligt komplett för att klara efterlevnadstester och ändå lämna luckor som modellen måste fylla i. Modellerna fyller dem med genomsnittet av allt de har tränats på.

Varför AI-driven UX-drift är svår att upptäcka

Ikonexperimentet var en del av mitt eget projekt, där jag testade att skapa och arbeta med eget UX-material. Jag satte upp strikta mål för UX och tjänstedesign som jag inte fick designa bort – på samma sätt som du inte kan designa bort en kunds kärnkrav. Med avsikt gav jag det ovanliga interaktionsmönster: tre överlappande navigationsmodeller, kontroller som bara visas efter specifika händelser och framåt- och bakåtbeteenden som ändras beroende på sammanhang – sådant som jag antar inte är väl representerat i träningsdatan.

Jag antog att de udda mönstren skulle vara svåra att bygga med AI. Det var de inte, men att behålla dem intakta var nästan omöjligt.

Under några veckor blev de ovanliga mönstren omärkligt mer konventionella. Formuleringar som jag hade valt av en anledning blev ”förbättrade” under en orelaterad buggfix. En kollega råkade ut för samma sak från andra hållet: när ett designsystem som tidigare fungerat tillämpades på nytt började det ge pixelavvikelser, märklig positionering och subtila förändringar i tonaliteten. 

Inget av detta syntes i testerna, eftersom inget var trasigt. Allt förflyttades några grader mot genomsnittet.

Mekanismen är inte mystisk. AI tränas på vanliga saker som finns i överflöd i träningsmaterialet. I tekniskt arbete är det oftast en fördel – men inom produktdesign är det nästan tvärtom. Det mesta som gör en produkt värd att investera i är just det som ännu inte är normalt och definitivt inte finns tillgängligt i stor skala i träningsdatan.

Varför mänsklig granskning inte upptäcker AI-drift

Här kommer den del jag helst inte skulle skriva. Det här hände inte bakom min rygg. Verktyget visade mig en diff för varje ändring och bad om tillåtelse. Jag läste dem. Jag godkände dem alla.

Det är värt att stanna upp vid, eftersom standardsvaret på allt ovan är ”inga problem, en människa granskar resultatet och tar ansvar”. Jag var människan, jag kände till mina mål, jag granskade – borde jag kanske avskeda mig själv från mitt testprojekt? Eller finns det andra sätt att se på saken?

En diff är ett utmärkt verktyg och förtjänar bättre än att få skulden här. Diff fungerar bäst när omfattningen av en ändring är snäv eller tydligt definierad: effekterna är oftast lokala, och de icke-lokala effekterna synliggörs genom en kodningskonvention eller ett test som fallerar. Dessutom är arbetsloopen kring kod och mjukvaruutveckling mycket tätt sammanhållen. Dessa faktorer förklarar varför utvecklare tog till sig AI-stöd så snabbt.

En ändring i ett produktantagande är inte lokal på det sättet. Ändra en mening högst upp i ett positioneringsdokument, så kan innebörden av allt nedanför förändras trots att texten är densamma. Ändra en regel i ett arbetsflöde för en tjänst, och konsekvensen visar sig tre steg senare – i någon annans kundresa. Vi saknar verktygen och konventionerna för att fånga den här typen av förändring när den görs av AI.

Så jag läste kanske inte slarvigt. Jag letade efter rätt sak, men i fel form. Jag läste orden och missade innebörden. Volymen gör resten. 

Vi har genomfört det här experimentet många gånger utanför AI, och vi vet hur det slutar. Tidiga virusskannrar meddelade allt de gjorde, eftersom användarna ”behövde veta att säkerhetsarbetet pågick”. I stället lärde sig användarna att reflexmässigt stänga dialogrutorna, även den udda dialogruta som faktiskt hade varit viktig. Webbannonsering lärde oss samma sak omvänt: placera något i form av en banner och människor slutar se det. Forskningen om mänskliga faktorer har sagt detta om automatisering i åratal – Parasuraman och Manzey fann att automatiseringsbias och överdriven tillit beror på personen, situationen och systemet, och att enbart instruktioner och utbildning inte tar bort dem. NIST:s vägledning om AI-risker uppmanar därför team att granska hur resultat *presenteras* och att ta in expertis inom mänskliga faktorer.

Källor:

Parasuraman & Manzey: Överdriven tillit och bias i människors användning av automatisering: en uppmärksamhetsintegrering

NIST:s vägledning om AI-risker

Inget av detta betyder att människor är slarviga eller att granskningen misslyckades och att de behöver utbildas på nytt. Uppgiften var i stället utformad för ett annat innehåll och en annan profession.

Hur designbyråer arbetar med AI

Mitt resultat är inte unikt. De stora designbyråerna har i stort sett slutat diskutera om generering är användbar inom produktdesign och för kunskapsarbetare. De har gått vidare till just detta nya område. Designit utvecklade Repsol, ett gemensamt ramverk för AI-upplevelser, med interaktionsprinciper omvandlade till återanvändbara människa–AI-mönster så att ”teamen inte längre behöver börja från noll”. frogs handbok för agentisk AI föreskriver skyddsräcken, verifieringspunkter, eskaleringsregler, agenter som har ”den minsta behörighet som krävs för att utföra jobbet” samt kontinuerlig snarare än engångsvis utvärdering. IDEO har publicerat The case against AI-generated users, som varnar för riskerna med att ytlig, generisk och känslolös ”data” tar sig in i kundförståelsen.

Så: koda in ditt sammanhang, styr loopen och sluta räkna prompts. Jag håller med dem, men jag ser ett perspektiv som saknas: det dagliga arbetet och de förändringar i arbetsflödet som krävs för att behålla den önskade riktningen.

Referenser: Designit byggde Repsol och frogs handbok för agentbaserad AI

Källor: IDEO: Argumenten mot AI-genererade användare

För designers: Dokumentera för AI vad som måste förbli oförändrat

Det användbara startpaketet är litet: design- och produktreglerna, inklusive var var och en *inte* gäller, bör alltid vara tillgängliga för agenten som arbetar med uppgiften. Antaganden bakom en användarresa bör kopplas till de skärmar och beteenden som är beroende av dem, tillsammans med exempel på godtagbara och oacceptabla resultat och allt det där som tidigare hamnade mellan simbanorna.

Det här är ingen uppgift för en enda prompt. En agent följer inaktuell intention med precis lika stort självförtroende som aktuell intention. En enda stor fil har fel form, eftersom varumärke, produktvision, tjänsteresor, innehåll och interaktionsmönster har olika ägare och förändras i olika takt. Att skicka med allt vid varje LLM-anrop kostar tokens och begraver instruktionen som faktiskt var viktig.

Jag experimenterar i stället med ett index – något som pekar agenten mot "widgets → buttons → switch" när det behövs, och inte tidigare. Strukturen är mindre viktig än principen: minsta möjliga relevanta intention, i samma ögonblick som den blir aktuell. Nackdelar? Detta måste underhållas, så du behöver involvera dig i arbetet i Confluence och Jira under planeringen och gå in i GitHub för att göra relevanta ändringar under utvecklingsfasen.

För chefer: Utforma människans arbete lika omsorgsfullt som prompten

Att dokumentera produktintentionen minskar avvikelser, och att följa upp effekten av intentionen hjälper till att hålla målen intakta. Men avvikelser kräver en granskningsyta som är anpassad för yrkesrollen som utför granskningen.

Designern behöver vara en del av produktteamet. De behöver se förändringar i den visuella modellen och tjänstemodellen i sitt eget sammanhang. Visa en tjänstedesigner vilket antagande som har ändrats och vilka användarresor som hänger på det. Visa en produktägare målet, underlaget och avvägningen.

Låt miljön själv upprätthålla de vanliga tekniska gränserna – att be en designer godkänna ett obekant shell-kommando gör inte designern till en säkerhetsgranskare. Det är brus som tröttar ut och distraherar. Att be en produktchef godkänna en textdiff innebär inte att de har godkänt ändringen i produkten.

Det här är ett gemensamt arbete för design-, utvecklings- och plattformsteam, och det kräver en sak av den som äger pipelinen: personer i andra roller än utvecklare behöver få tillgång till det verkliga AI-stödda arbetsflödet, inte bara dess slutresultat, och befogenhet att justera, stoppa eller avvisa det.

Välj ett arbetsflöde där människor ofta godkänner, återskapar eller reparerar AI-resultat. Fråga varje granskare vad de faktiskt behöver förstå för att kunna säga ja. Utforma granskningen utifrån svaret och mät om den fångar upp något.

AI kommer att fortsätta bli bättre på att producera arbetet. Att hålla varje rolls verktyg i takt med utvecklingen är inte ett problem för designers, utan för pipelinen. För att motverka AI-avvikelser behöver [Platform Engineering-team](https://www.eficode.com/software-tooling/platform-engineering) bygga granskningsytor som gör det möjligt för produktägare att se AI-förändringar i sitt sammanhang, inte bara i textdiffar.