- Barron Webster, mit mehr als 8 Jahren Erfahrung im Design von AI-Produkten, arbeitet bei Figma in der weltweit ersten Rolle eines „Model Designers“ – ein Zeichen für das Entstehen eines neuen hybriden Berufsbilds, in dem Designer direkt mit LLMs zusammenarbeiten
- Die Kernaufgabe eines Model Designers besteht darin, die Grenzen von Foundation Models auszugleichen und neue Tools und Denkweisen für das Design von AI-Funktionen in die Designorganisation einzuführen
- Anders als beim klassischen UI-Design muss beim Design von AI-Produkten zuerst das Verhalten des Modells prototypisiert und erst danach die UI gestaltet werden; andernfalls besteht das Risiko, eine UI zu entwerfen, die nicht zum tatsächlichen Verhalten passt
- Der Aufbau eines Evals-Systems ist zentral für die Qualitätssicherung von AI-Produkten; dafür werden Tools benötigt, mit denen Designer Evaluierungsfälle in einer schnellen Feedback-Schleife bearbeiten und ausführen können
- Im AI-Zeitalter müssen Designer die Ein- und Ausgabestruktur von Modellen tiefgehend verstehen und die Fähigkeit besitzen, das gesamte System zu überblicken; sie sollten nicht nur UI-Ersteller sein, sondern an Entscheidungen mitwirken
Einführung in Barron Webster
- Ein Designer, der seit über 8 Jahren intensiv an AI-Produkten beteiligt ist und über Einsichten verfügt, die den Hype-Zyklus durchschauen
- Beteiligte sich bei Google Creative Lab am 2017 veröffentlichten Teachable Machine, dem ersten Tool, mit dem Konsumenten AI-Modelle trainieren konnten
- Arbeitete anschließend bei Replit an AI-Funktionen und trug zum Wachstum des Startups bis zum Unicorn bei
- Trat kürzlich als weltweit erster Model Designer Figma bei
Die Rolle des Model Designers
- Gehört zum AI-Research-Team von Figma und erfüllt zwei Hauptaufgaben
- Lösungen für Situationen finden, in denen selbst die maximale Leistung aus Foundation Models nicht ausreicht
- Die Lücke überbrücken, weil Figmas Daten in proprietären Formaten vorliegen und daher von Foundation Models nicht gut verarbeitet werden
- Einführung von neuen Tools und einer AI-first-Denkweise in die Designorganisation
- Figma ist ein großes Unternehmen, und viele Designer haben keine Erfahrung im Entwurf von AI-Erlebnissen
- Das Design von AI-Funktionen unterscheidet sich von traditionellem Produktdesign
- Ziel ist es, Tools zu bauen, mit denen Designer früh im Prozess den Kern einer AI-Funktion prototypisieren können, ohne selbst zu Engineers werden zu müssen
- Wenn man die UI für eine Funktion entwirft, die man nicht direkt erlebt hat, besteht das Risiko, eine UI für einen perfekten Fall zu bauen, die nicht zum realen Verhalten passt
Die Zukunft von AI-Design-Tools
- Das Tool, auf das er sich am meisten freut, ist eines, mit dem Designer Evaluierungsfälle in einer schnellen Feedback-Schleife bearbeiten und ausführen können
- Wenn eine AI-Funktion in einer Figma-Datei nicht funktioniert, sollte sie sofort als Testfall hinzugefügt werden können
- Anpassungen am System Prompt oder das Ausprobieren anderer Modelle sollten direkt möglich sein
- Das Problem heute ist, dass die Feedback-Schleife zu langsam ist
- Der Kern aller guten Design-Tools ist das Entfernen oder Verkürzen der Feedback-Schleife
- Ein großer Teil der Arbeit beim Aufbau von Evaluierungs-Sets besteht aus manueller Datenbereinigung
- Er denkt auch darüber nach, wie sich AI-Funktionen in Figma differenzieren lassen
- Da es sich um eine Designplattform handelt, werden besser gestaltete Outputs erwartet als bei Claude Code oder Cursor
- Entscheidend sind gezielte Evaluierungsstrategien und das Finden eines Proxy für gutes Design
- Das ist zugleich eine philosophische Frage auf Kunsthochschul-Niveau
Barrons Einstieg in AI
- RISD-Kurs Computer Utopias 2014–2015: eine Zeit vor LLMs, als sich die Machine-Learning-Forschung auf Klassifikatoren konzentrierte
- Bildklassifikationsmodelle waren am spannendsten und trieben Snapchat-Gesichtsfilter oder die Google-Bildersuche an
- Content Moderation und Empfehlungssysteme waren zentrale Themen
- In der Hochphase von Facebook, Twitter und Cambridge Analytica schuf die Erfindung des algorithmischen Feeds neues Material für Design
- Google Creative Lab 2016–2018: Arbeit an Google Lens, Google Assistant und Teachable Machine
- Fast jedes Projekt setzte Modellinnovationen ein
- Modelle wurden nicht zur Textgenerierung, sondern zum Sortieren oder Annotieren bestehender Inhalte genutzt
- Er bewarb den Fall eines japanischen Gurkenbauern, der TensorFlow zur Klassifikation von Gurken nutzte
Erfahrungen bei Replit
- Arbeitete mehr als 3 Jahre dort und begann zu einer Zeit, als es noch keinerlei AI-Funktionen gab; seine Rolle bestand darin, Einsatzmöglichkeiten für AI zu bewerten
- Mit der fortlaufenden Verbesserung der Modelle suchte er nach Wegen, neue Fähigkeiten zu nutzen und zugleich verlässliche AI-Funktionen hinzuzufügen
- Beginn mit einfachen manuell ausgelösten Funktionen, etwa AI-Erklärungen für ausgewählten Code oder Codegenerierung in bestehende Dateien
- Nach jedem Feature-Launch wiederholte sich ein Zyklus steigender Nutzererwartungen
- Wenn Code-Snippets generiert werden konnten → Wunsch nach ganzen Dateien/Projekten
- Wenn vollständige Generierung möglich war → Wunsch nach gezielten Bearbeitungen
- Wenn gezielte Bearbeitungen möglich waren → Wunsch nach komplettem Neubeginn
- Typisches Muster: Mit dem bestehenden Modell ein Feature versuchen → wenn es nicht klappt, warten → mit neuem Foundation Model erneut versuchen
- Produktbeschränkungen in Programmierumgebungen
- Auch wenn ein Modell gut Code schreiben kann, braucht es einen Weg, an der richtigen Stelle zu editieren
- Bis Sonnet 3.5 waren Modelle schwach im Umgang mit Zeilennummern
- Für Bearbeitungsgenauigkeit, Vermeidung von Duplikaten und Funktionsersetzung waren Workarounds nötig
- Vieles davon wurde 6 bis 12 Monate später durch neue Modelle wieder obsolet
Ein Beispiel für den Wechsel zur Nutzerverifikation
- Wenn der Replit-Agent automatisch Dateien erstellt und Code schreibt, war das Testen der vom Agenten gebauten Anwendung ein großes technisches Problem
- Beispiel: Prüfen, ob eine Login-Seite funktioniert
- Der Engineering-Ansatz: Sandbox starten, Screenshot-Funktion bauen, Screenshots an ein multimodales Modell geben, damit es entscheidet, wo geklickt oder etwas eingegeben werden soll
- Im Kern eine Umsetzung von quasi-computer use durch das Modell
- Vorschlag von Barron und einem weiteren Engineer: Dem Nutzer die Website zeigen und ihn bitten, sie selbst zu testen
- Dadurch wurde Verifikation und Testing auf den Nutzer ausgelagert und das komplexe technische Problem als Ganzes umgangen
- Wenn jemand nicht auf das technische Problem, sondern auf das Nutzerproblem fokussiert ist, lässt sich vieles überspringen oder vereinfachen
Product-Market-Fit finden
- Traditionelle Produktstrategie vor AI: Planung erstellen, bestehende Nutzerbasis verstehen, Strategie zur Erweiterung von Markt/Kategorie aufsetzen
- Durch den schnellen Wandel in AI war Replits Strategie viel reaktiver
- Starkes Product-Market-Fit im Bildungsmarkt, insbesondere nach COVID und dem Übergang zu Remote Education
- Mit besseren AI-Funktionen entstand ein Dilemma
- Indie-Entwickler und Hacker mochten AI
- Lehrkräfte lehnten sie ab, weil Studierende damit Grundlagenlernen umgehen konnten
- Als der Replit-Agent veröffentlicht wurde, war die Zielgruppe unklar
- Erfolgreicher als Top-down-Projekte war es, Funktionen zu veröffentlichen und dann die Reaktionen zu beobachten
- Durch Gespräche nach dem Launch wurden neue Nutzer entdeckt: Operations-Verantwortliche in Tech-Unternehmen, die Vertriebsdaten sammeln oder Dashboards bauen mussten, ähnlich wie Nutzer von Zapier oder Retool
Das Evals-System
- In den ersten zwei Jahren bei Replit wurde wenig evaluiert, weil diese Praxis damals noch nicht weit verbreitet war
- Beim Agenten wurden Evaluierungen aktiver eingesetzt, vor allem als Metrik für die Produktentwicklung
- Wenn ein neues Modell erschien, wurde anhand seiner Performance in Programmier-Evals entschieden, ob App-Testing versucht werden sollte
- Bei Sandbar wurde viel Zeit in Evaluierungen zur Modellpersönlichkeit investiert
- Neben branchenweiten Benchmark-Evals ist der Aufbau produktspezifischer Evaluierungen eine neue Form von Designarbeit
- Workflow: Prompt schreiben → Prompt anpassen → Eval erzeugen → Leistung prüfen → mit manuellem Testen und subjektivem Feedback kombinieren
- Ohne Evals steigt die manuelle Arbeit zur Verifikation der AI-Funktionalität massiv an
- Beispiele für Sandbar-Evals
- Wenn das Modell die Antwort nicht kennt, soll es statt zu halluzinieren eine einzelne, konkrete Klärungsfrage stellen
- Es darf nicht mehr als zwei Fragen auf einmal stellen
- Antworten sollen knapp bleiben, mit Ausnahmen
Schwierigkeiten bei Evaluierungen
- Sycophancy ist eines der schwierigsten Themen beim Schreiben von Evaluierungen
- Gemeint ist die Frage, wann ein Modell dem Nutzer widersprechen sollte
- Die Entscheidung über eine akzeptable Fehlerrate wird zur Produkt- und Designentscheidung und damit Teil der Designphilosophie des Produkts
- Oft liegt eine schlechte Eval-Performance nicht an nachlassender Leistung, sondern an schlecht geschriebenen Evaluierungen
- Beispiel: In einer Eval für „sehr knapp“ würde auf „Meine Mutter ist gestorben“ die Antwort „Das tut mir leid“ hoch bewertet, obwohl das nicht die tatsächlich gewünschte Antwort ist
- Evals dienen hauptsächlich der Vermeidung von Regressionen und der Prüfung, ob Eigenschaften erfüllt sind
- Ähnlich wie Test-Coverage in der Programmierung
- Etwas wie Test-driven Development (TDD) aus der klassischen Programmierung ist im AI-Engineering noch selten
- Also erst Evals schreiben und dann Code, der diese Evals besteht
- Ein möglicher künftiger Beruf: Eval Designer
- Ähnlich wie Design-System-Arbeit, nur für Dashboards, mit denen Teams die AI-Leistung verstehen können
Ideen für AI-Funktionen bei Figma
- Er denkt über die Idee „Designkritik als Service“ nach
- Nutzer würden AI um Designkritik bitten
- Das wirft interessante Fragen über die Persönlichkeit eines solchen Systems auf
- Soll es wählbare Haltungen geben, etwa im Stil von „Dieter Rams“, oder einen Standard?
- Sollte der Fokus auf Barrierefreiheit oder Kontrastproblemen liegen, also objektiverem Feedback, oder breiter gefasst sein?
- Wie stark sich das im realen Produkterlebnis niederschlägt, ist noch offen
Wohin sich Eval-Tools entwickeln sollten
- Gewünscht sind Tools, die die Iterationszeit bei der Erstellung von Evaluierungen verkürzen
- Dinge, die heute praktisch jeder bei Eval-Arbeit selbst erledigen muss
- Mapping, Formatierung, Pipelines und eine Oberfläche, in der Outputs an einem Ort sichtbar sind
- Für Text sind die Tools schon recht gut, für andere Formate aber unzureichend
- Es gibt ähnliche Eval-Plattformen wie Design Arena
- Dort stimmen Menschen in einem blinden Side-by-Side-Test über den besten gewünschten Output ab
- Er würde so etwas gern direkt in Figma-Dateien tun
- Einschließlich Kommentieren und Markieren von Problemen
- Testsets sollten schnell erstellt, auf einmal ausgeführt und 100 Antworten in unter 30 Sekunden iteriert werden können
- Heute funktionieren zwar alle Einzelteile, aber es dauert noch viel zu lange
Die Rolle von Designern bei der Modellerzeugung
- Er hat beide Wege erlebt: Training von Grund auf und Fine-Tuning
- Beim Training von Grund auf: Der größte Beitrag von Designern besteht darin, der Organisation mitzuteilen, wo Nutzerbedürfnisse und Pain Points am größten sind
- Bei Replit wurde ein Custom Model für häufige, einfache Python-Fehler trainiert
- Er war stärker an Problemdefinition und daran beteiligt, wie das trainierte Modell im Produkt eingesetzt wird, als am eigentlichen Training
- Beim Fine-Tuning: Es gibt bereits bestehende Modelle, Produkte und Evals, und man möchte die Leistung verbessern
- Wer Prompts schreibt, Evals erstellt und mit Nutzern spricht, weiß besonders klar, ob Erwartungen erfüllt werden
- Wenn Prompt Engineering an seine Grenzen stößt, ist Fine-Tuning der nächste Schritt
- Die zentrale Übersetzungsrolle von Designern: Nutzerannahmen im Gedächtnis behalten
- Engineers und Designer, die eng mit Modellen arbeiten, vergessen leicht, dass Nutzer die Details nicht kennen
- Man muss den „inneren Idioten“ nutzen, um zu vermitteln, was naive Nutzer ohne Wissen über AI-Modelle ausprobieren würden und wo sie hängen bleiben
Ratschläge für AI-Produktdesigner
- Das Nachhaltigste und Wirkungsvollste ist, früh viel Zeit zu investieren, um die Ein- und Ausgaben des Modells wirklich zu verstehen
- Was ist der Prompt, welche Nutzerinformationen gehen ein, welche Tools kann das Modell aufrufen, welche Evals gibt es
- Ein intuitives Gefühl dafür entwickeln, was passiert, wenn man an diesen Stellschrauben dreht
- Man sollte nicht zum UI-Gestalter für Outputs werden, die man nicht tief versteht
- Wenn es heißt „Das Modell liefert das hier, entwirf dafür eine Oberfläche“, kann man das zwar tun, aber keine Verbesserungen aus Nutzerperspektive vorschlagen
- Man arbeitet dann sehr reaktiv auf nachfolgende Modelländerungen
- Man sollte Teil der Entscheidungsfindung darüber sein, ob eine neue Funktion überhaupt wünschenswert ist, statt nur Empfänger zu sein
- Für Designer ohne Code-Erfahrung kann das schwierig sein
- Dann braucht es Interfaces wie Langsmith oder die Fähigkeit, Entwicklungsumgebungen direkt auszuführen
Fälle mit dem größten Einfluss
- Replit Agent: Er überzeugte das Team, Nutzer direkt prüfen zu lassen, ob die generierte Anwendung funktioniert
- Durch die Konzentration auf den einfachsten Weg der Nutzerverifikation konnte viel Aufwand gespart werden
- LaMDA-Launch (Googles frühes LLM): Er investierte viel Zeit darin, das Modell auf verschiedene Arten auszuprobieren und zu sehen, was am besten funktionierte
- Damals nannte man es noch nicht „Prompting“, aber man versuchte, das Modell glaubwürdig verschiedene Rollen spielen zu lassen
- Die Demo, in der man mit Pluto oder seinen Monden sprechen konnte, war das Ergebnis unzähliger Versuche, um die am besten funktionierende Variante zu finden
- Ohne breit angelegte Experimente hätte man keine strategische Auswahl treffen können
Prompting durch Designer
- Die Frage „Sollten Designer prompten?“ ist anders gelagert als „Sollten Designer coden?“
- Beim Coden ist die Antwort recht gut widerlegbar: Kann man mit Technik ABC XYZ bauen? Jemanden aus dem Engineering zu fragen, ist fast gleichwertig mit eigenem Wissen
- Das Verhalten von AI-Modellen ist inhärent subjektiver und nuancierter
- Es gibt keinen Ersatz dafür, dieses Material auf tiefer Ebene selbst zu verstehen
Ist das noch Design?
- Es ist das Design von Verhalten, und es muss nicht perfekt werden – das ist in Ordnung
- Das erfordert ein anderes Mindset als UI-Design, bei dem man jedes Pixel vollständig kontrolliert und Perfektion belohnt wird
- Es gibt weiterhin Mockups und die Nutzung von Design-Tools
- Bei Figma erstellt er Eval-Fälle, überprüft Outputs und korrigiert unbeholfene Stellen
- Es wirkt fast therapeutisch, wie ein Fidget Spinner
- Gibt man ihm ein Website-Mockup und 30 Minuten Zeit, ist er glücklich damit, Typografie zu überarbeiten
- Es ist eine Art von Arbeit, die nie wirklich endet, solange die Funktion nicht entfernt wird; Verbesserungen sind immer möglich
Noch keine Kommentare.