UX-Designer-Skill-Matrix & Kompetenzrahmen nach Level

Eine gemeinsame UX-Designer-Skill-Matrix gibt Ihnen eine klare Sprache für Erwartungen: Was bedeutet „gute Arbeit“ je Level – und woran sieht man sie? Damit werden Feedbackgespräche konkreter, Beförderungen besser begründbar und Entwicklungspläne leichter priorisierbar. Gleichzeitig sinkt die Streuung zwischen Teams, weil ähnliche Arbeit ähnlich bewertet wird.

Eine Matrix bleibt nur lebendig, wenn sie in Reviews und Entwicklungsgesprächen genutzt wird. Am einfachsten gelingt das in Talentmanagement-Software statt in einer vergessenen Tabelle.

Kompetenzbereich	Junior UX Designer	Mid UX Designer	Senior UX Designer	Lead UX Designer
UX Research & Discovery	Führt einfache Discovery-Aufgaben mit Anleitung durch und dokumentiert Learnings verständlich. Nutzt Ergebnisse, um einen klar abgegrenzten Flow messbar zu verbessern.	Plant und führt Mixed-Methods-Discovery für einen Problemraum durch und übersetzt Findings in Design-Entscheidungen. Markiert Evidenzlücken vor großen Entscheidungen.	Setzt eine Research-Strategie für einen Produktbereich auf und verbindet Insights mit User- und Business-Outcomes. Moderiert Trade-offs, wenn Evidenz uneindeutig ist.	Definiert Discovery-Standards und Roadmaps teamübergreifend (Rigor, Ethik, Datenschutz). Macht User-Impact für Leadership sichtbar und beeinflusst Priorisierung.
Interaction Design & Information Architecture	Designt klare Interaktionen für klar gescopte Aufgaben und nutzt bestehende Patterns. Reduziert Verwirrung in Standardszenarien.	Entwirft End-to-End-Journeys für ein Feature-Set und validiert IA mit Nutzer:innen und Daten. Deckt Edge Cases ab und erfüllt Accessibility-Basics.	Löst komplexe, mehrstufige Workflows über mehrere Oberflächen hinweg und senkt kognitive Last durch starke Struktur. Verbessert Usability auf System-, nicht nur Screen-Level.	Definiert Interaction-Prinzipien für die Produktsuite und richtet Navigation/IA teamübergreifend aus. Löst Teamkonflikte über eine kohärente Experience-Strategie.
Visual/UI Craft	Liefert sauberes UI im Design System und übergibt konsistent an Engineering. Iteriert schnell, ohne Inkonsistenzen einzubauen.	Balanciert Ästhetik, Klarheit und Constraints, damit UI Task Success unterstützt. Verbessert Hierarchie, Spacing und States für skalierende Screens.	Hebt Craft-Qualität im Produktbereich und verhindert „tausend kleine Inkonsistenzen“. Coacht mit konkreter, wiederverwendbarer Kritik.	Setzt Qualitätsmaßstäbe über Teams hinweg und stabilisiert Konsistenz trotz Tempo und Komplexität. Etabliert Mechanismen wie Reviews, Examples, Tokens und Audits.
Prototyping & Tools	Baut Prototypen, um Flows zu erklären und Basisfeedback einzuholen. Wählt mit Unterstützung die passende Fidelity zur Fragestellung.	Nutzt Prototypen, um Interaktionen zu de-risken, Stakeholder auszurichten und kritische Pfade zu testen. Hält Dateien so strukturiert, dass andere wiederverwenden können.	Wählt für komplexe Systeme die passende Prototyping-Methode und beschleunigt Entscheidungen. Standardisiert Templates/Workflows und erhöht Team-Effizienz.	Definiert Tooling-Practices, die teamübergreifend Reibung reduzieren (Libraries, Naming, Branching, Doku). Stellt sicher, dass Prototyping Strategie unterstützt, nicht nur Präsentation.
Design Systems & Consistency	Verwendet Komponenten korrekt und meldet Lücken mit konkreten Beispielen. Vermeidet One-offs ohne klaren Grund.	Verbessert System-Komponenten und Guidelines aus Produktbedarfen heraus. Unterstützt Adoption durch pragmatische Doku und Enablement.	Treibt System-Evolution über Governance und klare Entscheidungskriterien. Reduziert Rework durch abgestimmte Contribution-Workflows.	Verantwortet System-Strategie über Produkte hinweg (Brand, Accessibility, Skalierbarkeit). Richtet Design, Engineering und Product auf langfristige Konsistenz-Investments aus.
Collaboration & Communication	Erklärt Design-Intention klar in Reviews und Handoffs. Baut Vertrauen auf, indem Input früh eingeholt und sauber nachgehalten wird.	Moderiert produktive Critiques und klärt Scope/Constraints mit Engineering und Product. Dokumentiert Entscheidungen, damit Teams ohne Meeting-Schleifen liefern können.	Geht mit Konflikten und Ambiguität um, ohne Delivery zu bremsen, und hält Diskussionen outcome-orientiert. Verbessert Entscheidungsqualität über Funktionen hinweg.	Etabliert Routinen, die Missverständnisse und Doppelarbeit reduzieren. Schafft psychologische Sicherheit und erhöht Entscheidungsqualität auf Leadership-Ebene.
Strategy, Impact & Measurement	Kennt Erfolgsmetriken für zugewiesene Aufgaben und designt darauf hin. Teilt Learnings nach Releases für bessere Iterationen.	Definiert Hypothesen und Success Criteria und bewertet Outcomes mit Data-Partnern. Priorisiert Arbeit nach User- und Produktimpact.	Verknüpft UX-Arbeit mit Produktstrategie und misst Impact über Zeit, nicht nur zum Launch. Lenkt Teams weg von Vanity Metrics hin zu entscheidungsfähigen Signalen.	Formt Experience-Strategie über Teams hinweg und beeinflusst Roadmaps mit Evidenz und Impact-Narrativen. Etabliert Messgewohnheiten, die UX-Wert für Executives sichtbar machen.
Mentoring & Craft Leadership	Holt Feedback aktiv ein, setzt es um und teilt Learnings mit Peers. Verbessert Craft durch bewusstes Üben.	Unterstützt Juniors über Reviews und konkrete Anleitung. Hebt Team-Output durch Patterns, Beispiele und leichtgewichtige Trainings.	Mentort kontinuierlich mit klaren Zielen und evidenzbasiertem Feedback. Baut Communities, die Qualität und Konsistenz erhöhen.	Entwickelt Talent-Systeme (Career Ladders, Rubrics, Calibration-Habits) und baut zukünftige Leads auf. Sichert, dass Craft Leadership über Einzelpersonen hinaus skaliert.

