WPML mit Claude Code neu gestalten – und was ich über das Entwickeln mit KI lerne

Ich bin der Gründer von OnTheGoSystems. Diese Woche habe ich persönlich die Admin-Oberfläche von WPML, unserem größten Produkt, neu gestaltet. Nicht das Projekt geleitet. Nicht die Arbeit anderer überprüft. Sondern mit Claude Code zusammengesessen und die eigentliche Designarbeit selbst erledigt.

Zwei Gründe.

Erstens: Eine übersichtlichere, intuitivere Admin-Oberfläche ist das Wichtigste, was unsere Kunden von uns verlangen. Seit Jahren sagen sie uns, dass WPML zu viele Bildschirme hat, dass Einstellungen über unzusammenhängende Bereiche verteilt sind, dass wichtige Funktionen schwer zu finden sind. Wenn etwas den Kunden so wichtig ist, möchte ich es mit meinen eigenen Händen leiten – nicht aus der Ferne.

Zweitens: Ich wollte aus erster Hand lernen, wie die Entwicklung echter Produkte mit KI heute aussieht. Nicht, was Demos zeigen. Nicht, was Vordenker behaupten. Echte Produktarbeit an einer Codebasis, die echte Kunden sehen werden, mit all dem Durcheinander, das dazugehört. Ich entdecke lieber selbst, was funktioniert, indem ich die Arbeit selbst mache, als dass mir jemand davon berichtet.

Was ich herausfand, überraschte mich in beide Richtungen. Einige Dinge, von denen ich erwartete, dass sie einfach sein würden, stellten sich als schwierig heraus – insbesondere die KI mit der Realität in Einklang zu halten, wenn sie versucht war, Funktionen zu erfinden, die plausibel klangen, aber nicht in unserem Produkt vorhanden waren. Andere Dinge, von denen ich erwartete, dass sie schwierig sein würden, stellten sich als nahezu trivial heraus – wie die Erstellung von dreizehn konsistenten HTML-Dateien für einen neuen Bereich in unter einer Stunde, jede mit funktionierendem JavaScript für Zustandsumschaltungen und Suchindizierung, und jede einzelne als Designreferenz für das Team verwendbar, das die echte Umsetzung vornimmt.

Die Geschwindigkeit war ehrlich gesagt die kleinere Überraschung. Die größere war, wie sehr die Methode zählt. Wenn Sie die Methode richtig anwenden, erhalten Sie kumulative Ergebnisse – bessere Ausgabe, schneller, mit Dokumentation, die zur Übergabe bereit ist. Wenn Sie sie falsch anwenden, erreichen Sie nur schneller Mittelmäßigkeit.

Was folgt, ist die vollständige Methode, die ich verwendet habe – die Prompts, die funktionierten, die Fehler, die ich gemacht habe, die Überprüfungsrunden, die von der KI erfundene Funktionen abfingen, bevor sie ausgeliefert werden konnten. Sie ist in erster Linie für OTGS-Entwickler geschrieben, die solche Projekte selbst durchführen möchten, aber jeder, der heute Benutzeroberflächen mit KI erstellt, kann wahrscheinlich etwas daraus mitnehmen.

Die eine Regel, die dies zum Funktionieren bringt

Planen Sie in Text, bevor Sie Code produzieren.

Claude Code wird gerne HTML erstellen, sobald Sie danach fragen. Es wird auch das falsche HTML erstellen – höflich, schnell und in großen Mengen. Jedes Mal, wenn Sie durch das Überspringen einer Planungsrunde Zeit sparen, zahlen Sie doppelt bei der Nacharbeit – und die Nacharbeit ist schwieriger als die ursprüngliche Planung, weil es jetzt Code gibt, den Sie nicht wegwerfen möchten.

Jeder erfolgreiche Zweig in der WPML-Sitzung hatte dieselbe Form:

1. Amir formulierte ein Problem oder eine Absicht.
2. Claude stellte klärende Fragen.
3. Amir antwortete prägnant.
4. Claude schlug einen Plan in Textform vor.
5. Amir bestätigte oder bearbeitete den Plan.
6. Erst dann begann Claude mit der Erstellung.

Überall dort, wo diese Form zusammenbrach, gingen wir zurück. Wenn Sie sich nichts anderes aus diesem Leitfaden merken, merken Sie sich die sechs Schritte oben.

