Die 3 Ebenen des KI-Designs... Nur wenige erreichen Ebene 2

AAI LABS
Computing/SoftwarePhotography/Art

Transcript

00:00:00Wenn du diesen Kanal schon länger verfolgst, weißt du wahrscheinlich, dass wir bereits viele
00:00:03Design-Workflows und Tools getestet haben. Wir haben sie monatelang auf Herz und Nieren geprüft und schließlich herausgefunden,
00:00:08warum dasselbe Modell manchmal etwas völlig Maßgeschneidertes liefert oder etwas, das sofort
00:00:13nach KI aussieht. Das Ganze lässt sich auf drei Ebenen herunterbrechen. Stufe eins ist das Design einer einzelnen Seite,
00:00:19und es gibt eine Sache, die die meisten auslassen – genau das ist der Grund, warum ihr Ergebnis so generisch wirkt. Stufe
00:00:23zwei ist der Punkt, an dem man aufhört, nur Seiten zu gestalten, und anfängt, Systeme zu entwerfen – und der Workflow hierbei ist
00:00:28völlig anders. Und Stufe drei zeigt, wie wir Designs gegeneinander testen, um die Version zu finden,
00:00:34die tatsächlich funktioniert. Das ist die Methode, die wir mittlerweile bei jedem echten Projekt anwenden. In Stufe eins geht es also darum,
00:00:39ein gutes Design für eine einzelne Seite zu erstellen. Das ist das Level, das die meisten unterrichten, weil es das
00:00:44Fundament jedes guten Designs bildet. In unserem vorherigen Video haben wir darüber gesprochen, wie stark sich Opus 4.7 bei
00:00:50Designfähigkeiten verbessert hat und dass ein Großteil des früheren KI-Schrotts verschwunden ist. Wenn wir ihm früher
00:00:55einen einfachen Befehl wie das Erstellen einer Landingpage gaben, hat es einfach starr das
00:00:59lila-weiße Schema übernommen und alles darum herum aufgebaut. Dieses spezifische Muster hat sich zwar gebessert,
00:01:04aber genau wie jedes andere KI-Modell neigt auch dieses zu sicheren Mustern. Nach all unseren Tests und
00:01:09Experimenten haben wir festgestellt, dass es standardmäßig jedes Mal auf einen bestimmten Stil zurückgreift. Wenn wir also
00:01:15jetzt diesen Stil sehen, ist das ein untrügliches Zeichen dafür, dass die Website von Opus 4.7 stammt, und es ist nur eine Frage der Zeit,
00:01:21bis das der nächste KI-Einheitsbrei wird. Wir brauchen also andere Wege, um diese Website aufzuwerten.
00:01:25Diese Stufe hängt hauptsächlich vom Prompt-Engineering ab und davon, wie wir die App spezifizieren, denn
00:01:30wenn man den Prompt richtig strukturiert, kann man die App im Grunde beim ersten Versuch erstellen. Der Prompt sollte
00:01:35mit der Absicht der Website beginnen, die du erstellen möchtest, gefolgt von den unumstößlichen Anforderungen – wie den
00:01:39genauen Dingen, die in der App sein sollen und wie die UI-Elemente aussehen sollen. Danach legst du das
00:01:44Farbsystem fest. Hierbei verwenden wir OKLCH, was im Grunde ein Maß für Helligkeit, Chroma und Farbton ist.
00:01:49Die Verwendung von OKLCH anstelle des üblichen RGB oder HSL ist besser, weil es Farben so darstellt, wie das
00:01:55menschliche Auge sie tatsächlich wahrnimmt, wodurch Helligkeit und Balance besser gehandhabt werden. Außerdem entstehen
00:01:59dadurch flüßigere Farbverläufe, im Gegensatz zu Hex-Codes, die manchmal ungleichmäßig wirken können. Sobald du das
00:02:04Farbschema festgelegt hast, musst du auch die Kontrastverläufe erwähnen. Kontrast ist ein sehr wichtiger
00:02:08Faktor im UI-Design, da er eine Hierarchie schafft, die den Blick gezielt auf das lenkt,
00:02:13was wichtig ist. Ohne explizite Kontraste behandelt das Modell jedes Element als gleich wichtig,
00:02:18wodurch es schwierig wird, eine visuelle Hierarchie aufzubauen. Und um sicherzustellen, dass die Website nicht nach
00:02:22KI-Schrott aussieht, musst du auch die Typografie über den Prompt steuern. Du definierst also, welche Schriften
00:02:27wegen des KI-Einheitslooks tabu sind und welche in verschiedenen Bereichen des Designs verwendet werden sollen. Schriften wie Inter und Geist
00:02:33sind inzwischen typische Erkennungsmerkmale für KI-Einheitsbrei, weil jeder Agent standardmäßig danach greift. Wenn man sie also
00:02:38explizit ausschließt, zwingt das das Modell, sich woanders umzusehen. Danach definierst du das Layout und den Rhythmus der Website,
00:02:42aber zuerst musst du den Unterschied zwischen Symmetrie und Asymmetrie kennen. Symmetrische Layouts haben Komponenten,
00:02:47die gleichmäßig auf dem Raster platziert sind, was einen ausgewogenen Look ergibt und sich besser für professionelle und
00:02:51geradlinige Designs eignet. Für einen künstlerischeren Look solltest du jedoch zu Asymmetrie greifen, da dir das mehr Freiraum
00:02:56zum Experimentieren gibt. Das eignet sich besonders gut, wenn du mit Negativraum arbeiten musst, damit das Design
00:03:01atmen kann. Die Art des Produkts, das du baust, entscheidet, welcher Ansatz besser passt. Definiere dann alle gewünschten
00:03:06Abschnitte, die Materialien, die du verwenden wirst, und wie sich die Website responsive verhalten soll. Das Wichtigste
00:03:11dabei ist die Erwähnung der Anti-Muster. Das sind die typischen Merkmale von KI-Schrott, wie der einfache zentrierte Call-to-Action,
00:03:17Lucid-Icons und Farbverläufe mit Glassmorphismus-Design. Sobald du diesen Prompt an Claude Code oder
00:03:22welchen Agenten du auch immer verwendest, übergibst, analysiert er deine App und geht die Implementierungsdetails durch. Anschließend
00:03:27wird er die App genau wie im Prompt beschrieben bauen – mit Asymmetrie aufgrund des künstlerischen Ziels und einer sinnvollen Nutzung des Negativraums.
00:03:34In Stufe 2 geht es also darum, dasselbe Design auf jeder Seite der Website beizubehalten, denn die meisten von Agenten generierten Apps
00:03:40fallen in sich zusammen, sobald man die Landingpage verlässt. Wenn man ganze Apps mit Agenten generiert, ist man
00:03:45wahrscheinlich genau darauf gestoßen. Die Landingpage ist meistens ziemlich gut, aber wenn man zu den anderen Seiten wechselt,
00:03:50folgen sie dem UI-Stil nicht mehr so stimmig, wie sie sollten. Das Dashboard hat plötzlich andere
00:03:55Button-Stile, andere Abstände, eine andere Typografie – fast so, als hätte der Agent vergessen, dass er dieselbe
00:04:00App baut. Die anderen Seiten sehen am Ende so aus, als würden sie gar nicht zur selben Website gehören, und das verrät
00:04:05sofort, dass die Seite von einem Agenten generiert wurde. Manchmal hält das Design noch auf den Authentifizierungsseiten, aber auf
00:04:10dem Dashboard bricht der Stil dann komplett ein. Dafür musst du also die zwei wichtigsten
00:04:15Dateien erstellen: Claude.md und Design.md. Diese beiden Dateien sorgen dafür, dass das Design auf der gesamten Website konsistent bleibt.
00:04:21In Claude.md schreibst du, wie wir schon oft erwähnt haben, nur deine Projektinformationen, nicht das Design.
00:04:27Das liegt daran, dass diese Datei während der gesamten Session geladen bleibt und Designdetails darin den Agenten nur
00:04:32ablenken würden, wenn er an etwas anderem arbeitet. Dennoch ist sie die Schlüsseldatei, weil sie
00:04:37den Projektkontext bewahrt, der wiederum ein gutes Design unterstützt. Für das Design selbst benötigen wir eine separate Datei,
00:04:42die alles für das visuelle System, das Layout, die Farben, die Typografie und alle Details enthält,
00:04:47die wir in Stufe 1 behandelt haben. Die design.md sollte so beschaffen sein, dass jeder Agent sie übernehmen und
00:04:52sofort verstehen kann, wie das visuelle System aufgebaut ist. Und genau wie auf der vorherigen Stufe musst du
00:04:57das Farbsystem auch hier in OKLCH definieren. Um diese beiden Dateien zu erstellen, haben wir Claude Code einen detaillierten
00:05:03Prompt gegeben, der abdeckt, was jede Datei benötigt, und er hat beide Dateien für uns generiert. Die Claude.md ist kurz und
00:05:09enthält nur die Projektdetails. Die design.md ist länger und enthält jedes einzelne Detail, einschließlich Farbcode,
00:05:15Typografie-Entscheidungen und vielem mehr. Aber damit ist die Arbeit an der design.md noch nicht getan. Wir müssen sie
00:05:20mit der Zeit kontinuierlich verfeinern. Deshalb fügen wir ganz an den Anfang eine Zeile ein, die den Agenten anweist, jeden neuen Designwert,
00:05:25den er findet, in diese Datei einzutragen. Auf diese Weise beginnt jede Session mit einer verfeinerten Version des Designsystems
00:05:30als die vorherige. Aber Claude einfach nur die design.md erstellen zu lassen, reicht nicht aus,
00:05:35denn das, was er generiert, folgt nicht immer perfekt den Best Practices. Google hat seine Vorlage
00:05:40für die design.md-Datei als Open Source veröffentlicht. Diese Vorlage enthält auch Befehle, mit denen du deine design.md
00:05:46dagegen gegenchecken und eventuelle Fehler markieren lassen kannst. Du kannst deinen Agenten also einfach auffordern, mithilfe dieser Befehle
00:05:51iterativ vorzugehen, um die design.md zu perfektionieren. Und selbst damit ist Stufe 2 noch nicht abgeschlossen. Um Designs zu generieren, die auf diesem Niveau gut genug sind,
00:05:56musst du sie auch anhand bestehender Designprinzipien überprüfen. Dafür gibt es
00:06:00viele Open-Source-Skills, die genau das tun. Du kannst jeden davon verwenden, aber wir nutzen den Skill von VersaLab,
00:06:06weil er, anstatt alle Prinzipien fest im Skill zu codieren, auf eine externe Quelle verweist,
00:06:11die aktiv gepflegt wird. So bleiben die Prinzipien stets auf dem neuesten Stand der Best Practices,
00:06:16anstatt auf dem Stand eingefroren zu sein, der beim ersten Schreiben des Skills modern war. Du installierst diesen Skill
00:06:21im Projekt, führst ihn aus, und dein Design präsentiert sich in einer weitaus besseren Verfassung als zuvor. Aber bevor wir
00:06:25fortfahren, hören wir ein Wort von unserem Sponsor. Ich habe vor Kurzem ZillysCloud verwendet, und ich erzähle dir mal,
00:06:30warum. Die meisten RAG-Anwendungen funktionieren mit einer Handvoll Dokumenten problemlos, aber sobald man echte Daten einbindet,
00:06:35fangen sie an zu versagen, weil das Setup einfach nicht für diese Art von Last ausgelegt war.
00:06:40Milvus ist die meistgeclusterte Open-Source-Vektordatenbank auf GitHub mit über 44.000 Sternen,
00:06:46und sie ist genau für diese Art von Last gebaut – aber Self-Hosting bedeutet, dass man die Infrastruktur selbst verwalten muss.
00:06:51Hier kommt ZillysCloud ins Spiel: die vollständig verwaltete Version mit derselben API, die bis zu
00:06:5610-mal schneller ist und die du in wenigen Minuten einrichten kannst, ohne eine einzige Zeile Code zu ändern.
00:07:00Wir haben also eine semantische Suchabfrage auf ZillysCloud ausgeführt, und die Ergebnisse sind tatsächlich relevant, weil sie
00:07:05Bedeutung statt nur Schlüsselwörter verstehen, und die Antwortzeit ist selbst bei einem großen
00:07:11Datensatz fast augenblicklich. Wir haben auch eine Empfehlungsabfrage für einen bestimmten Artikel durchgeführt.
00:07:16Sie fand die fünf ähnlichsten im gesamten Datensatz, sortiert nach Ähnlichkeit in unter einer Sekunde. Und das Dashboard verfolgt deine Cluster-Leistung,
00:07:21Speicherauslastung und Datenmetriken, einschließlich Sammlungs- und Entitätszahlen, in Echtzeit. Keine Kreditkarte
00:07:27erforderlich – klicke einfach auf den Link im angepinnten Kommentar und teste ZillysCloud kostenlos.
00:07:31In Stufe drei geht es darum, das Design programmatisch zu testen – auf dieselbe Weise, wie Ingenieure
00:07:36Code mit TDD verifizieren. Nun wissen wir, dass man visuell keine Tests schreiben kann wie bei Code. Bei Code
00:07:41gibt es für alles klare Eingaben und Ausgaben. Design hat das nicht, weil es subjektiver ist
00:07:46und sich nicht so wie Code quantifizieren lässt. Aber nur weil es subjektiv ist, heißt das nicht, dass wir keine
00:07:51Tests dafür schreiben können. Der Grund, warum TDD für Code funktioniert, ist, dass der Test festlegt, wie das Verhalten sein soll,
00:07:57und die Implementierung diesen Vorgaben entsprechen muss. Derselbe Gedanke gilt für Design, nur mit anderen
00:08:01Arten von Vorgaben. Bei der App, die wir bauten, war der erste Schritt derselbe wie zuvor: die Dateien
00:08:05claude.md und design.md zu erstellen, noch bevor man über die Implementierung nachdenkt. Tests sollten
00:08:12immer vor dem Code geschrieben werden, damit die Implementierung tatsächlich gegen sie getestet werden kann. Wenn wir Tests
00:08:17nach der Implementierung schreiben, lässt der Agent nach. Er schreibt dann nur Testfälle, die auf den
00:08:22bereits vorhandenen Code optimiert sind, weil sich dieser Code schon in seinem Kontext befindet. Das Schreiben des Tests zuerst zwingt
00:08:27die Implementierung dazu, sich dem Test anzupassen, anstatt dass sich der Test an die Implementierung anpasst. Also verwenden wir die Designdateien
00:08:32als Single Source of Truth für die Tests, da diese Dateien alle Anti-Muster enthalten, gegen die wir
00:08:37programmatisch prüfen können. Jedes Anti-Muster in der design.md wird zu einem Testfall. Jede Farbregel,
00:08:44jede Abstandsbedingung und jede Typografie-Entscheidung erhält eine programmatische Überprüfung. Wir haben Claude Code einen
00:08:49detaillierten Prompt gegeben, um die Testfälle zu schreiben und dabei jeden Abschnitt anzugeben, auf den er sich konzentrieren soll. Wenn dir
00:08:54unsere Inhalte gefallen, überlege dir, den Like-Button zu drücken, da uns das hilft, mehr solcher Inhalte
00:08:59zu erstellen und mehr Menschen zu erreichen. Mit deinem Prompt schreibt er alle Testfälle für das Design
00:09:04der App. Er schreibt mehrere Arten von Tests: Statische Tests, die direkt auf die
00:09:09im Prompt erwähnten Anti-Muster prüfen, sowie visuelle Tests, die im Grunde
00:09:14Playwright im Hintergrund verwenden und Regressionstests durchführen, um die Website schrittweise zu verbessern. Er schreibt auch
00:09:19Testfälle für andere Komponenten und Hilfsfunktionen wie Scan and Report. Diese Tests
00:09:24prüfen zwar auf statische Anti-Muster, aber das Design-Testing erfordert noch etwas anderes. Dafür gibt es
00:09:28ein weiteres Tool namens Visly Test, im Grunde ein CLI, das TDD für UI durchführt. Die Funktionsweise besteht darin,
00:09:34dass es lokales TDD ausführt, bei dem du das Design bei Codeänderungen überprüfen kannst. So kannst du die
00:09:39Unterschiede selbst überwachen, anstatt dich auf die Selbstüberwachung des Agenten zu verlassen. Außerdem erhältst du einen besseren Diff mit
00:09:44Metadaten und anderen Details, was die Überprüfung beschleunigt. Ohne diese Metadaten vergleichst du nur zwei
00:09:49Screenshots nebeneinander und hoffst, den Unterschied zu erkennen. Damit sagt dir Visly genau, welche
00:09:54Pixel sich verändert haben und um wie viel. Um es zu nutzen, installierst du zuerst das CLI, indem du den Install-Befehl aus der
00:10:00Dokumentation ausführst. Sobald es eingerichtet und initialisiert ist, kann es losgehen. Öffne nun einfach Claude Code und weise ihn an,
00:10:05TDD zu verwenden und den gewünschten Teil der UI unter Verwendung des Visly-CLI als Testumgebung zu implementieren. Wenn
00:10:10du den Visly-TDD-Befehl ausfühest, startet ein lokaler Server und überwacht die Screenshot-Änderungen. Um die
00:10:16Screenshots zu senden, schreibt Claude im Grunde separate Tests mit dem Namen Visly. Diese Tests verwenden Playwright-
00:10:21Screenshot-Mechanismen, um die Bilder an den Viewer auf dem Server zu übertragen. Von dort aus kannst du das Design
00:10:27genehmigen oder ablehnen und Diffs im Vergleich zur vorherigen Version anzeigen. Jeder abgelehnte Diff wird zu Feedback,
00:10:32das der Agent nutzt, um den nächsten Durchlauf anzupassen. Nach einigen Iterationen nähert sich das Design dem an, was du tatsächlich
00:10:37wünschst, anstatt dem, was der Agent glaubt, dass du es wünschst. Die hier verwendeten Prompts findest du in AI Labs Pro
00:10:43für dieses Video sowie für alle unsere vorherigen Videos, von wo aus du sie herunterladen und für deine eigenen
00:10:47Projekte nutzen kannst. Wenn du unseren Inhalt wertvoll findest und den Kanal unterstützen möchtest, ist dies der beste Weg dazu. Die
00:10:52Links findest du in der Beschreibung. Damit sind wir am Ende dieses Videos angelangt. Wenn du den Kanal unterstützen
00:10:57und uns helfen möchtest, weiterhin solche Videos zu machen, kannst du das über den Super-Thanks-Button unten tun. Wie
00:11:02immer, vielen Dank fürs Zuschauen und bis zum nächsten Mal.

