6 Min. Lesezeit

Wer braucht eigentlich noch UX Designer?

Wenn Daten und Services immer häufiger über Sprachmodelle bereitgestellt werden – wozu dann noch User Flows und Journey Maps? Über Kontext, MCP Server und die Frage, was von einem Berufsbild bleibt.

Featured image for "Wer braucht eigentlich noch UX Designer?"

Wer braucht eigentlich noch UX Designer, wenn Daten und Services immer häufiger über Sprachmodelle bereitgestellt werden? Die UI ist doch quasi vorgegeben – ein Chatfenster, fertig. Der Nutzer tippt, das LLM antwortet. Wozu noch User Flows, Wireframes, Journey Maps?

Die Frage klingt provokant. Sie ist es auch. Aber ich stelle sie mir ernsthaft, seitdem ich mich intensiver mit dem Thema MCP Server beschäftige. Dabei sind mir erstaunliche Parallelen zu meiner früheren Arbeit als UX Designer aufgefallen.

Kurzer Einschub für die UI-Designer

Bevor jetzt Panik ausbricht: UX ist nicht UI. UI ist nur eine von vielen Methoden, um UX-Probleme zu lösen. Und UI-Design wird es auch in der LLM-Welt weiterhin geben – sogar mehr als man denkt.

Google, Anthropic und OpenAI arbeiten parallel an Standards für agentengesteuerte Interfaces – von A2UI über MCP Apps bis AG-UI. Die Ansätze unterscheiden sich, aber der Trend ist klar: UI-Design für LLM-Kontexte wird gerade neu definiert.

Die Frage “Wie präsentiere ich komplexe Daten visuell?” verschwindet also nicht. Sie wird sogar dynamischer und spannender. Aber das ist ein eigenes Thema für einen eigenen Artikel.

Hier soll es um UX im weiteren Sinne gehen. Um die Frage: Was braucht der Nutzer wann – und wie sorgt man dafür, dass er es bekommt?

Was ist MCP überhaupt?

MCP steht für Model Context Protocol. Ein offener Standard, ursprünglich von Anthropic entwickelt, der es Sprachmodellen ermöglicht, auf externe Daten und Werkzeuge zuzugreifen. Mittlerweile haben auch OpenAI und Google den Standard übernommen – alle drei kümmern sich gemeinsam in einer Stiftung darum, MCP als Open Source weiterzuentwickeln. Ein seltenes Beispiel für Zusammenarbeit in einer sonst so kompetitiven Branche.

Die Architektur ist eigentlich simpel: MCP Server stellen sogenannte “Primitives” bereit. Das sind Tools (ausführbare Funktionen wie API-Aufrufe oder Datenbankabfragen), Resources (Datenquellen, die Kontext liefern) und Prompts (wiederverwendbare Vorlagen für bestimmte Aufgaben).

Das LLM entscheidet dann selbstständig, welches Werkzeug es für eine Aufgabe braucht, ruft es auf und bekommt Daten plus Kontext zurück.

Eine gängige Analogie: MCP ist wie ein USB-Port für KI. Eine standardisierte Schnittstelle statt individueller Bastelei für jede einzelne Integration.

Warum Kontext alles ist

Jetzt wird es interessant. Denn der Kontext, den ein MCP Server mitliefert, entscheidet darüber, ob das Sprachmodell dem Nutzer wirklich helfen kann – oder ob es nur Datenmüll weiterreicht.

Ein Beispiel: Eine API liefert die Zahl “123”. Mehr nicht. Was soll ein LLM damit anfangen? Es wird entweder zugeben, dass es keine Ahnung hat, was das bedeutet. Oder – schlimmer – es halluziniert sich irgendetwas zusammen.

Jetzt das gleiche Szenario mit Kontext: “Das ist der Zugangscode für Ihr Hotelzimmer. Sie können ihn direkt in der Lobby am Terminal eingeben, um den Fahrstuhl zu Ihrer Etage freizuschalten. Das Terminal befindet sich links neben der Rezeption. Der Code ist 24 Stunden gültig.”

Plötzlich kann der Nutzer etwas damit anfangen. Keine Rückfragen nötig. Keine Verwirrung. Das LLM kann sogar typische Follow-up-Fragen beantworten: “Wo genau ist das Terminal?” – “Links neben der Rezeption.” “Wie lange gilt der Code?” – “24 Stunden.”

Mit genug Kontext lassen sich Support-Anfragen minimieren. Das LLM kann erklären: wann, wie, warum. Aber eben nur, wenn jemand diesen Kontext vorher durchdacht und bereitgestellt hat.

Und hier kommt User Experience Design ins Spiel

Diese Fragen – welchen Kontext braucht der Nutzer wann? Wie nimmt man Unsicherheiten? Was sind typische Probleme? Wo entstehen Missverständnisse? – das sind klassische UX-Fragen.

Was könnte der Nutzer in dieser Situation wissen wollen? Welche Infos fehlen ihm vermutlich? Welche Ängste hat er vielleicht? Das ist exakt das, was UX Designer seit Jahren machen. Nur dass sie in Zukunft vielleicht keine Screens mehr designen, sondern Kontexte formulieren.