Die acht Phasen einer Sitzung

1. Formulieren Sie das Problem, nicht die Lösung

Beginnen Sie mit dem Schmerz, den der Benutzer empfindet, nicht mit dem Bildschirm, den Sie ändern möchten.

Schlechter Einstieg:

„Neue Einstellungsseite für die Abrechnung der KI-Übersetzung hinzufügen.“

Guter Einstieg (wie die WPML-Sitzung tatsächlich begann):

„Benutzer berichten, dass WPML überwältigend und unintuititiv wirkt aufgrund von:

• Zu vielen verschiedenen übersetzungsbezogenen Bildschirmen.
• Einstellungen, die über mehrere, manchmal unzusammenhängende Bereiche verteilt sind.
• Prominenten, aber unwichtigen Optionen, die von den Hauptübersetzungs-Workflows ablenken.
• Verwandten Abschnitten, die über verschiedene Bildschirme verteilt sind, ohne klare Abhängigkeiten oder Navigationspfade.
• Fehlende Querverlinkung zwischen verwandten Funktionen…“

Die zweite Version gibt Claude einen Rahmen zum Nachdenken. Es kennt den Schmerz des Benutzers, kann andere Dinge erkennen, die zu diesem Schmerz beitragen, und kann zurückdrängen, wenn Ihre vorgeschlagene Lösung die Grundursache nicht angeht. Die erste Version reduziert Claude auf einen Schreiber.

In der WPML-Sitzung führte die Problemformulierung direkt zu Entscheidungen, die Claude nicht allein hätte treffen können: dass „Zahlungen & Wartung“ ein Bildschirm zu viel war, dass Pakete nicht auf oberster Ebene sein sollten, dass das Kommunikationsprotokoll im falschen Menü war, dass das Glossar weder eine Einstellung noch ein Abrechnungselement war. Nichts davon würde greifen, wenn man mit „Einstellungen neu gestalten“ beginnt.

2. Sammeln Sie Ihr Material, bevor die Sitzung beginnt

Legen Sie alles, was die KI benötigt, in das Arbeitsverzeichnis, bevor Sie einen Prompt eingeben:

• Screenshots der aktuellen Benutzeroberfläche. Jeden Bildschirm, den Sie möglicherweise berühren. In der WPML-Sitzung befanden sie sich in Current/ – WPML settings.jpg, debug-main.jpg, td-invoices.jpg, td-translators.jpg usw. Etwa zehn JPGs, die alles im Umfang abdecken.
• Eine instructions.txt, die das Problem, den Umfang und die Ausgabeerwartung angibt. Siehe ../instructions.txt für die tatsächliche – beachten Sie, wie sie über drei Durchgänge (--- 1 ---, --- 2 ---, --- 3 ---) wuchs, als neuer Umfang hinzugefügt wurde, anstatt jedes Mal neu geschrieben zu werden.
• Jedes bereits vorhandene Design in einem already-updated/-Ordner. Die WPML-Sitzung begann mit einer gestalteten ai-translation.html, die Claude als visuelle Vorlage für alles andere verwendete, was in der Sitzung produziert wurde – die Tailwind-Konfiguration, die Kartenklasse, das Zurück-Link-Muster, die Flash-Animation für Ankersprünge. Diese einzelne Datei sparte etwa 30 Minuten an Entscheidungen zum visuellen System.
• Externe Links, die Claude konsultieren soll. Für die Fehlerbehebung steuerte die WPML-Mindestanforderungsseite (wpml.org/home/minimum-requirements/) das Design des Warnfelds.

Claude funktioniert besser, wenn es die Quelle der Wahrheit sehen kann. Screenshots ermöglichen es, Behauptungen gegen die Realität zu überprüfen. Externe Links ermöglichen es, Recherchen über Subagenten durchzuführen (siehe Phase 8), ohne Sie mit Hintergrundinformationen zu belästigen.

3. Beenden Sie jedes Briefing mit „Stellen Sie mir Fragen, treffen Sie keine Annahmen.“

Dies ist der Satz mit der höchsten Hebelwirkung im Leitfaden. Jede Anweisungsreihe in der WPML-Sitzung endete mit einer Version von:

„Bevor Sie mit dem Design beginnen, überprüfen Sie alles, erstellen Sie eine Liste mit Fragen und stellen Sie sie mir. Treffen Sie keine Annahmen.“

