Was wird in UX-Designer-Interviews eigentlich geprüft?

Wem Sie tatsächlich gegenübersitzen werden

Ein UX-Designer-Interview ist selten ein einzelnes Gespräch. Es ist meist eine Abfolge: ein Recruiter-Screen, dann ein Portfolio-Review mit ein oder zwei Designern, dann eine Design-Übung oder Whiteboard-Challenge, dann eine Runde mit den Leuten, mit denen Sie tatsächlich arbeiten würden — ein Product Manager, ein Entwickler, manchmal ein Researcher — und oft ein abschließendes Gespräch mit dem Hiring Manager oder Design Lead. Kleinere Unternehmen komprimieren das auf zwei oder drei Sessions; größere strecken es über Wochen mit einem formalen Debrief zwischen den Runden, bei dem Interviewer ihre Notizen auf einem Scorecard vergleichen.

Das Portfolio-Review ist der Teil, der am meisten Gewicht trägt, und wird meist von einem arbeitenden Designer geleitet, nicht von HR. Das ist wichtig, weil diese Person das gebaut hat, was Sie beschreiben, und weiß, wo die Nahtstellen sind. Sie bewerten nicht Ihre Folien. Sie hören darauf, ob Sie eine Entscheidung unter leichtem Druck erklären können und ob die Entscheidung tatsächlich Ihre war.

Das Portfolio-Review: was wirklich passiert

Das Standardformat ist "führen Sie mich durch ein Projekt". Es klingt nach Small Talk. Ist es aber nicht. Ein Designer, der dieses Review führt, prüft beim Zuhören auf einige spezifische Dinge:

• Woher das Problem kam. Hat Ihnen ein Stakeholder eine Lösung als Brief verkleidet übergeben ("wir brauchen ein Dashboard"), oder sind Sie zum zugrundeliegenden Bedarf vorgedrungen? Wenn Sie sagen "der PM bat um X" und dann beschreiben, wie Sie X gebaut haben, ist das ein Warnsignal. Wenn Sie sagen "der PM bat um X, aber als ich Support-Tickets ansah und drei User-Interviews führte, stellte ich fest, dass die eigentliche Reibung Y war", ist das die gewünschte Antwort.
• Was Sie tatsächlich gemacht haben versus was das Team gemacht hat. Für Portfolios geschriebene Case Studies verwenden durchgehend "wir". Ein guter Interviewer unterbricht und fragt "was war Ihr spezifischer Beitrag zu diesem Flow?" Wenn Sie Ihre Arbeit nicht von der des Teams trennen können, nehmen sie an, dass Sie nur mitgefahren sind.
• Trade-offs, die Sie gemacht haben, und warum. Nicht "wir haben ein paar Optionen erwogen und die beste gewählt" — welche Option, was wäre so oder so verloren gegangen, und welche Daten oder welcher Zwang gaben den Ausschlag. Engineering-Timeline, Technical Debt, Brand Guidelines, Accessibility-Anforderungen, ein Stakeholder, der nicht nachgab — nennen Sie den tatsächlichen Zwang.
• Was nach dem Launch passierte. Haben Sie die Zahlen angesehen, einen Follow-up-Usability-Test durchgeführt, Support-Ticket-Volumen ermittelt, oder endete das Projekt beim Handoff an Engineering? Viele Kandidaten haben hier keine Antwort, weil die Organisation nie den Loop geschlossen hat, und ein anständiger Interviewer wird das notieren, ohne es Ihnen anzukreiden — aber es wird Ihnen angekreidet, wenn Sie ein Ergebnis behaupten, das Sie nie gemessen haben.

Eine oberflächliche Antwort in einem Portfolio-Review klingt flüssig und sagt nichts Prüfbares: "wir haben den Onboarding-Flow neu gestaltet und das hat die User Experience wirklich verbessert". Keine Baseline, keine Metrik, kein benannter Zwang, keine Unterscheidung zwischen Ihrem Input und dem des Teams. Jemand, der beruflich Portfolios reviewt, hört das ständig und hört nach einem Satz auf zuzuhören.

Die Design-Übung oder Whiteboard-Challenge

Das ist das praktische Assessment, und das Format variiert stark nach Unternehmen, also seien Sie spezifisch, welche Art Sie machen sollen:

• Live-Whiteboard/Figma-Übung. Sie bekommen vor Ort einen Prompt — "gestalte den Checkout-Flow für eine Lebensmittel-App neu" oder "entwirf eine Möglichkeit für zwei Leute, eine Rechnung zu teilen" — und werden gebeten, zu skizzieren, Ihr Denken zu strukturieren und in Echtzeit zu erläutern, oft in Figma oder FigJam oder buchstäblich an einem Whiteboard. Das wird nicht nach visueller Politur bewertet. Es wird bewertet, ob Sie klärende Fragen stellen, bevor Sie etwas zeichnen (wer ist der User, welches Gerät, was ist der Business-Zwang), ob Sie mehr als eine Struktur erwägen und ob Sie eine Entscheidung verteidigen können, wenn der Interviewer widerspricht — denn das wird er absichtlich tun, um zu sehen, ob Sie einknicken oder argumentieren.
• Take-home-Übung. Ein Brief, an dem Sie über ein paar Tage arbeiten und dann präsentieren. Hier kommt das Getestete echter Arbeit näher: können Sie einen wirklich mehrdeutigen Brief scopen und können Sie einer Runde eine Begründung präsentieren, nicht nur Screens übergeben. Wenn der Brief keine Research-Methode spezifiziert, trotzdem eine zu verwenden (selbst einen leichtgewichtigen Guerilla-Test mit fünf Leuten) und das zu sagen, wird meist bemerkt.
• Kritik-Übung. Ihnen wird ein bestehender Screen oder Flow gezeigt — manchmal das eigene Produkt des Unternehmens — und Sie werden gefragt, was Sie ändern würden. Das testet Urteilsvermögen mehr als Ausführung: können Sie das tatsächliche Usability-Problem identifizieren (eine verwirrende Informationshierarchie, eine verletzte Plattform-Konvention, ein Accessibility-Fehler wie unzureichender Kontrast oder fehlende Focus States) statt kosmetische Vorschläge zu Farbe und Schrift zu machen.

