UI vs UX: Der wahre Unterschied (und warum die meisten Erklärungen falsch liegen)
UI ist nicht das Geschenkpapier. UX ist nicht das Geschenk. Der wahre Unterschied zwischen UI und UX, was jede Rolle wirklich macht und wen man wofür einstellt.
UI ist nicht das Geschenkpapier. UX ist nicht das Geschenk. Und UI ist auch nicht die Ketchupflasche, und UX ist nicht das Einschenken des Ketchups.
Jeder „UI vs UX"-Erklärartikel im Internet versteckt sich hinter einer Analogie, weil der Autor keinen der beiden Jobs je wirklich gemacht hat. Die Ketchupflaschen-Analogie hat einer ganzen Generation von Designern absolut nichts beigebracht. Eine Ketchupflasche hat keine Aufgabenhierarchie, keine User Research, keine Fehlermodi, keine Erfolgsmetriken, keine Edge Cases bei 390px. Du lieferst kein Würzmittel aus. Du lieferst Software.
Dieser Artikel beerdigt die Analogien, definiert jede Disziplin in einem Satz, zeigt was jede Rolle täglich wirklich liefert und gibt dir ein Einstellungs-Framework an die Hand, das du morgen nutzen kannst.
Die Analogien sind das Problem
Die gängigen Erklärungen behandeln UI und UX als physische Metaphern, weil Metaphern einfacher zu schreiben sind als Definitionen. Der Preis dafür: Jeder Junior-Designer kommt zu seinem ersten Job in dem Glauben, UI sei „Farben und Schriften" und UX sei „das Gefühl". Beides ist falsch.
„UI ist das Auto, UX ist die Fahrt" sagt dir nichts über Informationsarchitektur. „UI ist das Haus, UX ist das Darin-Wohnen" sagt dir nichts über Journey Mapping. „UI ist visuell, UX ist Interaktion" ist die häufigste Version und gleichzeitig die am meisten falsche. UI-Designer verbringen einen großen Teil ihrer Woche mit Interaktionszuständen. UX-Designer verbringen einen großen Teil ihrer Woche mit visuellen Entscheidungen wie Informationsdichte und Layout-Hierarchie. Die Grenze verläuft nicht dort, wo die Analogien sie ziehen.
Wirf das alles weg. Fang damit an, was jede Disziplin tatsächlich entscheidet.
Die echte Definition, je ein Satz
UX ist die Entscheidungsarchitektur. UI ist der Ausdruck dieser Entscheidungen auf dem Bildschirm. Das ist alles.
UX fragt, was existieren soll und wann. Welche Screens dieses Produkt braucht. In welcher Reihenfolge der Nutzer sie durchläuft. Welche Informationen bei jedem Schritt erscheinen. Was passiert, wenn der Nutzer verwirrt, im Irrtum oder in Eile ist. Wie Erfolg aussieht und woher wir das wissen.
UI fragt, wie diese Entscheidungen aussehen, sich anfühlen und sich bewegen, sobald sie auf dem Bildschirm sind. Was die Hierarchie ist, was die Typografie sagt, wie sich ein Button beim Drücken verhält, wie ein Modal eintritt, was ein deaktivierter Zustand kommuniziert, wie das Ganze über fünfzig Screens und drei Geräte hinweg kohärent bleibt.
Dasselbe Produkt. Zwei verschiedene Entscheidungsebenen. Eine kann nicht ohne die andere ausgeliefert werden.
Was ein UX-Designer wirklich macht
Die Woche eines UX-Designers besteht größtenteils aus Research und Struktur, nicht aus Screens.
Er führt User Interviews durch, reviewt Session Recordings und erstellt Journey Maps. Er skizziert Informationsarchitektur, entscheidet über Taxonomie und streitet mit Product Managern darüber, was ein Feature überhaupt ist. Er skizziert Flows. Er baut Wireframes, die niemand anschauen möchte, weil sie absichtlich hässlich sind. Er validiert Annahmen, indem er Prototypen mit echten Nutzern testet, und er streicht Features, die schlecht abschneiden.
Typische UX-Deliverables:
- Synthese aus User Research und Personas
- Journey Maps und Flow-Diagramme
- Informationsarchitektur und Content-Modelle
- Low-Fidelity-Wireframes
- Usability-Testpläne und -Berichte
- Erfolgsmetriken und Instrumentierungs-Spezifikationen
Der UX-Designer ist die Person, die fragt „Sollte dieser Screen überhaupt existieren", bevor irgendjemand fragt „Welche Farbe hat der Button".
Was ein UI-Designer wirklich macht
Die Woche eines UI-Designers ist das genaue Gegenteil. Er entscheidet, wie das Ding aussieht und sich verhält, sobald UX entschieden hat, was es ist.
Er baut visuelle Systeme. Er legt Type Scale, Color Tokens, Spacing-Rhythmus und Komponenten-Spezifikationen fest. Er gestaltet jeden Interaktionszustand (default, hover, active, focus, disabled, loading, empty, error). Er definiert Motion-Regeln. Er arbeitet akribisch an der Pixel-Hierarchie über Breakpoints hinweg und sorgt dafür, dass sich das Produkt auf jedem Screen wie ein einziges Produkt anfühlt. Er liefert die Component Library und die Design Tokens, die das Engineering tatsächlich verwendet.
Typische UI-Deliverables:
- Visuelles Design-System (Type, Color, Spacing, Grid)
- Component Library mit allen Interaktionszuständen
- Design Tokens als Code-Export
- Motion- und Transition-Spezifikationen
- High-Fidelity-Screens und hochauflösende Mockups
- Hand-off-Dokumentation für das Engineering
Der UI-Designer ist die Person, die dafür verantwortlich ist, dass das Produkt kohärent und lebendig wirkt, nicht nur funktional.
Wo die Überschneidung liegt
In der Mitte entstehen gute Produkte.
Prototyping ist geteilt. Beide Rollen bauen Prototypen: UX zur Validierung von Flows, UI zur Validierung von Motion und Polish. User Testing ist geteilt. UX gestaltet den Test, UI beobachtet, ob die eigenen visuellen Entscheidungen das Verständnis fördern oder behindern. Design Reviews sind per Definition geteilt, und sie funktionieren nur, wenn beide Perspektiven im Raum sind.
Hier ist die unbequeme Wahrheit: Ein UI-Designer, der UX nicht versteht, liefert hübsche Sackgassen. Ein UX-Designer, der nicht visuell umsetzen kann, liefert Strategie-Decks, die niemand umsetzt. Die Guten entwickeln genug Reichweite auf der anderen Seite, um Arbeit zu liefern, die den ersten Kontakt mit Nutzern übersteht. Die Besten werden zu Product Designern, dazu kommen wir noch.
Die Product-Designer-Frage
„Product Designer" ist der Titel, der das Mittelfeld verschluckt hat, und im Jahr 2026 bedeutet er eine Person, die sowohl UI als auch UX auf einem glaubwürdigen Niveau macht.
In einem Startup ist ein Product Designer oft der einzige Designer im Unternehmen. Er besitzt Research, Flows, Wireframes, visuelles System, Komponenten und Motion. Er ist ein Ein-Personen-Design-Team, und das funktioniert, weil ein Startup sich nur eine Person leisten kann und beide Hälften der Disziplin braucht.
In einem größeren Unternehmen besitzt ein Product Designer normalerweise einen Produktbereich von Anfang bis Ende und arbeitet mit spezialisierten UX-Researchern, Design-System-Teams und manchmal einem Motion Designer zusammen. Er ist der generalistische Operator, kein Junior-Hybrid.
Der Fehler, den die meisten Gründer machen: Sie stellen einen „Product Designer" ein, wenn sie eigentlich einen Senior UX Researcher brauchen, oder einen „UI Designer", wenn sie eigentlich einen Product Designer brauchen. Titel-Inflation verdeckt die eigentliche Frage: Was ist das eigentliche Problem, und welche Skill-Kombination löst es.
Tools, Prozesse, Ergebnisse
Ein schneller Vergleich. Das ist die komprimierte Version, keine vollständige Spec.
| Dimension | UX Designer | UI Designer | Product Designer |
|---|---|---|---|
| Kernfrage | Was soll existieren, und wann | Wie soll es aussehen, sich anfühlen, sich bewegen | Beides, von Anfang bis Ende |
| Wichtigste Tools | Figma, Miro, Dovetail, Maze | Figma, Framer, Principle | Figma, Framer, leichter Code |
| Wichtigste Deliverables | Research, Flows, IA, Wireframes | Visuelles System, Komponenten, States | All das, für einen Produktbereich |
| Liefert | Validierte Pläne | Pixelgenaue Screens + Komponenten | Validierte, ausgelieferte Features |
| Erfolgsmetrik | Task Success Rate, Time on Task | Visuelle Konsistenz, Usability Scores | Produktmetriken (Aktivierung, Retention) |
| Arbeitet am engsten mit | PMs, Researchern, Analysten | Brand, Design Systems, Frontend | PMs, Engineers, allen |
UI-Designer stützen sich auf visuelle Hierarchie, Token-Systeme und Layout-Muster wie Bento Grids, um Screens auf einen Blick lesbar zu machen. UX-Designer stützen sich auf Research-Schleifen, Flow-Tests und Barrierefreiheits-Audits, um sicherzustellen, dass das Produkt für alle funktioniert, für die es funktionieren muss. Product Designer leben in beiden Räumen und besitzen am Ende meist auch Landing-Page-Strukturen, weil Conversion-Arbeit nicht sauber in eine der beiden Spezialistenrollen passt.
Was Tools betrifft: Alle nutzen Figma. Über Tools zu streiten ist die Art, wie Designer es vermeiden, über die eigentliche Arbeit zu streiten. Wer eine kompakte Liste der lohnenswerten Plugins sucht, findet sie im Artikel zu Figma Plugins, die sich lohnen.
Wann man UI, UX, beide oder einen Product Designer einstellt
Das ist der Abschnitt, den du dir merken solltest.
Nutze die Tabelle. Ordne deine Situation einer Zeile zu, stelle die Rolle in der letzten Spalte ein.
| Phase | Kernproblem | Team heute | Einstellen |
|---|---|---|---|
| Pre-Launch, kein Designer | Alles muss entschieden und gebaut werden | Nur Gründer und Engineers | Product Designer |
| Pre-Launch, hat einen UI-Contractor | Das Produkt sieht gut aus, aber Nutzer verlieren sich | UI-Contractor, kein UX | UX Designer (Vollzeit oder Senior-Freelance) |
| Erste Einnahmen, Skalierung | Flows funktionieren, aber das Produkt wirkt veraltet und inkonsistent | 1 UX / Product Designer | UI Designer oder Design Systems Lead |
| Skalierung, hohes Nutzervolumen | Drop-off in bestimmten Flows, Ursache unklar | 1 Product Designer, überlastet | UX Researcher (Spezialist), kein weiterer Generalist |
| Reifes Unternehmen, Multi-Produkt | Konsistenzprobleme zwischen Produkten | Mehrere Product Designer | Design Systems Team + Principal UX |
| Agentur, Kundenarbeit | Muss vollständige Projekte von Anfang bis Ende liefern | Kleines Team | Product Designer + ein geteilter UX Researcher |
Drei Abkürzungen, die die meisten Gründer vor Fehlgriffen bewahren:
- Wenn dein Produkt ein UX-Problem hat, das als UI-Problem verkleidet ist, macht das Einstellen eines UI-Designers es schlimmer. Du bekommst eine schöne Version eines verwirrenden Produkts. Die Verwirrung wird teurer zu beheben sein, weil sie jetzt absichtlich aussieht.
- Wenn du einen Design-Platz hast, stelle einen Product Designer ein. Spezialisten machen erst Sinn, wenn du das Volumen hast, um sie vollständig auszulasten.
- Wenn ihr debattiert „Brauchen wir einen UX Designer oder einen UI Designer", braucht ihr wahrscheinlich einen Product Designer und ein klareres Product Brief.
FAQ
Ist UI oder UX wichtiger?
Keines von beidem. Ein Produkt mit großartigem UX und schlechtem UI verliert gegen seinen Konkurrenten bei der wahrgenommenen Qualität. Ein Produkt mit großartigem UI und schlechtem UX verliert bei der tatsächlichen Nutzung. Sie sind zwei Hälften eines Jobs, und nur eine auszuliefern bedeutet, ein halbes Produkt auszuliefern.
Kann eine Person sowohl UI als auch UX machen?
Ja, und diese Person heißt normalerweise Product Designer. Die meisten Startups in der Frühphase werden von einem starken Generalisten besser bedient als von einer Junior-UI/UX-Aufteilung. Die Spezialisierung zahlt sich erst aus, wenn das Team über einen Designer hinausgewachsen ist.
Müssen UX-Designer coden können?
Nein, aber zu verstehen, wie Dinge gebaut werden, macht sie besser. Ein UX-Designer, der weiß, was im Code günstig, teuer oder unmöglich ist, liefert Flows, die das Engineering tatsächlich umsetzen kann. Das ist kein Coding-Job. Es ist ein Systems-Literacy-Job.
Was ist der Gehaltsunterschied zwischen UI- und UX-Designern?
In den meisten Märkten zahlen die beiden Titel auf demselben Senioritätsniveau ähnlich. Product-Designer-Titel tendieren dazu, auf demselben Niveau mehr zu zahlen als beide Spezialisten-Titel, weil die Rolle beide Skill Sets verlangt. Der größere Treiber des Gehalts ist die Unternehmensphase und die Branche, nicht UI vs UX.
Stelle die Rolle ein, die zum Problem passt
Hör auf zu fragen, was der Unterschied zwischen UI und UX ist. Fang an zu fragen, welches spezifische Problem du lösen möchtest und welche Deliverables dich dorthin bringen.
UX liefert Pläne, die den Kontakt mit echten Nutzern überstanden haben. UI liefert Screens, die sich über fünfzig Oberflächen wie ein einziges Produkt anfühlen. Product Designer liefern beides, von Anfang bis Ende, für einen Produktbereich. Wähle die Rolle, die zum Problem passt, das du wirklich hast, nicht den Titel, der im Organigramm am teuersten klingt.
Jeder mittelmäßige Erklärartikel im Internet wird weiterhin die Ketchupflasche recyceln. Du musst das nicht. Du hast ein Produkt auszuliefern und ein Team dafür aufzubauen.
Need to figure out whether your product needs a UI designer, a UX designer, or both? Brainy builds the team for the problem, then ships the work.
Get Started