Ohne dies handelt Claude standardmäßig direkt nach Ihrer Anweisung. Damit verbringt Claude eine Runde damit, herauszufinden, was es nicht weiß, und fragt Sie. Diese Runde spart Stunden.

Wenn Claude Fragen zurückstellt, beantworten Sie sie knapp. Sie schulden keine Absätze. Aus der WPML-Sitzung:

F: „Menübezeichnung — als ‚Zahlung für KI-Übersetzung‘ beibehalten? (klingt etwas umständlich)“
A: „Abrechnung für KI-Übersetzung“

F: „Seitenstruktur — eine lange Seite mit Abschnitten oder Unterseiten?“
A: „Unterseiten, die einer ähnlichen Struktur folgen, wie Sie die Einstellungsseite aufgebaut haben. Wir müssen planen, bevor Sie implementieren.“

Einzeilige Antworten sind in Ordnung. Vollständige Sätze sind in Ordnung. Vollständige Absätze sind normalerweise ein Zeichen dafür, dass Sie Claudes Arbeit für es erledigen.

4. Durchlaufen Sie Fragerunden, bevor Sie mit der Implementierung beginnen

Der Abrechnungsbereich der WPML-Sitzung durchlief zwei vollständige Fragerunden, bevor eine einzige Zeile HTML geschrieben wurde.

Runde 1 — 8 Fragen zu: Menübezeichnung, Seitenstruktur, Zustandsvarianten, dem redundanten Zähler für verbundene Websites, Platzierung des Glossars, Platzierung von „Wer kann verwenden“, Umfang der Abrechnung, Behandlung von Aktionen nur für den Eigentümer.

Runde 2 — 7 weitere, fokussierte Fragen: Übersicht vs. Index, der CTA „Müde vom Zuweisen von Credits“, Inhalt der Nutzungsberichte, UX für die Übertragung von Credits, Felder für den aktiven Zahlung nach Bedarf-Status, Status für Vorauszahlung aktiv, Umfang nur für den Eigentümer.

Erst nach beiden Runden schlug Claude den Dateiplan vor. Erst nachdem der Dateiplan bestätigt wurde, wurde HTML geschrieben. Gesamte verstrichene Planungszeit: vielleicht fünfzehn Minuten Hin und Her. Insgesamt produzierte Dateien: fünf, alle beim ersten Mal korrekt.

Das Anti-Muster besteht darin, sich nach einer Runde auf die Ausgabe festzulegen und dann jede Datei zwei- oder dreimal neu zu generieren, weil die Einschränkungen nicht vollständig aufgedeckt wurden. Dieser Weg fühlt sich schneller an bis zur dritten Stunde.

5. Kennzeichnen Sie Mockup-spezifische Bedienelemente explizit

Mockups müssen oft mehrere Zustände desselben Bildschirms zeigen – leer vs. gefüllt, sicher vs. Warnung, Plan aktiv vs. Plan inaktiv. Zwei Muster in dieser Sitzung funktionierten gut:

Der Umschalter für den Abrechnungsstatus. Die Abrechnungs-Landingpage verfügt oben rechts über ein Preview state: No plan | PAYG active Steuerelement. Durch Klicken auf eine der Optionen wechselt das Übersichtsfeld zwischen den beiden Zuständen — „kein Plan“ zeigt beide Akquisitionskarten, „Zahlung nach Bedarf aktiv“ zeigt das einzelne Panel „Ihr Zahlung nach Bedarf-Plan“ mit Kartendetails. Beschriftet mit „Vorschau-Status:“, damit Prüfer verstehen, dass dies eine Mockup-Funktion und keine Produkt-Benutzeroberfläche ist.

Die Fehlerbehebungs-Warnungsumschaltung. Preview state: Has warnings | All OK zeigt oder verbirgt das gelbe Mindestanforderungsfeld. Gleiche Beschriftung, gleicher Grund.

Ohne diese würden Sie zwei separate HTML-Dateien für jeden Bildschirm mit einer Zustandsübergang ausliefern. Mit ihnen demonstriert eine Datei die gesamte Designoberfläche. Prüfer sehen mehr, schneller.

Rufen Sie sie im YT-Ticket-Update explizit auf:

„Oben gibt es einen Umschalter: ‚Vorschau-Status: Kein Plan / Zahlung nach Bedarf aktiv‘. Verwenden Sie ihn, um beide Zustände zu sehen. Dies ist natürlich nur ein Teil des Mockups und nicht für die tatsächliche Benutzeroberfläche gedacht.“