Eine oberflächliche Antwort bei jeder dieser Übungen klingt wie Design-Meinung ohne User darin: "Ich würde den Button größer machen und die Farbe ändern, damit er auffällt". Ein Designer, der Sie interviewt, will hören, welches spezifische Problem die Änderung löst — Auffindbarkeit, Kontrastverhältnis, Touch-Target-Größe, Konkurrenz mit einem stärkeren visuellen Element in der Nähe — und idealerweise eine Möglichkeit, zu prüfen, ob die Änderung funktioniert hat.

Die Fragen, die nicht wirklich über Design sind

Ein paar Fragen wiederholen sich genau deshalb, weil sie schwer zu faken sind, und sie sind es wert, genannt zu werden, weil sie oberflächlich nicht wie technische Fragen klingen.

"Erzählen Sie von einer Situation, in der ein Stakeholder mit Ihrem Design nicht einverstanden war." Das ist eine Kollaborations-Frage im Konfliktgeschichten-Kostüm. Eine schwache Antwort endet mit "und schließlich sahen sie es auf meine Art" oder, schlimmer, "ich habe einfach gemacht, was sie wollten". Eine starke Antwort beschreibt eine spezifische Meinungsverschiedenheit, welche Evidenz oder Argumentation jede Seite hatte, und eine Lösung, die tatsächlich eine Änderung beinhaltete — entweder Ihres Designs oder Ihrer eigenen Sicht, aufgrund von etwas, das Sie gelernt haben. Wenn sich in Ihren Geschichten nie etwas bewegt, ist das ein Signal, dass Sie nicht wirklich verhandeln, sondern nur erzählen.

"Woher wissen Sie, wann ein Design fertig ist?" oder "Wie gehen Sie mit einem Feature ohne Zeit für Research um?" Diese prüfen, ob Sie einen funktionierenden Prozess unter realen Zwängen haben, nicht den Lehrbuch-Double-Diamond. Eine oberflächliche Antwort rezitiert ein Framework beim Namen — "ich starte immer mit Empathy Mapping, dann Ideation, dann Prototyping" — ohne es je mit einem Zwang zu verbinden. Ein erfahrener Designer beschreibt, was er gestrichen hat und warum: "es gab keine Zeit für eine vollständige Studie, also führte ich einen fünfminütigen unmoderierten Test auf den zwei riskantesten Screens durch und nutzte das, um zwischen zwei Richtungen zu entscheiden".

"Wie arbeiten Sie mit Engineering zusammen?" Das prüft, ob Sie verstehen, was Sie tatsächlich übergeben — Component States, Edge Cases, Empty States, Error States, nicht nur den Happy Path — und ob Sie jemals ein Design wegen eines echten technischen Zwangs geändert haben, den Sie nicht antizipiert hatten. Wenn Ihre Antwort impliziert, dass Entwickler einfach bauen, was Sie ihnen schicken, liest sich das als Unerfahrenheit, nicht als Selbstvertrauen.

Metriken und Business-Fragen — "wie würden Sie Erfolg für dieses Feature messen" oder "wie entscheiden Sie, was zu priorisieren ist" — prüfen, ob Sie eine Design-Entscheidung mit einer Zahl verbinden können, die dem Business wichtig ist (Conversion, Task Completion Time, Support-Ticket-Volumen, Retention) statt nur mit ästhetischer oder Usability-Sprache. Sie müssen kein Data Analyst sein, aber eine Metrik zu nennen, die Sie tatsächlich tracken würden, selbst grob, unterscheidet Sie von jemandem, der nie einen Roadmap-Slot rechtfertigen musste.

Was Sie damit anfangen können

Bauen Sie vor jedem Interview die Story für zwei oder drei Projekte um folgendes herum neu auf: das tatsächliche Problem hinter dem Brief, ein schwerer Trade-off, Ihr spezifischer Beitrag versus der des Teams, und was nach dem Launch passierte, selbst wenn die Antwort ist "wir haben es nicht gemessen und hier ist, was ich beim nächsten Mal tracken würde". Diese letzte Ehrlichkeit kommt besser an als eine vage Erfolgsbehauptung.

Wenn Sie eine Live-Design-Übung machen, üben Sie die ersten neunzig Sekunden — die klärenden Fragen — mehr als das Zeichnen. Die meisten schwachen Performances sind keine schlechten Ideen, sondern ein Kandidat, der zu skizzieren beginnt, bevor er weiß, wer der User ist oder was der Zwang ist.

Und wenn das Problem, dem Sie tatsächlich gegenüberstehen, früher liegt als all das — Bewerbungen, die nirgendwohin führen, und kein Interview, auf das man sich vorbereiten kann — dann ist das ein anderes Problem mit einem anderen Mechanismus, das es zu lösen gilt, bevor Sie Interview-Antworten für einen Anruf polieren, der nie kommt. jobmarket.pro liest das Inserat vollständig, gleicht es mit einem Profil Ihrer tatsächlichen Erfahrung ab und bereitet die Bewerbung daraus vor, ohne etwas zu erfinden, das Sie nicht gemacht haben.