UX-Designer Skill-Matrix & Kompetenzrahmen nach Level (Junior–Lead): Verhaltensanker, Rubrik + Vorlage

Eine gemeinsame ux designer skill matrix gibt euch 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.

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. Ihr nutzt 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. Fragt 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.

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

Kompetenzbereiche in der ux designer skill matrix

Eine gute Matrix balanciert Craft und Impact. Bewertet ihr nur Craft, belohnt ihr polierte Screens ohne Adoption. Bewertet ihr 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 teilt ihr 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.

Haltet 6–8 Kompetenzbereiche mindestens zwei Zyklen stabil, dann erst anpassen.
Definiert pro Bereich 3–5 konkrete Artefakt- und Outcome-Beispiele aus eurem Kontext.
Legt fest, was „gute Evidenz“ ist: Dokumente, Daten, Feedback, Entscheidungsverlauf.
Erlaubt Stärkenprofile je Level; erwartet nicht „Senior in allem“.
Reviewt 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. Nutzt eine klare Skala, definiert jedes Rating und fordert 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 ihr Reviews bereits strukturiert fahrt, koppelt die Evidenzfelder an eure Performance-Management-Routinen, damit Ratings nicht zur Spreadsheet-Übung werden.

Mini-Beispiel	Was passiert ist	Wie ihr es einstuft (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.

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

Entwicklungssignale & Warnzeichen

Wachstum zeigt sich als stabile Verhaltensmuster, nicht als ein heroisches Projekt. Nutzt 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 seht ihr, dass Abhängigkeiten proaktiv gelöst werden und Messdaten die Iteration steuern – nicht nur der Launch.

Growth signals (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.

Warning signs (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.

Trackt Signale über Zeit; entscheidet nicht auf Basis eines Projekt-Peaks.
Formuliert Next-Level-Erwartungen als 3–5 beobachtbare Verhaltensanker pro Bereich.
Nutzen Warnzeichen für Support-Pläne – nicht als Label für Personen.
Holt Peer-Input dort ein, wo Zusammenarbeit zentral ist (Eng, PM, Research).
Macht „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 ihr über Verhalten und Outcomes sprecht – 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 ihr Bewertungen zwischen Manager:innen ausrichtet: gleiche Evidenz-Pakete, Start mit Grenzfällen, dann ein schneller Bias-Check (Recency, Halo/Horn, Similar-to-me, „Style vs Outcome“). Wenn ihr eine strukturierte Facilitation braucht, nutzt Vorlagen aus einem Talent-Calibration-Guide und passt sie an Design-Craft-Kontexte an.

DACH-Hinweis (unverbindlich, keine Rechtsberatung): Wenn ihr mit einem Betriebsrat arbeitet, bindet 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.
Standardisiert ein „Evidence Packet“ für alle UX Designer:innen.
Timeboxt Kalibrierung und loggt Entscheidungen für spätere Konsistenz.
Nutzt Facilitator-Rollen, damit leisere Stimmen gehört werden.
Kommuniziert 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. Nutzt diesen Teil als Scorecard-Ergänzung zur ux designer skill matrix und legt vorher fest, wie „gute Evidenz“ je Level klingt. Bei Senior/Lead hört ihr 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?

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

Einführung & laufende Pflege

Führt 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. Behandelt Updates wie Produktarbeit: Feedback sammeln, klein iterieren, Änderungen versionieren.

Phase	Was ihr macht	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: Benennt eine verantwortliche Rolle (oft Design Ops oder Lead UX), die Anchors pflegt, Change Requests sammelt und den Jahresreview organisiert. Wenn ihr ohnehin ein übergreifendes Skill-Framework betreibt, haltet 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ärt 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.

Trainiert Manager:innen mit anonymisierten Fällen, bevor ihr echte Personen bewertet.
Pilotiert zuerst; messt Zeitaufwand, Verwirrungspunkte und fehlende Evidenztypen.
Versioniert Anchors: wer darf ändern, wie wird Feedback gesammelt, wann releast ihr?
Klärt Datensichtbarkeit früh, besonders wenn Bewertungen digital gespeichert werden.
Reviewt 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 ihr nächste Woche starten wollt: Wählt ein Pilotteam, macht ein 60‑Minuten-Kickoff (Design Lead + People Partner) und definiert ein Evidence-Packet-Template. Innerhalb von 4–6 Wochen sammelt ihr Evidenz für ein Quartal und führt eine kurze Kalibrierung mit zwei Manager:innen durch. Innerhalb von 12 Wochen veröffentlicht ihr Version 1.0 mit Owner, Review-Takt und einem einfachen Change-Prozess.

FAQ

Wie nutze ich die ux designer skill matrix im Führungsalltag?

Verwendet sie in 1:1s als gemeinsame Referenz: Wählt ein bis zwei Kompetenzbereiche, beschreibt das Zielverhalten fürs nächste Level und vereinbart Evidenz, die ihr in den nächsten Wochen sammelt. 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?

Startet mit Evidenzstandards: ein klarer Zeitraum (z. B. 6–12 Monate), mehrere Quellen und eindeutige Anchors. Führt dann Kalibrierungsrunden durch, in denen Manager:innen Grenzfälle vergleichen und Ratings mit derselben Struktur begründen. Nutzt kurze Bias-Checks: Recency, Halo/Horn, Similar-to-me und „Style vs Outcome“. Bewertet 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?

Nutzt die Matrix, um den Case zu strukturieren, nicht um Kästchen zu zählen. Fordert 2–3 starke Beispiele, die Next-Level-Scope, autonome Entscheidungen und Influence zeigen – jeweils mit nachvollziehbarer Evidenz. In der Diskussion vergleicht ihr gegen die Level-Definition, nicht gegen andere Personen. Wenn ein Bereich schwächer ist, entscheidet: 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?

Benennt einen Owner (oft Design Ops oder Lead UX) und führt einen einfachen Change-Prozess ein: Feedback laufend sammeln, Änderungen bündeln, Release Notes veröffentlichen. Plant mindestens einen Jahresreview plus Reviews nach großen Änderungen (neue Plattform, Reorg, neues Design-System-Governance-Modell). In DACH-Kontexten bindet ihr 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.