Die kursiv gedruckte Klausel ist wichtig. Andernfalls wird ein Entwickler fragen, warum das Produkt eine Zustandsumschaltung hat.

6. Führen Sie eine Überprüfungsrunde durch, bei der Mockups mit der Quelle verglichen werden

Nachdem alles erstellt wurde, bevor Sie sich auf die Übergabe festlegen, führen Sie eine Überprüfungsrunde durch. In dieser Sitzung war es ein einzelner Prompt:

„Alles sieht gut aus. Führen Sie eine Überprüfungsrunde durch:

1. Überprüfen Sie die Eingabe-Screenshots im Detail, um sicherzustellen, dass Sie keine Dinge hinzugefügt haben, die WPML nicht hat, und keine Dinge entfernt haben, die dort sein sollten.
2. Überprüfen Sie, ob die Texterklärungen für jede Seite und jede Funktion ausreichend beschreibend sind, damit Kunden verstehen, was ‚dies‘ tut, wofür es gut ist und was zu erwarten ist.“

Claude untersuchte jeden Screenshot erneut, verglich ihn mit jeder produzierten Datei und gab einen strukturierten Bericht zurück. Aus der WPML-Fehlerbehebungsüberprüfung:

• Fehlt in meinem Design — fünf Tools, die in der aktuellen Benutzeroberfläche vorhanden sind und nicht portiert wurden: „Kommentare entfernen, die nicht der Sprache des Inhalts entsprechen“, „Nachrichten und Benachrichtigungen / Alle Nachrichten und Benachrichtigungen entfernen“, „wpml_language-Code in der WPML-Einrichtung korrigieren“, „ATE zurücksetzen / Debug-Protokoll zurücksetzen“ und die Tabelle des Installer-Protokolls auf der Installer Support-Seite.
• Dinge, die ich hinzugefügt habe, die nicht existieren – das System-Check-Mockup zeigte 4 Konnektivitätsserver; das aktuelle Produkt prüft nur 2. Es listete 4 PHP-Bibliotheken auf; aktuell werden 2 angezeigt.
• Erklärungen, die geschärft werden müssen – Das Kommunikationsprotokoll erklärte nicht, wie Erfolg/Misserfolg aussieht; die Paketverwaltung erwähnte nicht, dass Pakete automatisch von anderen Plugins erstellt werden; die Inhaltstyp-Verknüpfung erklärte nicht die sichtbare Auswirkung der Änderung einer Zuordnung.

Jeder Punkt war in einer einzigen Folgerunde behebbar. Keiner wäre ohne den Überprüfungsprompt aufgefallen. Die KI hat hier einen Vorteil, den Sie nicht haben – sie kann jede Seite und jeden Screenshot gleichzeitig in einer Runde erneut lesen.

Tun Sie es immer. Behandeln Sie es nicht als optional.

7. Schreiben Sie die Entwicklerübergabe parallel, nicht am Ende

Das YT-Ticket-Update in der WPML-Sitzung durchlief während der Sitzung mehrere Iterationen — verfeinert, während sich das Design entwickelte, nicht in Panik am Ende zusammengestellt. Als PostHog in „Nutzungsverfolgung und Berichterstattung“ umbenannt wurde, spiegelte das Ticket-Update dies sofort wider.

Ein gutes Ticket-Update für eine Benutzeroberflächen-Neugestaltungsübergabe hat:

1. Eine Zusammenfassung in einem Absatz dessen, was sich ändert.
2. Aufzählungspunkte zu Änderungen auf hoher Ebene – was verschoben wird, was entfernt wird, was hinzugefügt wird.
3. Eine Detailtabelle pro Bereich – Seitenname, was sich geändert hat, warum. Überspringen Sie Kosmetik, wenn der gesamte Abschnitt neu gestaltet wurde – es ist Rauschen.
4. Eine Migrationszuordnungstabelle für alles, was Admin-Menüs überschreitet. Verwenden Sie exakte aktuelle Benutzeroberflächenpfade: WPML → Translation Dashboard → Payments & Maintenance → Advanced Translation Editor → Overview → Who can use Automatic Translation? – keine Zusammenfassungen, keine Paraphrasen.
5. Offene Punkte – was noch den Input des empfangenden Teams benötigt.
6. @-Erwähnungen der spezifischen Personen, die sich bestimmte Bereiche ansehen müssen.

