LLMs sind in vielen UX-Teams längst Alltag: Interviews clustern, Personas schreiben, User Flows entwerfen, Copy polieren. Die Antworten klingen oft brillant - fachlich korrekt, sauber formuliert, gut strukturiert. 

Genau das ist das Problem. Das Paper „Potemkin Understanding in Large Language Models“ beschreibt, wie Modelle ein überzeugendes Bild von Verständnis erzeugen, ohne intern konsistent mit Konzepten zu arbeiten. Im UX-Kontext nenne ich das: UX Potemkin – eine schicke UX-Fassade ohne tragfähiges Fundament. 

Das Wichtigste in Kürze 

• UX Potemkin bedeutet: AI klingt kompetent, bricht aber die eigenen Annahmen in der Anwendung. 

• LLMs können Konzepte korrekt erklären und sie im nächsten Schritt widersprüchlich nutzen. 

• Richtige Antwort ≠ echtes Verständnis. Entscheidend sind Konsistenz, Kontext und Nachvollziehbarkeit. 

• Trenne immer: Konzept erklären lassen vs. Konzept anwenden lassen – und vergleiche beides bewusst. 

• Baue Konsistenz-Checks direkt in Deine Prompts ein, z. B. „Zeige, wo Du Deinen eigenen Aussagen widersprichst.“ 

• Nutze AI als Sparringspartner:in, nicht als Autorität – Validation bleibt bei Dir, Deinem Team und Euren Daten. 

• Dokumentierte Prompts + klare Red-Flag-Tests machen Deinen AI-Einsatz robuster und auditierbar. 

  
  

Was ist „UX Potemkin“ überhaupt? 

Historisch steht „Potemkin“ für Fassaden-Dörfer, die Eindruck machen sollten, obwohl dahinter nichts war. 

Übertragen auf LLMs heißt das: Ein Modell liefert Dir plausible Antworten, ohne das Konzept dahinter stabil, konsistent und kontextsensibel zu nutzen. 

Im UX-Alltag wird daraus UX Potemkin: 

• Personas klingen rund, aber verhalten sich im Flow völlig anders. 

• Journeys wirken logisch, brechen aber implizite Bedürfnisse. 

• Design-Empfehlungen argumentieren mit bekannten Prinzipien, wenden sie aber inkonsistent an. 

Du schaust auf ein scheinbar solides UX-Gebäude – bis Du an einer Stelle dagegen stößt und merkst: Fassade. 

Was zeigt das Paper „Potemkin Understanding in Large Language Models“? 

Die Autor:innen untersuchen, ob LLMs Konzepte wirklich „verstehen“ – oder nur Best-Guess-Text produzieren, der so aussieht. 

Kernidee der Studie: 

• Schritt 1: Modell soll ein Konzept erklären (z. B. eine literarische Technik, spieltheoretische Idee, psychologische Verzerrung). 

• Schritt 2: Dasselbe Modell soll dieses Konzept in einer Aufgabe anwenden. 

  
  

Ergebnis: 

• Definitionen sind oft korrekt. 

• Bei der Anwendung tauchen systematisch Inkonsistenzen und Selbstwidersprüche auf. 

• Modelle können sogar behaupten, alles sei stimmig, obwohl sie ihre eigenen Regeln brechen. 

  
  

Zusätzlich generieren die Modelle eigene Frage-Antwort-Paare und bewerten später ihre Konsistenz. Die gefundenen Brüche sind dabei eher eine untere Schranke – es ist also mindestens so wackelig, vermutlich schlimmer. 

Für uns in UX heißt das: 

• Punktuelle „richtige“ Antworten sind kein Beweis für tragfähiges Verständnis. 

• Wir müssen auf Kohärenz über Tasks hinweg achten, nicht nur auf schöne Einzelergebnisse. 

  
  

Wo UX Potemkin in Deinem Alltag auftaucht 

1. Research-Synthese: Schöne Cluster, wackelige Grundlage 

Du gibst 20 Interview-Transkripte ins LLM und lässt: 

• Pain Points extrahieren 

• Needs clustern 

• Kategorien benennen 

Ergebnis: ein strukturiertes Bild mit klugen Überschriften – perfekt für ein Slide-Deck. 

UX-Potemkin-Risiko: 

• Zitate passen nicht sauber zu Kategorien. 

• Kategorien überlappen oder sind unscharf getrennt. 

• Emotionale Nuancen (z. B. Scham vs. Frust) verschwimmen. 