Key Takeaway

Die drei Ebenen des KI-Designs trennen Prompt-Optimierung von systemweiter Konsistenz und programmatischen UI-Tests mit Werkzeugen wie Visly und OKLCH.

Highlights

  • Das OKLCH-Farbsystem bildet Farben so ab, wie das menschliche Auge sie wahrnimmt, wodurch flüssigere Farbverläufe als bei RGB oder Hex-Codes entstehen.

  • Getrennte Projekt- und Designdateien wie Claude.md und design.md verhindern, dass das Design auf Unterseiten und Dashboards einbricht.

  • Das Vorgehen bei Stufe 3 nutzt Design-Driven Development mit Playwright und dem Visly-CLI für programmatische UI-Tests vor der Implementierung.

Timeline

Grundlagen und Stufe 1 für einzelnes Seitendesign

  • KI-Modelle neigen standardmäßig zu vorhersehbaren Mustern wie lila-weißen Schemata oder Einheits-Schriften.
  • Der Einsatz von OKLCH steuert Helligkeit, Chroma und Farbton präziser als herkömmliche Hex-Codes.
  • Symmetrische und asymmetrische Layouts definieren den visuellen Rhythmus und den Umgang mit Negativraum.

Die erste Stufe behandelt das Design einer einzelnen Seite durch präzises Prompt-Engineering. Durch die Vorgabe von Absicht, Anforderungen, OKLCH-Farbsystem, Kontrastverläufen und spezifischen Typografie-Ausschlüssen bricht das Modell aus generischen Standardmustern aus. Die Definition von Anti-Mustern wie zentrierten Call-to-Actions oder Lucid-Icons verhindert typischen KI-Schrott.