Wichtigste Erkenntnisse

Erwartungen vor Feedback klären – nicht erst im Review.
Nachweise je Kompetenzbereich sammeln, damit Beförderungen vergleichbar bleiben.
„Strategischer werden“ als beobachtbare Verhaltensanker pro Level formulieren.
Kalibrierungsrunden nutzen, um Bias und Team-Streuung zu reduzieren.
Entwicklung auf zwei Bereiche fokussieren, statt acht parallel zu „optimieren“.

Definition des Frameworks

Diese UX-Designer-Skill-Matrix ist ein gestuftes Kompetenzmodell für UX Designer:innen (Junior bis Lead). Sie beschreibt beobachtbare Verhaltensanker und erwartete Ergebnisse je Kompetenzbereich. Sie nutzen sie für Rollenprofile, Hiring-Scorecards, Performance Reviews, Peer-Feedback und Beförderungsentscheidungen – mit gemeinsamen Evidenzstandards, damit Bewertungen zwischen Teams vergleichbar bleiben. Mehr Kontext zur Einbettung in Skill Management hilft, das Framework als Prozess statt als Tabelle zu nutzen.

Skill-Level & Verantwortungsbereich der UX-Designer-Skill-Matrix

Leveling funktioniert am saubersten über Scope, Ownership und Influence – nicht über Geschmack, Selbstbewusstsein oder Jahre im Job. Fragen Sie im Zweifel: „Welche Entscheidungen kann diese Person sicher treffen – und wie weit reicht ihr Impact?“

Hypothetisches Beispiel: Zwei Designer:innen shippen beide eine neue Settings-Seite. Mid validiert sie mit Nutzer:innen und iteriert sauber. Senior löst zusätzlich einen Konflikt zu Navigations-Patterns, damit die Lösung über die Produktsuite skaliert.