Besonders heikel: bei sensiblen Themen (Gesundheit, Behinderung, Finanzen) kann das Modell oberflächlich empathisch klingen und trotzdem kulturelle oder emotionale Kontexte verfehlen. 

2. Personas, Journeys und Flows: Innenleben vs. Verhalten 

LLMs lieben Personas. Sie spucken Dir in Minuten Figuren mit Zielen, Frustpunkten und Zitaten aus. 

Typisches UX-Potemkin-Muster: 

• Persona „ist äußerst kostenbewusst“, verhält sich in der Journey aber wie jemand mit hoher Zahlungsbereitschaft. 

• Persona „braucht Sicherheit und Kontrolle“, wird im Flow aber ständig von überraschenden Auto-Entscheidungen überrollt. 

Fassade: alles wirkt narrativ stimmig. Fundament: innere Logik ist kaputt – und Deine Design-Entscheidungen werden wackelig. 

3. Design-Prinzipien & Patterns: Richtig erklärt, falsch genutzt 

Du fragst: 

1. „Erkläre bitte ›Progressive Disclosure‹ im UX-Kontext.“ 

2. „Entwirf ein Dashboard auf Basis dieses Prinzips.“ 

   
   

Das Modell liefert: 

• saubere Definition von Progressive Disclosure 

• ein Dashboard mit 15 sichtbaren Metriken, 4 Filtern und 3 Tabs auf dem Startscreen 

  
  

Offiziell: „Das nutzt Progressive Disclosure.“ Faktisch: Das Gegenteil. 

Hier zeigt sich Potemkin-Verständnis sehr direkt: Das Modell kann das Prinzip beschreiben, aber nicht zuverlässig danach gestalten. 

Wie Du UX Potemkin erkennst: kompakter Werkzeugkasten 

Jetzt das Ganze im „quick & dirty“-Format, das Du direkt in Deine Prompts einbauen kannst. 

1. Erklären vs. Anwenden strikt trennen 

Immer zwei Schritte: 

1. „Erkläre in Deinen Worten, was [Konzept X] bedeutet – bitte ohne Beispiele.“ 

2. „Wende [Konzept X] in einem konkreten UX-Beispiel an und beschreibe die Nutzer:innen-Schritte.“ 

Dann: 

Findet das Modell nichts Konkretes, ist das ein Warnsignal. 

2. Konsistenz-Reflexion einfordern 

Statt nur: „Erstelle eine Journey“, lieber: 

Damit zwingst Du das Modell, seine eigene Story gegenzulesen. 

3. Gleiche Info, andere Formate (Cross-Task-Check) 

Beispiel: 

1. „Beschreibe die drei wichtigsten Bedürfnisse der Zielgruppe in einem Absatz.“ 

2. „Stelle dieselben Bedürfnisse in einer Tabelle dar: Bedürfnis | Konsequenz fürs Design | Risiko bei Missachtung.“ 

   
   

Vergleiche: Werden Begriffe plötzlich anders gewichtet oder neu erfunden, ohne Erklärung → UX Potemkin. 

4. Kurz begründen lassen 

Statt langer Chain-of-Thought reicht oft: 

„Erkläre in 3–5 Sätzen, wie Du von den beschriebenen Nutzer:innen zu diesem Interface-Vorschlag gekommen bist.“ 

Achte darauf, ob konkrete Persona-Eigenschaften vorkommen – oder nur generische UX-Floskeln. Letzteres ist Fassade. 

5. Red-Flag-Tests vorschalten 

Halte Dir ein paar Mini-Stress-Tests bereit, z. B.: 

oder 

Wenn da nichts Substanzielles kommt, wird es dünn. 

Workflow-Prinzipien für stabilen AI-Einsatz 

1. Rollenklärung & Team-Regeln 

AI ist Sparringspartner:in, nicht Entscheider:in. Nutze sie für: 

• Ideen und Varianten 

• Hypothesen und erste Struktur 

• alternative Perspektiven 

Definiere im Team einfache Regeln: 

• Kein AI-Output ohne Konsistenz-Check in Kundendokumenten. 

• Personas aus AI immer gegen echte Daten spiegeln. 

• Flows aus AI müssen mindestens einen Red-Flag-Test bestehen. 

2. Prompt-Protokolle statt Bauchgefühl 

Dokumentiere kurz: 

• Ausgangsprompts 

• wichtige Nachfragen 

• gefundene Inkonsistenzen 

Das klingt trocken, macht aber Deine Arbeit: 

• nachvollziehbar für Stakeholder 

• reproduzierbar im Team 

• überprüfbar für spätere Entscheidungen 

  
  

3. Automatisierte Sanity-Checks 

