intervjuer
Chris Strahl, grunnlegger og administrerende direktør i Knapsack – intervjuserie

Chris Strahl er medgründer og administrerende direktør i Knapsack, hvor han fokuserer på å omforme hvordan moderne digitale produkter bygges ved å samordne design-, ingeniør- og produktteam rundt et felles sannhetssystem. Med en bakgrunn forankret i designsystemer og frontend-utvikling, er han også viden kjent for å være vert for Designsystemer Podcast, hvor han utforsker hvordan organisasjoner skalerer design, forbedrer samarbeid og moderniserer digital produksjon.
Knapsack er et designsystem for bedrifter og en digital produksjonsplattform som fungerer som et levende system for registrering, og kobler sammen designressurser, kode, innhold og dokumentasjon i sanntid. Plattformen lar team bygge og styre gjenbrukbare, produksjonsklare komponenter, administrere designtokener og opprettholde konsistens på tvers av komplekse digitale økosystemer. Ved å strukturere design- og brukergrensesnittdata på en måte som er skalerbar og AI-klar, hjelper Knapsack store organisasjoner med å akselerere levering, redusere duplisering og sikre merkevare- og produktintegritet på tvers av team og kanaler.
Knapsack oppsto etter å ha brukt år på å bygge designsystemer for store bedrifter hos Basalt, hvor gjentakende friksjon mellom designfiler, ingeniørarbeidsflyter og levert kode ble umulig å ignorere. Når ble dette mønsteret tydelig nok til å rettferdiggjøre lanseringen av en dedikert plattform?
Vi bygde utallige designsystemer hos Basalt, og mønsteret var tydelig: designfiler, ingeniørarbeidsflyter og levert kode eksisterte alle i separate universer. Resultatet var ikke én dramatisk feil, men tusen repeterbare tap: feil størrelse på knapper, inkonsekvent oppførsel og stilavvik på tvers av egenskaper som kostet team måneder med omarbeiding. Vi visste at det var et reelt problem da vi så at disse problemene ikke kunne løses med bedre synkroniseringsplugger eller penere dokumentasjon. De krevde et enkelt autoritativt system for registrering av design, kode og merkevareregler. Denne erkjennelsen gjorde det klart at en dedikert plattform var nødvendig.
Å gå fra byrå- og konsulentarbeid til å bygge et produktselskap avdekket et dypere problem som eksisterende designverktøy og arbeidsflytplattformer ikke adresserte. Hva var det grunnleggende gapet som formet Knapsacks tidligste arkitektur og retning?
Da vi gikk over fra byråarbeid til å bygge et produkt, ble den manglende kjernen åpenbar. Det fantes ikke noe pålitelig, maskinlesbart system som fanget opp komponenter, begrensninger og synergien mellom designere og ingeniører. Eksisterende verktøy fokuserte på filer eller isolerte databaser, men ikke på en levende representasjon av et produkts sanne tilstand, inkludert komponenter, temaer, bruksregler og samsvarsmetadata. Vi bygde Knapsack rundt et kanonisk registreringssystem som er komponentorientert, versjonert, instrumenterbart og i stand til å integreres med både designverktøy og kodebaser. Denne konklusjonen formet vår inntaksmodell og koblingslaget, noe som til slutt førte til den intelligente produktmotoren.
«Lerretsæraen» viker plass for levende, kodekoblede systemer. Hvordan definerer du dette skiftet, og hva endrer seg for team når produktutvikling går fra statiske filer til kontinuerlig oppdaterte systemer?
Canvas-æraen behandlet brukeropplevelse som statiske artefakter, vanligvis filer som sendes mellom team. Den nye æraen er drevet av kontinuerlig oppdaterte, kjørbare systemer som gjenspeiler reell implementering. Endringen for team er betydelig. I stedet for å diskutere hvilken fil eller gren som er kilden til sannheten, jobber de fra et delt system som eksponerer den nåværende tilstanden til komponenter, tokener, tilgjengelighetsbegrensninger og produksjonsatferd. Dette reduserer tvetydighet, muliggjør automatisert validering og støtter agentiske arbeidsflyter som genererer brukbart brukergrensesnitt basert på reelle komponenter i stedet for tilnærminger.
Agentgenerert brukergrensesnitt mislykkes ofte uten et registreringssystem som gjenspeiler reelle komponenter, regler og begrensninger. Hvorfor er dette forankringslaget viktig for at AI skal kunne produsere bedriftsklare grensesnitt?
AI kan syntetisere layouter og tekst, men den trenger et autoritativt vokabular for å produsere bedriftsklare grensesnitt. Forankringslaget, som inneholder konkrete komponenter, rekvisitter, begrensninger, tokens og bruksregler, gir AI grensene den må respektere. Uten det hallusinerer agenter stiler, ignorerer tilgjengelighetskrav eller genererer kode som ikke samsvarer med det ingeniørteamene faktisk leverer. Med en ekte komponentgraf og et regelsett produserer agenter resultater som er implementerbare, kompatible og i samsvar med merkevarestandarder. Dette er forskjellen mellom en pen mockup og et distribuerbart grensesnitt.
Etter hvert som den intelligente produktmotoren utviklet seg, hva viste seg å være det vanskeligste med å forene designressurser, kode, merkevareregler, samsvarskrav, UX-mønstre og ytelsesdata til ett sammenhengende system?
Utfordringen er ikke én enkelt integrasjon, men snarere en serie av dem. Den harmoniserer intensjon og virkelighet på tvers av ulike representasjoner, inkludert designtokens i Figma, komponentimplementeringer i flere repositorier, merkevareretningslinjer i juridiske dokumenter, telemetri fra produksjonssystemer og samsvarsmetadata. Hver av disse finnes i forskjellige formater, med forskjellige eiere og på forskjellige oppdateringssykluser. Å gjøre disse signalene om til én konsistent modell krevde sterke inntaksrørledninger, konfliktløsningsregler og en tydelig modell for opprinnelse og eierskap. Teamene må vite hva som ble endret, hvem som gjorde endringen og hvorfor den ble gjort. Å bygge det tillitslaget var den vanskeligste delen.
Med AI som nå er i stand til å generere stadig mer komplette grensesnitt, hvordan ser du for deg at rollene til designere og ingeniører utvikler seg i arbeidsflyter mellom mennesker og agenter?
Agenter vil håndtere repeterende oppgaver, som å sette opp sider, foreslå tilgjengelige varianter og generere lokalisert innhold. Designere vil fokusere på strategi, opplevelsesintensjon, brukeropplevelse i utkanten av prosessen og definere begrensningene som driver gode resultater. Ingeniører vil fokusere mindre på å skrive ut hver piksel og mer på komponentkorrekthet, kjøretidskontrakter, observerbarhet og ytelse. Mennesker blir kuratorer og validatorer. Vi definerer reglene, gjennomgår resultater og bestemmer hvordan kvalitet ser ut. De menneskelige ferdighetene med høyest verdi vil være systemtenkning og dømmekraft.
Etter serie A, hva ble de høyest prioriterte fokusområdene for å akselerere produktutvikling og bedriftsadopsjon?
Serie A tillot oss å akselerere på tre områder. For det første, onboarding og inntak, som gjør det mulig for bedrifter å opprette et registreringssystem på dager i stedet for måneder. For det andre, Intelligent Product Engine, inkludert modelljusterte funksjoner som sikrer at genererte grensesnitt respekterer merkevare og regler. For det tredje, bedriftskontroller, som tillatelser, revisjonsmulighet og samsvarsmekanismer, sikrer at ledere føler seg trygge på å ta i bruk Knapsack på tvers av store organisasjoner. Dette er mekanismene som driver implementering i reell skala.
Bedriftsteam sliter ofte med å gå fra statiske arbeidsflyter til dynamiske, agentklare systemer. Hva er de største hindringene, og hvordan hjelper Knapsack organisasjoner med å tilpasse seg?
Bedrifter sliter med fragmenterte systemer, eierskapssiloer, regulatoriske begrensninger og de høye kostnadene ved å holde alt oppdatert. Vi hjelper ved å gjøre inntak raskt og deterministisk, ved å modellere opprinnelse og eierskap, og ved å tilby styringsfunksjoner som tillatelser og revisjonslogger. Disse verktøyene gjør det mulig for team å validere tillit til automatiserte arbeidsflyter.
Etter hvert som produktutvikling blir stadig mer automatisert, hvilke nye funksjoner tror du team må utvikle for å forbli effektive i et miljø der AI genererer mer av det grunnleggende arbeidet?
Team må utvikle sterkere systemtenkningsferdigheter, spesielt evnen til å utforme begrensninger, retningslinjer og komponentkontrakter som agenter kan bruke. De trenger også bedre overvåkings- og valideringspraksiser, inkludert observerbarhet i agentbeslutninger, utrullingskontroller og rammeverk for spørsmål og svar for generert brukergrensesnitt. Styringskompetanse blir viktig, spesielt evnen til å uttrykke samsvar, tilgjengelighet og personvernkrav i et maskinlesbart format. Organisasjonene som lykkes, vil være de som kan kodifisere retningslinjer og kvalitet i systemene sine.
Hvordan forventer du at AI-drevet produktutvikling vil utvikle seg fem år fremover, og hvilken posisjon ønsker du at Knapsack skal ha i den neste fasen av bransjen?
Om fem år vil produktutvikling ligne på å sette sammen tjenester mot en live komponentgraf, i stedet for å sende statiske sammenligninger mellom team. Agentiske verktøy vil generere produksjonsklare overflater ved hjelp av policyer, ytelsesbudsjetter og merkevarebegrensninger. Målet mitt er at Knapsack skal være det kanoniske registreringssystemet som agenter og apper er avhengige av for å forstå et selskaps sanne brukergrensesnittprimitiver og regler. Dette inkluderer dyp integrasjon med modeller og CI/CD, sterk styring for regulerte virksomheter og rask onboarding for nye team. Knapsack bør være det pålitelige laget for merkevare, atferd og sikkerhet ettersom selskaper lar agenter operere mer autonomt.
Takk for det flotte intervjuet. Lesere som ønsker å lære mer om moderne designsystemer og skalerbar digital produksjon bør besøke Knapsack.