Level	Verantwortungsbereich	Entscheidungsfreiheit	Typischer Beitrag zum Ergebnis
Junior UX Designer	Ein klar abgegrenzter Task oder Feature-Slice innerhalb bestehender Patterns. Fokus auf saubere Ausführung und Lernkurve in Methoden.	Trifft tägliche Design-Entscheidungen im definierten Scope und holt Richtungssicherheit bei Senior/Lead ein. Eskaliert Unsicherheiten früh statt spät.	Stabiler Output: verständliche Screens, weniger Missverständnisse, saubere Handoffs. Reduziert Rework durch Klarheit und Dokumentation.
Mid UX Designer	Feature-Bereich oder End-to-End-Flow von Discovery bis Iteration. Koordiniert Abhängigkeiten in einem überschaubaren Umfeld.	Setzt Designrichtung für den eigenen Bereich und begründet Trade-offs mit Evidenz. Kann Entscheidungen ohne ständige Freigaben vorantreiben.	Weniger Rework-Loops, bessere Abstimmung mit Engineering, messbare Usability-Verbesserungen. Liefert zuverlässig über Releases hinweg.
Senior UX Designer	Produktbereich mit hoher Komplexität: mehrere Stakeholder, System-Constraints, konkurrierende Ziele. Rahmt Probleme und priorisiert Unsicherheit.	Entscheidet, welches Evidenzniveau „gut genug“ ist, und steuert Ambiguität. Beeinflusst Entscheidungen über Teams/Funktionen hinweg.	Höhere Entscheidungsqualität, konsistente User Journeys, weniger Cross-Team-Reibung. Macht Constraints produktiv statt blockierend.
Lead UX Designer	Mehrere Teams oder Produktlinie inklusive Standards und langfristiger Experience-Kohärenz. Baut Mechanismen, die Qualität skalieren.	Setzt Prioritäten für UX-Investments, definiert Standards und schafft Alignment-Routinen. Delegiert klar und macht Teams unabhängig.	Konsistente Experiences, schnellere teamübergreifende Execution, stärkerer UX-Influence in Roadmap-Diskussionen. Reduziert Drift und doppelte Arbeit.

Definieren Sie „Scope“ explizit: Feature, Produktbereich oder Multi-Team-Experience.
Schreiben Sie Decision Rights je Level auf: was ohne Eskalation entschieden wird.
Trennen Sie Output (Screens) von Outcome (weniger Fehler, schnellere Task Completion).
Nutzen Sie Evidenz aus den letzten 6–12 Monaten statt Karriere-Highlights.
Dokumentieren Sie Leveling-Entscheidungen für Konsistenz über Manager hinweg.

Kompetenzbereiche in der UX-Designer-Skill-Matrix

Eine gute Matrix balanciert Craft und Impact. Bewerten Sie nur Craft, belohnen Sie polierte Screens ohne Adoption. Bewerten Sie nur Impact, bleibt unklar, ob Outcomes durch Glück, starke Zusammenarbeit oder wiederholbare Praxis entstanden sind.

Hypothetisches Beispiel: Ein DACH-SaaS-Team sieht Onboarding-Drop-off. Mit der Matrix teilen Sie sauber auf: eine Person verantwortet Discovery, eine Konsistenz im System, Senior prüft Measurement und Success Criteria.

1) UX Research & Discovery

Ziel ist, Unsicherheit früh zu senken, bevor Design teuer wird. Typische Outcomes: klare Problemdefinition, priorisierte Opportunities und Entscheidungen mit nachvollziehbarer Evidenz.

2) Interaction Design & Information Architecture

Ziel ist, Tasks, Navigation und Flows so zu strukturieren, dass Nutzer:innen schnell und fehlerarm ans Ziel kommen. Outcomes zeigen sich in weniger Supportfällen, weniger Fehlern und stabilen Mental Models.

3) Visual/UI Craft

Ziel ist klare Hierarchie, Konsistenz und zugängliche UI-Ausführung. Outcomes: schnellere Orientierung, weniger Inkonsistenzen, besser skalierende Screens über Devices.

4) Prototyping & Tools

Ziel ist schnellere Entscheidungen durch passende Prototypen und saubere Tool-Artefakte. Outcomes: kürzere Alignment-Zyklen und weniger Ambiguität für Engineering.

5) Design Systems & Consistency

Ziel ist skalierbare Patterns, Governance und weniger UI-Drift. Outcomes: weniger One-offs, geringere Maintenance-Kosten, schnelleres Shipping durch Wiederverwendung.

6) Collaboration & Communication

Ziel ist Klarheit mit Stakeholdern und weniger Koordinationsaufwand. Outcomes: weniger Rework, schnellere Entscheidungen, weniger „Design vs Engineering“-Deadlocks.

7) Strategy, Impact & Measurement

Ziel ist, UX-Arbeit an Produktstrategie und messbare Wirkung zu koppeln. Outcomes: bessere Priorisierung, klarere Hypothesen und belastbare Post-Launch-Learnings.

8) Mentoring & Craft Leadership

Ziel ist ein Multiplikator-Effekt: Qualität steigt nicht nur in der eigenen Arbeit, sondern im Team. Outcomes: schnelleres Ramp-up, stabilere Standards und weniger Abhängigkeit von Einzelpersonen.