Wenn Du AI tiefer in Tools integrierst, bau kleine Prüfregeln ein, z. B.: 

• Wenn Persona „schnell & unkompliziert“ will → Warnung bei Flows mit > X Steps. 

• Wenn Hauptbedürfnis „Kontrolle“ ist → Markierung, wenn zu viel Autopilot im Flow steckt. 

Kein Schutzwall, aber ein solider UX-Potemkin-Alarm. 

Zwei kurze Praxis-Beispiele 

Beispiel 1: Research-Clustering 

Situation: LLM clustert 30 Interviews, liefert fünf schicke Kategorien mit Zitaten. 

UX-Potemkin-Problem: Zitate passen teils nicht zu den Kategorien, zwei Cluster überschneiden sich stark. Trotzdem wirkt alles slide-fähig. 

Lösung: 

• Modell fragen: „Zeige mir Pain Points, die in mehreren Clustern auftauchen, und schlage eine Neuordnung vor.“ 

• Stichprobe manuell codieren und vergleichen. 

• Clustering als Hypothese behandeln – nicht als „Fertig-Insight“. 

Beispiel 2: Progressive Disclosure im Dashboard 

Situation: LLM erklärt Progressive Disclosure korrekt, entwirft dann ein volles Überwachungs-Dashboard. 

Lösung: 

1. „Markiere alle Elemente, die Deiner Definition von Progressive Disclosure widersprechen.“ 

2. „Entwirf eine Variante mit maximal fünf initial sichtbaren Elementen und beschreibe die Offenlegungsschritte.“ 

So machst Du das Potemkin-Muster sichtbar – und zwingst das Modell zur Korrektur. 

FAQ zu UX Potemkin & LLMs 

1. Lohnt sich der Einsatz von LLMs dann überhaupt? Ja. LLMs sind stark bei Struktur, Formulierung und Varianten. Sie werden zum Problem, wenn Du sie als „Wahrheitsmaschine“ behandelst. Nutze sie bewusst als Unterstützung – nicht als Autorität. 

2. Fressen diese Checks nicht die gesamte Zeitersparnis wieder auf? Ein Teil der Zeitersparnis geht in Checks – aber sinnvoll. Lieber 20 % der gesparten Zeit in Konsistenz-Prüfungen stecken, als ein Projekt auf einer schicken Fassade aufzubauen, die später teuer korrigiert werden muss. 

3. Sind teurere oder neuere Modelle weniger anfällig für UX Potemkin? Sie sind oft besser darin, Fassade zu spielen: noch flüssiger, noch überzeugender. Das reduziert manche Fehler, erhöht aber auch das Risiko, dass Du ihnen zu schnell glaubst. Je „smart“ ein Modell wirkt, desto wichtiger sind Deine Checks. 

4. Kann ich Potemkin-Verständnisse komplett vermeiden? Nein. Aber Du kannst sie deutlich reduzieren, indem Du: 

• Erklären vs. Anwenden trennst 

• Konsistenz-Prompts nutzt 

• Team-Regeln definierst 

• AI-Ergebnisse gegen echte Daten hältst 

Es geht nicht um Perfektion, sondern um kontrollierbare Risiken. 

Fazit: Wie Du mit UX Potemkin umgehen kannst 

Potemkin-Verständnisse sind kein theoretischer Spielplatz, sondern ein sehr reales Risiko, sobald AI in Deinen UX-Prozess einzieht. 

Merke Dir: 

• LLMs liefern schnell eine UX-Fassade, die stabil wirkt, aber innere Brüche haben kann. 

• Entscheidend ist nicht, wie gut der Output klingt, sondern wie konsistent er zu Deinen Daten und Annahmen passt. 

• Du behältst die Verantwortung: für Research-Qualität, Design-Entscheidungen und ethische Implikationen. 

Nutze AI als Sparringspartner:in – mit klaren Konsistenz-Checks, dokumentierten Prompts und einem Team, das weiß, worauf es achten muss. 

Dein nächster Schritt 

Nimm ein aktuelles Projekt und probiere eine einfache Zwei-Stufen-Strategie: 

1. Begriff erklären lassen (z. B. ein Prinzip, ein Bedürfnis, ein Geschäftsmodell). 

2. Anwendung dazu erstellen lassen (Persona, Journey oder Flow) – und aktiv nach Widersprüchen fragen. 

   
   

💌 Noch nicht genug? Dann lies weiter – in unserem Newsletter.

Kommt viermal im Jahr. Bleibt länger im Kopf.  https://www.uintent.com/de/newsletter

Stand: Dezember 2025