Das tatsächliche WPML-Ticket-Update umfasst etwa 2.500 Wörter und deckt drei Menüs der obersten Ebene ab (Einstellungen / AI Translation Billing / Fehlerbehebung). Es ist länger als die meisten Tickets, weil die Änderungsoberfläche groß ist – haben Sie keine Angst vor Länge, wenn die Änderung komplex ist, aber seien Sie diszipliniert darüber, was in die Tabelle gehört (Pfade und Ziele) vs. was in Prosa gehört (Prinzipien und Begründung).

Wenn Sie möchten, dass Claude das Ticket aktualisiert, während sich das Design entwickelt, funktioniert ein strukturierter Prompt am besten:

„Ich benötige, dass Sie meine Nachricht aktualisieren, die die vorgenommenen Änderungen erklärt.

1. Sie sollte einen neuen Abschnitt über [X] haben.
2. Erklären Sie, warum wir [Y getan haben].
3. Fügen Sie eine Tabelle mit den Details der Änderung hinzu. Überspringen Sie Kosmetik, weil alles in diesem Abschnitt ein neues Erscheinungsbild hat.
4. Aktualisieren Sie die aktuellen Anweisungen, da Sie nun einige Steuerelemente nach [Z] verschoben haben.“

Spezifisch, strukturiert, und es sagt Claude, was erhalten bleiben soll vs. was sich ändern soll.

8. Verwenden Sie Subagenten für externe Recherchen

Wenn Claude Informationen von außerhalb des Arbeitsverzeichnisses benötigt – Anbieterdokumentation, Blogbeiträge, Mindestanforderungen – delegieren Sie an einen Subagenten. Holen und fügen Sie nicht manuell ein.

Der Prompt, der die WPML-Fehlerbehebungsrecherche startete:

„Recherchieren Sie die Fehlerbehebungs-/Debug-Funktionen des WPML-Plugins auf wpml.org (der offiziellen Dokumentationsseite) und geben Sie eine prägnante Zusammenfassung zurück, was jede Funktion tut und wie das Support-Team von WPML Benutzer normalerweise anweist, sie zu verwenden. […] Bitte suchen Sie die Dokumentation für jede der folgenden auf und sagen Sie mir:

• Was das Tool tut (1–2 Sätze)
• Wer es verwendet – Endbenutzer-Selbstbedienung oder nur auf Anweisung des Supports
• Ist es destruktiv/riskant? (setzt Daten zurück, löscht Cache usw.)
• Alle bekannten Benutzerverwirrungen, die in den Dokumenten erwähnt werden.“

Dieser Subagent gab eine strukturierte Zusammenfassung mit Quelllinks zurück, die direkt die dreistufige Organisation (sicher / Protokolle / nur Support) der Fehlerbehebungs-Neugestaltung formte. Ohne ihn hätten wir entweder geraten, wer was verwendet, oder den Ablauf unterbrochen, um selbst Dokumentation zu lesen.

Wenn Sie an einen Subagenten delegieren, sagen Sie ihm:

• Was Sie zu erreichen versuchen (damit er Grenzfälle beurteilen kann, nicht nur Anweisungen befolgen).
• Genau welches Format Sie zurückhaben möchten (Tabelle? Aufzählungspunkte? Ein Satz jeweils?).
• Ein Wort- oder Zeitbudget. Andernfalls gibt es einen Aufsatz zurück.

Kritische UX-Prinzipien, die aus der Arbeit hervorgingen

Die Methode ist das Wichtigste. Aber einige Prinzipien traten oft genug auf, um es wert zu sein, sie im Voraus zu kennen – sie ersparen Ihnen ein oder zwei Fragerunden.

Organisieren Sie nach Risiko, nicht nach Thema

Die aktuelle WPML-Fehlerbehebungsseite ist eine riesige Bildlaufseite mit ca. 25 Tools, die „Cache leeren“ mit „WPML vollständig zurücksetzen“ mit dem gleichen visuellen Gewicht mischt. Kunden können nicht erkennen, was sicher ist. Supporter können keine URL angeben.

Die Neugestaltung sortiert jedes Tool in eine von drei Stufen mit farbigen Abzeichen:

• Sicher selbst auszuführen (grün) – Selbstbedienungskorrekturen, die Kunden ohne Hilfe ausprobieren können.
• Protokolle – nur lesen (blaue Info) – Diagnosen, die niemals etwas ändern.
• Erweitert – nur wenn der WPML-Support Sie darum bittet (rot, plus ein Erklärungsabsatz auf Gruppenebene) – Tools, die Daten verlieren oder eine Website beschädigen können, wenn sie falsch verwendet werden.

Wenn Sie eine dichte technische Seite neu gestalten, fragen Sie „Was ist der Explosionsradius jedes Tools?“, bevor Sie fragen „Zu welchem Thema gehört jedes Tool?“

Jedes Tool beantwortet drei Fragen

Damit ein Tool als Selbstbedienung funktioniert, muss sein Text dem Benutzer sagen:

1. Was es tut.
2. Wann es nützlich ist.
3. Was danach zu erwarten ist.

Das WPML-Tool „post_parent in Übersetzungen reparieren“ wurde von der knappen Formulierung des aktuellen Produkts „Repariert die übergeordneten Beziehungen übersetzter Beiträge.“ zu:

„Verknüpft übersetzte Unterseiten (oder andere hierarchische Inhalte) neu mit der übersetzten Version ihres übergeordneten Elements, anstatt auf das übergeordnete Element in der Originalsprache zu verweisen. Nützlich nach Migrationen oder Massenimporten.“

Dasselbe Tool, dreimal nützlicher, weil der Benutzer jetzt weiß, wann er danach greifen soll.

Abgestufte Sicherheitskontrollen

Nicht jede destruktive Aktion benötigt dasselbe Bestätigungsmuster. Die WPML-Sitzung endete mit drei Stufen:

• Sichere Aktion → eine Schaltfläche.
• Aktion mit mittlerem Risiko → ein „Ich verstehe“-Kontrollkästchen aktiviert die Schaltfläche; ein roter Absatz darüber erklärt das spezifische Risiko.
• Nukleare Aktion (WPML vollständig zurücksetzen) → das Kontrollkästchen UND eine eingegebene RESET WPML-Phrase müssen beide korrekt sein.

Unterschiedliche Risikoniveaus, unterschiedliche Reibung.

Querverknüpfen, nicht duplizieren

Wenn ein Tool mit einer Einstellung überlappt, verlinken Sie, anstatt es zu besitzen. Die Seite „Fehlerbehebung → Nutzungsberichte“ verlinkt zu „Einstellungen → KI-Übersetzung → Wer kann die automatische Übersetzung verwenden“, anstatt dieses Steuerelement neu zu implementieren. Eine einzige Quelle der Wahrheit, ein Ort zur Pflege, eine konsistente Erfahrung.

Für Kunden umbenennen

Interne Anbieter- oder Akronymnamen gehören nicht in kundenorientierte Texte. In dieser Sitzung:

• „PostHog-Integration“ → „Nutzungsverfolgung und Berichterstattung“ (Kunden wissen nicht, was PostHog ist).
• „ATE“ als UI-Bezeichnung → „Erweiterter Übersetzungs-Editor“ (ATE bleibt nur als interne Kurzform in YT-Kommentaren).
• „Credits“ → „Wörter“ (Änderung des Preismodells — aber die UX-Lektion verallgemeinert sich: keine internen Anbieter- oder Abrechnungsdetails als benutzerseitige Substantive offenlegen).

Suche schlägt Navigation bei dichten Oberflächen

Der WPML-Einstellungsindex hat 16 Abschnitte; die Fehlerbehebungsseite hat ~25 Tools. Von einem Benutzer zu erwarten, dass er scannt und das richtige findet, ist unrealistisch. Eine prominente, bereichsbezogene Suche mit Unterelement-Indizierung — so dass die Eingabe von „ghost“ direkt zum Anker des Ghost-Einträge-Tools springt — löst die Auffindbarkeit besser als jede Navigationsbereinigung.

Der Abrechnungsbereich war anders: 4 Unterseiten, alle mit klar verständlichen Bezeichnungen. Wir haben die Suche zunächst hinzugefügt, dann aber nach Bewertung der tatsächlichen Dichte wieder entfernt. Das Prinzip:

Wenn eine Seite ≤6 Top-Level-Elemente mit klar verständlichen Bezeichnungen hat, fügen Sie keine Suche hinzu. Wenn sie >10 technische Elemente hat, lohnt sich die Suche fast immer.