Halten Sie 6–8 Kompetenzbereiche mindestens zwei Zyklen stabil, dann erst anpassen.
Definieren Sie pro Bereich 3–5 konkrete Artefakt- und Outcome-Beispiele aus Ihrem Kontext.
Legen Sie fest, was „gute Evidenz“ ist: Dokumente, Daten, Feedback, Entscheidungsverlauf.
Erlauben Sie Stärkenprofile je Level; erwarten Sie nicht „Senior in allem“.
Reviewen Sie die Bereiche jährlich, besonders nach Reorgs oder Plattformwechseln.

Bewertungsskala & Nachweise für die UX-Designer-Skill-Matrix

Ratings scheitern, wenn sie vage sind oder auf Selbstsicherheit beruhen. Nutzen Sie eine klare Skala, definieren Sie jedes Rating und fordern Sie Evidenz. In dieser UX-Designer-Skill-Matrix beschreibt das Rating die nachgewiesene Fähigkeit im Bereich; das Level beschreibt Scope- und Impact-Erwartung.

Rating	Label	Beobachtbare Bedeutung	Typische Nachweise
1	Awareness	Kann Konzepte erklären und vorhandene Guidelines anwenden, braucht enges Coaching.	Notizen aus Critiques, kleine Tasks, Lernlog, begleitete Deliverables.
2	Basic	Liefert eigenständig bei gut gescoptem Work und weiß, wann Hilfe nötig ist.	Shipped Screens/Flows, klarer Handoff, einfache Research-Notizen, Peer-Feedback.
3	Skilled	Löst nicht-triviale Probleme, passt Methoden an Kontext an und liefert wiederholbare Outcomes.	End-to-End-Featurearbeit, validierte Entscheidungen, Decision Logs, messbare Verbesserungen.
4	Advanced	Steuert Ambiguität, hebt Standards und verbessert Outcomes über Stakeholder/Constraints hinweg.	Cross-Team-Alignment, Systemänderungen, komplexe Workflows, Coaching-Nachweise.
5	Expert	Setzt Richtung, skaliert Praktiken und baut Mechanismen, auf die andere sich verlassen.	Frameworks, System-Governance, Strategie-Influence, nachhaltiger Multi-Team-Impact.

Evidenz sollte aus mehreren Quellen kommen: shipped Work, Research-Artefakte, Entscheidungsdokumentation, Stakeholder-Feedback und Post-Launch-Learnings. Wenn Sie Reviews bereits strukturiert fahren, koppeln Sie die Evidenzfelder an Ihre Performance-Management-Routinen, damit Ratings nicht zur Spreadsheet-Übung werden.

Mini-Beispiel	Was passiert ist	Wie Sie es einstufen (warum Level unterschiedlich wirken)
Fall A vs. Fall B: „Komplexen Formular-Flow verbessert“	Beide redesignen den Flow; nach Release sinkt Verwirrung messbar.	Mid wird höher bewertet, wenn Validierung und Edge Cases eigenständig gelöst wurden. Senior wird höher bewertet, wenn zusätzlich Cross-Team-Patterns ausgerichtet, Success Criteria gesetzt und Skalierung sichergestellt wurden.
Fall A vs. Fall B: „Neue Komponente hinzugefügt“	Beide liefern eine neue Komponente ins System.	Mid wird höher bewertet, wenn Nutzung klar dokumentiert und im Produkt sauber umgesetzt ist. Senior/Lead wird höher bewertet, wenn Governance, Adoption und Deprecation-Pfade definiert und genutzt werden.
Fall A vs. Fall B: „User Interviews geführt“	Beide führen Interviews und teilen Insights.	Mid wird höher bewertet, wenn Insights direkt zu nachvollziehbaren Design-Entscheidungen führen. Senior/Lead wird höher bewertet, wenn Insights Priorisierung beeinflussen und strategische Unsicherheit reduzieren.

Nutzen Sie die gleiche Skala über UX-Rollen hinweg, damit Kalibrierung leichter wird.
Fordern Sie für Beförderungen pro Bereich mindestens 2–3 starke Evidenzbeispiele.
Timeboxen Sie Evidenz auf 6–12 Monate, um Recency Bias zu senken.
Trennen Sie „Potenzial“ von Performance-Ratings, damit Reviews konkret bleiben.
Speichern Sie Evidenz zentral, damit Peers und Manager konsistent reviewen können.

Entwicklungssignale & Warnzeichen