Stufe 2 für systemweite Konsistenz und Design-Dateien

  • Zwei separate Dateien namens Claude.md und design.md bewahren den Kontext und das visuelle System.
  • Open-Source-Skills von VersaLab vergleichen das Design aktiv mit aktuellen Best Practices.
  • ZillysCloud bietet als verwaltete Vektordatenbank bis zu 10-mal schnellere semantische Abfragen für große Datensätze.

Auf der zweiten Stufe wird sichergestellt, dass das Design beim Wechsel von der Landingpage zum Dashboard konsistent bleibt. Die Claude.md speichert reine Projektdaten, während die design.md das visuelle System, Farben und Schriften dokumentiert. Kontinuierliche Verfeinerung und Open-Source-Prüfungen sichern die Einhaltung aktueller Designstandards.

Stufe 3 für programmatisches Design-Testing

  • Tests sollten vor der Implementierung aus der design.md abgeleitet werden, um das Modell einzuschränken.
  • Statische Tests und visuelle Regressionstests prüfen das Design über Playwright im Hintergrund.
  • Das Visly-CLI ermöglicht lokales UI-Testing mit präzisen Pixel-Metriken und visuellen Diffs.

Die dritte Stufe überträgt den Ansatz des Test-Driven Developments auf das UI-Design. Das Erstellen von Tests vor dem Code zwingt die Implementierung zur Einhaltung der Vorgaben. Das Visly-CLI erstellt lokale Serverumgebungen und vergleicht Screenshots, um unerwünschte Abweichungen durch visuelle Metriken zu kontrollieren.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video