Proaktive Warnungen statt passiver Einstellungen

Wenn Ihre Website eine bekannte Anforderung nicht erfüllt, informieren Sie den Benutzer oben auf der Seite — warten Sie nicht, bis er es durch einen Fehler entdeckt. Die Fehlerbehebungs-Landingpage führt jede Prüfung aus der WPML-Mindestanforderungsliste durch und zeigt Fehler in einem gelben Panel über der Suche an. Wenn alles bestanden ist, wird das Panel vollständig ausgeblendet.

Funktionierende Prompt-Muster

Dies sind die exakten Formulierungen, die die WPML-Sitzung auf Kurs hielten. Übernehmen Sie sie.

Fragerunden erzwingen

„Bevor Sie fortfahren, überprüfen Sie alles und bitten Sie mich um Klärungen. Treffen Sie keine Annahmen.“

„Wenn Sie noch Fragen haben, stellen Sie diese.“

„Stellen Sie das Material zusammen und stellen Sie mir Fragen, bevor Sie das Ergebnis produzieren.“

Überprüfung vorantreiben

„Führen Sie eine Überprüfungsrunde durch:

1. Überprüfen Sie die Eingabe-Screenshots detailliert, um sicherzustellen, dass Sie nichts hinzugefügt haben, was WPML nicht hat, und nichts entfernt haben, was vorhanden sein sollte.
2. Überprüfen Sie, ob die Texterklärungen für jede Seite und jede Funktion ausreichend beschreibend sind, damit Kunden verstehen, was ‚dies‘ tut, wofür es gut ist und was zu erwarten ist.“

Bewertung vor dem Handeln

„Tatsächlich sehe ich, dass die Suchfunktion für den Abrechnungsbereich nicht erforderlich ist. Bitte bewerten Sie und sagen Sie mir, ob ein Bedarf besteht, basierend auf dem Inhalt der Unterseiten.“

Claude zu bitten, zu bewerten, bevor er implementiert, ist der Weg, um zu vermeiden, dass man etwas drei Bearbeitungen später rückgängig machen muss. In der WPML-Sitzung führte dieser Prompt dazu, dass die Suche in der Abrechnung in einem Schritt sauber entfernt wurde, anstatt halb implementiert und dann wieder herausgerissen zu werden.

Mehrdeutigkeit aufdecken

„Überprüfen Sie auf Konsistenz und Konflikte. Erstellen Sie eine aktualisierte Version, die frei von Konflikten und Mehrdeutigkeiten ist. Bevor Sie dies tun, stellen Sie mir Fragen, damit Sie keine Annahmen treffen oder erfinden müssen.“

Als dies gefragt wurde, lieferte Claude eine strukturierte Liste von Widersprüchen in einem Entwurf für ein Ticket-Update („Elemente, die als entfernt aufgeführt sind, sind auch als verschoben aufgeführt — was stimmt?“, „‚ATE‘ ist mehrdeutig: Erweiterter Übersetzungs-Editor oder Automatische Übersetzungs-Engine?“). Jeder konnte mit einer einzigen Antwort gelöst werden. Ohne diesen Prompt wären diese Widersprüche ausgeliefert worden.

Gezielte Umbenennungen und Verschiebungen

„Benennen Sie ‚X‘ in ‚Y‘ in allen Fehlerbehebungsdateien um.“

„Verschieben Sie den gelben Block für die Mindestanforderungen über die Suche in troubleshooting.html.“

Chirurgisch. Spezifisch. Funktioniert immer — solange die Änderung wirklich mechanisch ist. Für alles, was Urteilsvermögen erfordert, kehren Sie zum Planungsmuster zurück.

Zu vermeidende Fallstricke