Wachstum zeigt sich als stabile Verhaltensmuster, nicht als ein heroisches Projekt. Nutzen Sie Signale, um Readiness für mehr Scope zu erkennen, und Warnzeichen, um Support gezielt zu planen. So bleibt die UX-Designer-Skill-Matrix ein Entwicklungswerkzeug, kein Strafkatalog.

Hypothetisches Beispiel: Ein Mid möchte Senior werden. Über zwei Quartale sehen Sie, dass Abhängigkeiten proaktiv gelöst werden und Messdaten die Iteration steuern – nicht nur der Launch.

Entwicklungssignale (Readiness-Indikatoren)

Liefert konsistente Outcomes über verschiedene Problemtypen, nicht nur einen Flow.
Reduziert Unsicherheit früh durch passende Research- und Validierungsschritte.
Überzeugt Stakeholder mit klarer Begründung, Evidenz und transparenten Trade-offs.
Schafft wiederverwendbare Patterns, Doku oder Templates, die Teamzeit sparen.
Deeskaliert Konflikte und verbessert Entscheidungen ohne ständige Eskalation.

Warnzeichen (typische Beförderungsblocker)

Stützt Entscheidungen auf Meinung, obwohl Evidenz realistisch möglich ist.
Baut One-offs, die Inkonsistenz und spätere Maintenance-Kosten erhöhen.
Übersieht wiederholt Edge Cases, was zu Rework oder vermeidbaren Bugs führt.
Arbeitet im Silo: späte Handoffs, Überraschungsdesigns, unklare Decision Trails.
Optimiert Politur, während die Kernaufgabe für Nutzer:innen schwer bleibt.

Tracken Sie Signale über Zeit; entscheiden Sie nicht auf Basis eines Projekt-Peaks.
Formulieren Sie Next-Level-Erwartungen als 3–5 beobachtbare Verhaltensanker pro Bereich.
Nutzen Sie Warnzeichen für Support-Pläne – nicht als Label für Personen.
Holen Sie Peer-Input dort ein, wo Zusammenarbeit zentral ist (Eng, PM, Research).
Machen Sie „Readiness“ explizit: Scope-Erweiterung, Autonomie, Influence.

Team-Check-ins & Bewertungsrunden

Die UX-Designer-Skill-Matrix funktioniert am besten in kurzen Zyklen statt nur im Jahresgespräch. Häufige Check-ins erzeugen bessere Evidenz, senken „wer erinnert sich woran“ und entladen Feedback emotional. Sauber umgesetzt stärkt das psychologische Sicherheit, weil Sie über Verhalten und Outcomes sprechen – nicht über Persönlichkeit.

Takt	Format	Teilnehmende	Inputs	Output
Alle 2–4 Wochen	1:1 Growth Check-in	Designer:in + Manager:in	Aktuelle Arbeit, Blocker, Evidenz-Snippets	1–2 Fokusbereiche und nächste Aktionen
Monatlich	Portfolio-/Critique-Review	Design-Team	Work-in-progress, Begründung, Trade-offs	Craft-Feedback, verknüpft mit Kompetenzbereichen
Quartalsweise	Evidenz-Review	Designer:in + Manager:in (Peer optional)	Evidenzpaket nach Kompetenzbereichen	Aktualisierte Ratings, Anpassung Entwicklungsplan
2× pro Jahr	Kalibrierungsrunde	Leads/Manager + Facilitator	Ratings + Evidenz + Scope-Notizen	Abgestimmte Level-Entscheidungen, dokumentierte Grenzfälle

Für die wiederkehrenden Gespräche hilft eine konsistente Struktur aus wirksamen 1:1-Meetings: kurzer Kontext, Evidenz, Entscheidung, nächste Schritte. Viele Teams dokumentieren das in Tools wie Sprad Growth oder in einem gemeinsamen Dokument; entscheidend ist die Einheitlichkeit, nicht das System.

Wie Sie Bewertungen zwischen Manager:innen ausrichten: gleiche Evidenz-Pakete, Start mit Grenzfällen, dann ein schneller Bias-Check (Recency, Halo/Horn, Similar-to-me, „Style vs Outcome“). Wenn Sie eine strukturierte Facilitation brauchen, nutzen Sie Vorlagen aus einem Talent-Calibration-Guide und passen Sie sie an Design-Craft-Kontexte an.

DACH-Hinweis (unverbindlich, keine Rechtsberatung): Wenn Sie mit einem Betriebsrat arbeiten, binden Sie ihn früh ein, sobald Rating-Prozesse, Tools oder Datensichtbarkeit geändert werden. Viele Organisationen regeln Leitplanken in einer Dienstvereinbarung (Zugriffsrechte, Aufbewahrung, Zweckbindung der Bewertungsdaten).

Monatliche Evidenz-Checks verhindern, dass Beförderungen auf Erinnerung beruhen.
Standardisieren Sie ein „Evidence Packet“ für alle UX Designer:innen.
Timeboxen Sie Kalibrierung und loggen Sie Entscheidungen für spätere Konsistenz.
Nutzen Sie Facilitator-Rollen, damit leisere Stimmen gehört werden.
Kommunizieren Sie Outcomes klar: was sich ändert, was bleibt, was als Nächstes passiert.

Interviewfragen

Verhaltensbasierte Fragen funktionieren, wenn sie Details erzwingen: Kontext, Aktion, Trade-off, Outcome. Nutzen Sie diesen Teil als Scorecard-Ergänzung zur UX-Designer-Skill-Matrix und legen Sie vorher fest, wie „gute Evidenz“ je Level klingt. Bei Senior/Lead hören Sie besonders auf Scope-Handling, Stakeholder-Influence und Messdisziplin – nicht nur auf polierte Portfolios.

Hypothetisches Beispiel: Zwei Kandidat:innen haben starke Visual Craft. Im Interview zeigt sich: eine Person verbindet Entscheidungen konsequent mit Evidenz und messbaren Outcomes – sie scored höher bei Strategy und Discovery.

UX Research & Discovery

Erzählen Sie von einer Situation, in der Sie eine Design-Anfrage mit Discovery hinterfragt haben. Was änderte sich?
Wie sieht Ihr Research-Plan für ein unklar definiertes Problem aus – und warum genau diese Methoden?
Beschreiben Sie einen Fall mit widersprüchlichen Research-Ergebnissen. Wie entschieden Sie die nächsten Schritte?
Wie gehen Sie mit Recruitment-Constraints, Einwilligung und sensiblen Nutzerdaten um?
Welche Evidenz reicht für Sie, um eine Richtung zu wählen – und wann nicht?

Interaction Design & Information Architecture

Erzählen Sie von einem komplexen Workflow, den Sie vereinfacht haben. Was haben Sie entfernt oder umgebaut?
Beschreiben Sie einen Konflikt rund um Navigation/IA. Wie haben Sie ihn gelöst – und was war das Outcome?
Wie identifizieren Sie Edge Cases, und wie designen Sie dafür? Bitte mit konkretem Beispiel.
Welche Accessibility-Checks nutzen Sie im Interaction Design? Welche Änderung entstand daraus?
Wie dokumentieren Sie Interaktionen so, dass Engineering nicht raten muss?

Visual/UI Craft

Zeigen Sie ein Beispiel, in dem visuelle Hierarchie den Task Success verbessert hat. Was genau änderte sich?
Erzählen Sie von einem Fall, in dem Brand-Ziele mit Usability kollidierten. Wie entschieden Sie den Trade-off?
Wie gehen Sie mit States, Responsiveness und Error Handling in UI um?
Wann haben Sie bewusst „nicht perfekt“ shipped – und wie definierten Sie die Quality Bar?
Wie stellen Sie Konsistenz sicher, wenn mehrere Designer:innen parallel arbeiten?

Prototyping & Tools

Erzählen Sie von einem Prototyp, der eine Entscheidung gedreht hat. Was hat er sichtbar gemacht?
Wie wählen Sie Prototype-Fidelity? Geben Sie ein Beispiel, wo Sie bewusst „weniger“ gebaut haben.
Wie strukturieren Sie Design-Dateien, damit andere sicher weiterarbeiten können?
Welche Tooling- oder Workflow-Verbesserung haben Sie eingeführt – und wie hat das Delivery beeinflusst?
Wie nutzen Sie Prototypen, um Risiken früh zu senken (statt nur zu verkaufen)?

Design Systems & Consistency

Erzählen Sie von einer Situation, in der Sie ein One-off UI verhindert haben. Wie haben Sie beeinflusst?
Beschreiben Sie eine Komponente, die Sie beigesteuert oder weiterentwickelt haben. Wie lief Adoption?
Woran entscheiden Sie „System erweitern“ vs. „neues Pattern“ – und wie dokumentieren Sie das?
Schildern Sie einen Fall, in dem System-Constraints UX verschlechterten. Welchen Trade-off schlugen Sie vor?
Wie messen Sie, ob Systemarbeit wirklich Rework reduziert?

Collaboration & Communication

Erzählen Sie von einem Konflikt mit Engineering oder Product. Was haben Sie als Nächstes getan?
Beschreiben Sie einen Fall, in dem Ihre Dokumentation Rework verhindert hat. Was war enthalten?
Wie moderieren Sie Critiques, damit Feedback zu Actions wird und nicht zu „Opinion Ping-Pong“?
Schildern Sie eine Situation, in der Sie ohne formale Autorität Einfluss genommen haben. Was war das Outcome?
Wie schaffen Sie psychologische Sicherheit in Reviews, ohne Standards zu senken?

Strategy, Impact & Measurement

Erzählen Sie von einer UX-Änderung, die Sie gemessen haben: Metrik, Methode, Ergebnis.
Beschreiben Sie einen Fall, in dem UX-Evidenz Roadmap-Prioritäten verschoben hat.
Wie formulieren Sie Hypothesen und Success Criteria für Designarbeit?
Teilen Sie ein Post-Launch-Learning, das Ihre nächste Iteration verändert hat. Was haben Sie getan?
Wie vermeiden Sie Vanity Metrics, wenn Stakeholder schnelle Erfolge sehen wollen?

Mentoring & Craft Leadership

Erzählen Sie von einer Person, die Sie gementort haben. Welches Ziel setzten Sie und was änderte sich?
Beschreiben Sie Feedback, das schwer zu hören war. Wie haben Sie es vermittelt?
Wie erhöhen Sie Qualität im Team, ohne zum Bottleneck zu werden?
Welche Standards oder Rituale haben Sie eingeführt, die Konsistenz über Zeit verbessert haben?
Wie sehen Sie Ihren Multiplikator-Effekt im Alltag – woran merken andere ihn?

Scoren Sie Antworten gegen Verhaltensanker der Matrix, nicht gegen persönlichen Stil.
Fordern Sie Trade-offs und Constraints ein – nicht nur Artefakte.
Fragen Sie nach „Was würden Sie anders machen?“ für Lernfähigkeit.
Nutzen Sie gleiche Fragen pro Rolle für Vergleichbarkeit und Fairness.
Halten Sie Evidence Quotes fest, damit Entscheidungen später nachvollziehbar bleiben.

Einführung & laufende Pflege

Führen Sie die UX-Designer-Skill-Matrix als Arbeitswerkzeug ein, nicht als Policy-PDF. Adoption steigt, wenn Manager:innen das Raten an echten (anonymisierten) Fällen üben und Designer:innen sehen, wie die Matrix Entscheidungen beeinflusst. Behandeln Sie Updates wie Produktarbeit: Feedback sammeln, klein iterieren, Änderungen versionieren.

Phase	Was Sie machen	Owner	Output
Woche 1–2	Kickoff, Level-Logik und Evidenzregeln erklären, Beispiel-Pakete zeigen.	Design Leadership + People Partner	Gemeinsames Verständnis, Glossar, erste Scorecards
Woche 3–6	Manager-Training: 3 anonymisierte Cases raten, Unterschiede diskutieren, Anchors schärfen.	Design Ops oder Facilitator	Abgestimmte Interpretation, aktualisierte Beispiele
Woche 7–10	Pilot in einer Produktgruppe, ein kompletter Evidence-Review-Zyklus.	Pilot-Manager:innen	Evidence-Templates, Zeitaufwand, Lessons Learned
Woche 11–12	Pilot auswerten, Framework anpassen, Rollout-Plan und Cadence festlegen.	Framework-Owner	Version 1.0 Release Notes, Governance-Regeln, Jahresreview-Termin

Governance: Benennen Sie eine verantwortliche Rolle (oft Design Ops oder Lead UX), die Anchors pflegt, Change Requests sammelt und den Jahresreview organisiert. Wenn Sie ohnehin ein übergreifendes Skill-Framework betreiben, halten Sie Naming und Skalen konsistent, damit Teams nicht zwei Systeme lernen müssen.

DACH-Hinweis (unverbindlich, keine Rechtsberatung): Wenn die Matrix Einfluss auf Vergütung, Beförderungen oder formale Bewertungen hat, klären Sie früh Datenschutz, Aufbewahrungsfristen und Zugriffsmodelle. Mit Betriebsrat werden solche Punkte oft in einer Dienstvereinbarung konkretisiert – inklusive Transparenz, wer welche Daten sieht und wofür sie genutzt werden.

Trainieren Sie Manager:innen mit anonymisierten Fällen, bevor Sie echte Personen bewerten.
Pilotieren Sie zuerst; messen Sie Zeitaufwand, Verwirrungspunkte und fehlende Evidenztypen.
Versionieren Sie Anchors: wer darf ändern, wie wird Feedback gesammelt, wann releasen Sie?
Klären Sie Datensichtbarkeit früh, besonders wenn Bewertungen digital gespeichert werden.
Reviewen Sie jährlich und nach Reorgs, M&A oder großen System-/Plattformwechseln.

Fazit

Eine praktikable UX-Designer-Skill-Matrix schafft Klarheit: Designer:innen wissen, was erwartet wird, und Führungskräfte wissen, wonach sie suchen. Sie erhöht Fairness, weil Entscheidungen auf gemeinsamen Verhaltensankern und Evidenz beruhen – nicht auf der besten Story oder dem lautesten Auftreten. Und sie hält Entwicklung im Mittelpunkt, weil Feedback in konkrete nächste Verhaltensschritte übersetzt wird.

Wenn Sie nächste Woche starten wollen: Wählen Sie ein Pilotteam, machen Sie ein 60‑Minuten-Kickoff (Design Lead + People Partner) und definieren Sie ein Evidence-Packet-Template. Innerhalb von 4–6 Wochen sammeln Sie Evidenz für ein Quartal und führen eine kurze Kalibrierung mit zwei Manager:innen durch. Innerhalb von 12 Wochen veröffentlichen Sie Version 1.0 mit Owner, Review-Takt und einem einfachen Change-Prozess.

FAQ

Wie nutze ich die UX-Designer-Skill-Matrix im Führungsalltag?

Verwenden Sie sie in 1:1s als gemeinsame Referenz: Wählen Sie ein bis zwei Kompetenzbereiche, beschreiben Sie das Zielverhalten fürs nächste Level und vereinbaren Sie Evidenz, die Sie in den nächsten Wochen sammeln. Das bleibt leichtgewichtig: ein kurzer Decision Log, ein Research-Summary, ein Handoff-Beispiel oder Peer-Feedback. Die Matrix wird nützlich, wenn sie wöchentliche Arbeitsentscheidungen beeinflusst – nicht nur Review-Termine.

Wie vermeiden wir Bias bei Bewertungen gegen die Matrix?

Starten Sie mit Evidenzstandards: ein klarer Zeitraum (z. B. 6–12 Monate), mehrere Quellen und eindeutige Anchors. Führen Sie dann Kalibrierungsrunden durch, in denen Manager:innen Grenzfälle vergleichen und Ratings mit derselben Struktur begründen. Nutzen Sie kurze Bias-Checks: Recency, Halo/Horn, Similar-to-me und „Style vs Outcome“. Bewerten Sie Verhalten und Impact, nicht Präsentationspolitur oder Selbstvertrauen.

Kann jemand in einem Bereich Senior und in einem anderen Mid sein?

Ja, das ist häufig realistisch. Level beschreiben erwarteten Scope und Influence, Ratings beschreiben nachgewiesene Fähigkeit pro Kompetenzbereich. Eine Senior UX Designer:in kann bei Interaction Design und Collaboration sehr stark sein, aber bei Design Systems nur „Skilled“, je nach Team-Setup und Produktreife. Für Beförderungen zählt meist ein stabiles Muster in den Kernbereichen der Rolle – nicht Exzellenz in jedem einzelnen Feld.

Wie nutzen wir die UX-Designer-Skill-Matrix für Beförderungen, ohne eine Checkliste daraus zu machen?

Nutzen Sie die Matrix, um den Case zu strukturieren, nicht um Kästchen zu zählen. Fordern Sie 2–3 starke Beispiele, die Next-Level-Scope, autonome Entscheidungen und Influence zeigen – jeweils mit nachvollziehbarer Evidenz. In der Diskussion vergleichen Sie gegen die Level-Definition, nicht gegen andere Personen. Wenn ein Bereich schwächer ist, entscheiden Sie: Ist er kritisch für den nächsten Scope oder lässt er sich nach der Beförderung planvoll entwickeln?

Wie oft sollten wir das Framework aktualisieren, und wer besitzt es?

Benennen Sie einen Owner (oft Design Ops oder Lead UX) und führen Sie einen einfachen Change-Prozess ein: Feedback laufend sammeln, Änderungen bündeln, Release Notes veröffentlichen. Planen Sie mindestens einen Jahresreview plus Reviews nach großen Änderungen (neue Plattform, Reorg, neues Design-System-Governance-Modell). In DACH-Kontexten binden Sie den Betriebsrat früh ein, wenn Updates Bewertungen, Datensichtbarkeit oder Entscheidungslogik beeinflussen.

Jürgen Ulbrich

CEO & Co-Founder of Sprad

Jürgen Ulbrich has more than a decade of experience in developing and leading high-performing teams and companies. As an expert in employee referral programs as well as feedback and performance processes, Jürgen has helped over 100 organizations optimize their talent acquisition and development strategies.