Aber es kommt noch besser. In LLM-Kontexten gibt es sogar mehr Möglichkeiten als in klassischen UIs.

Das Sprachmodell arbeitet im Nutzerkontext. Es weiß, was vorher besprochen wurde. Es kennt vielleicht Präferenzen aus früheren Gesprächen. Und es kann mehrere Tools kombinieren. Beim Hotel-Beispiel: Code liefern, Adresse mitliefern, direkt in Google Maps anzeigen. Eine kontextuelle Hilfe, die früher drei verschiedene Apps gebraucht hätte.

Das LLM ist kein Nutzer – es ist ein Teamkollege

Ein wichtiger Perspektivwechsel: Es wäre falsch, das LLM wie einen zweiten Nutzer zu behandeln, den man auch “bedienen” muss.

Das LLM ist ein Teamkollege. Ein Partner mit dem gleichen Ziel: dem Menschen bestmöglich helfen. Es will helfen. Es braucht nur den richtigen Kontext dafür.

Designer und LLM bilden ein Duo mit gemeinsamer Mission. Man designt nicht für das LLM. Man arbeitet mit dem LLM. Die neue Kernkompetenz wird sein, zu verstehen, wie dieser Partner tickt. Was braucht er, um gut arbeiten zu können? Welche Informationen muss man ihm geben, damit er dem Nutzer die bestmögliche Antwort liefern kann?

Die Toolbox bleibt die gleiche

Und hier ist die gute Nachricht für alle UX-Designer, die sich gerade fragen, ob sie umschulen müssen: Die Techniken und Methoden bleiben relevant. Der Kontext ändert sich, aber die Grundlagen nicht.

User Research? Braucht man immer noch. Wie sonst will man wissen, welche Fragen die Nutzer haben?

Personas? Helfen immer noch dabei, typische Nutzungssituationen zu verstehen.

Journey Mapping? Jetzt eben Conversation Flows, aber das Prinzip ist das gleiche.

Und vor allem: Nutzertests. Der gemeinsame Output – das, was Designer und LLM zusammen produzieren – muss mit echten Menschen getestet werden. Funktioniert der Kontext? Versteht der Nutzer die Antworten? Fehlt etwas?

Das Ergebnis zählt. Und das validiert man wie immer: mit echtem Feedback von echten Menschen. Diese Validierungs-Kompetenz bringen UX-Designer mit. Das ist ihr unfairer Vorteil.

Was sich konkret ändert

Aber natürlich ändert sich auch einiges. Hier meine Hypothesen:

Neue Artefakte: Statt Wireframes werden UX Designer Tool-Descriptions und Kontext-Dokumentation schreiben. Statt User Flows werden sie Conversation Flows und Use Cases mappen. Statt Microcopy werden sie Kontext-Texte formulieren, die das LLM verstehen und sinnvoll weitergeben kann.

Neue Fragen im Alltag: “Welche Informationen braucht das LLM, um dem User hier gut helfen zu können?” “Welche Missverständnisse könnten entstehen, wenn dieser Kontext fehlt?” “Wie formuliert man das so, dass das LLM es richtig interpretiert?”

Skills, die wichtiger werden: Copywriting und präzises Texten. Empathie für den Endnutzer – das bleibt sowieso. Verständnis für LLM-Verhalten – das ist neu. Und Systemdenken: Wie greifen mehrere Tools und Services ineinander?

Skills, die weniger wichtig werden: Pixelgenaues Visual Design, zumindest für reine Chat-Interfaces. Klassisches Interaction Design mit Buttons und Menüs – teilweise, nicht komplett.

Was gleich bleibt: User Research. Usability Testing. Iteration basierend auf echtem Feedback. Und die Grundfrage: Hilft das dem Menschen wirklich?

Mein Fazit

Also: Wer braucht noch UX Designer?

Mehr Leute denn je. Nur anders.

Das Medium ändert sich. Weniger UI, mehr Text. Mehr Kontext. Copywriting wird wichtiger. Die Fähigkeit, sich in Sprachmodelle hineinzuversetzen, kommt dazu.

Aber die Grundfragen bleiben gleich. Und die Validierung durch echte Nutzer ist weiterhin unerlässlich. Vielleicht sogar wichtiger als je zuvor – denn wenn niemand testet, ob der Kontext funktioniert, merkt man Probleme erst, wenn echte Nutzer frustriert sind.

Fragen, die ich mir noch stelle

Wie testet man Kontext-Qualität systematisch? Gibt es dafür Methoden, Metriken?

Braucht es neue Rollen? “LLM Experience Designer”? “Context Architect”? Oder ist das einfach die Evolution von dem, was UX Designer schon machen?

Wie sieht die Zusammenarbeit zwischen UX, Entwicklung und LLM in der Praxis aus? Wer ist verantwortlich für was?

Falls du Antworten hast oder ähnliche Beobachtungen machst – ich bin neugierig.