• Planung überspringen, um „Zeit zu sparen“. Jede übersprungene Planungsrunde kostet mehr Nacharbeit, als sie gespart hat.
• Funktionen akzeptieren, deren Existenz Sie nicht überprüft haben. Claude fügte zunächst 4 Konnektivitätsserver zur Systemprüfung hinzu; das Produkt hat nur 2. Im Review entdeckt. Sie sind für die Plausibilitätsprüfung verantwortlich — vertrauen Sie nicht der Plausibilität als Ersatz für Genauigkeit.
• Namensdrift. Sobald eine Entscheidung getroffen ist („ATE“ ist nur intern; die Kunden-UI sagt „Erweiterter Übersetzungs-Editor“), setzen Sie diese überall durch. Abweichungen zwischen Mockup-Dateien und Tickets führen zu Verwirrung bei den Entwicklern. Bitten Sie Claude, Umbenennungen zu verbreiten — tun Sie es nicht manuell.
• Unbeschriftete, nur für Mockups vorgesehene Steuerelemente. Vorschau-Umschalter sind großartig für Reviews. Ohne eine Beschriftung „Vorschau-Status:“ lesen sie sich wie Produkt-UI.
• Vergessen der konsistenten Dokumentenübergreifung. Wenn eine Funktion umbenannt wird, müssen die HTML, der Suchindex, der Dateiname, jedes href und das YT-Ticket aktualisiert werden. Sagen Sie Claude, dass er es verbreiten soll — jagen Sie es nicht Datei für Datei.
• Handoff-Dokumente bis zum Schluss aufschieben. Schreiben Sie das Ticket während des Prozesses. Wenn das Design stabil ist, ist das Ticket fertig.
• Die KI entscheiden lassen, was wichtig ist. Claude ist großartig in der Ausführung; bei Urteilsentscheidungen, die vom institutionellen Kontext abhängen, ist er mittelmäßig. Die Entscheidung „Wir brauchen hier keine Suche“ bei der Abrechnung kam von Amir, nicht von Claude — und sie war richtig. Übertragen Sie redaktionelle Entscheidungen nicht an das Tool.

Ein Beispiel für einen Sitzungsablauf

Wenn Sie bis hierher gelesen haben, hier ist der gesamte Arbeitsablauf zusammengefasst:

1. Rahmen — beschreiben Sie das Problem des Benutzers, listen Sie die Bildschirme/Bereiche im Umfang auf, fügen Sie Screenshots bei.
2. Briefing — schreiben Sie ein instructions.txt, das mit „Überprüfen Sie alles, stellen Sie mir Fragen, treffen Sie keine Annahmen.“ endet.
3. Fragerunde 1 — lassen Sie Claude 5–10 Fragen stellen. Beantworten Sie sie knapp.
4. Plan — Claude schlägt eine Gesamtstruktur vor. Sie bestätigen oder passen an.
5. Fragerunde 2 — detailliertere verbleibende Fragen (normalerweise zu Zustandsvarianten, Randfällen, Bestätigungen).
6. Unterplan — Dateiliste und Gliederung pro Datei.
7. Erstellen — Claude schreibt die Dateien. Überprüfen Sie jede, sobald sie eingeht.
8. Überprüfung — Vergleich mit Quell-Screenshots; fehlende/hinzugefügte Elemente finden; Text schärfen.
9. Konsolidieren — Entwurf des YT-Ticket-Updates und Iteration parallel zum Design.
10. Übergabe — in das Repository pushen, ein kurzes Walkthrough-Video aufnehmen, das empfangende Team @erwähnen.

Budgetieren Sie für die Schritte 3–5 und Schritt 8 — der Rest ist hauptsächlich Ausführung.

Abschluss

Die größte Lektion der WPML-Sitzung ist, dass Claude Code kein Designer ist; es ist ein disziplinierter Erbauer, der einen gut spezifizierten Plan mit ungewöhnlicher Geschwindigkeit ausführen kann. Ihr Wert in der Schleife ist Urteilsvermögen, nicht Tippen. Geben Sie Claude das Problem, verlangen Sie, dass er Fragen stellt, bestehen Sie auf einem Plan in Textform, überprüfen Sie die Ausgabe anhand der Quelle der Wahrheit und bereiten Sie die Übergabe während des Prozesses vor.

Wenn Sie das tun, ist die Geschwindigkeit, die Sie erhalten, keine 2-fache Verbesserung gegenüber manueller UX-Arbeit. Sie liegt eher in der Größenordnung — und die Ausgabequalität ist höher, weil die Überprüfungsdisziplin in den Workflow integriert ist, anstatt etwas zu sein, woran Sie sich erinnern müssten.

Dieses Design-Update wird in WPML 4.10 integriert. Wie das KI-gesteuerte Design werden wir dieses riesige Update durch den Einsatz von KI-Agenten implementieren, die autonom als Team arbeiten. Wenn Sie an einer Vorschau interessiert sind, hier ist ein kurzes Video: