Interviewfragen für UX Designer, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Wähl zwei Projekte aus deinem Portfolio, die du in- und auswendig kennst, und übe, jedes in fünf Minuten und in zwanzig zu erzählen. Die meisten Fragen unten kannst du mit einem davon beantworten. Sag, was du getan hast, was das Team getan hat und was du heute anders machen würdest.

Was ein UX Designer können muss

• Research: Interviews, Usability-Tests, Umfragen und Analytics, und wann was passt.
• Struktur und Interaktion: Informationsarchitektur, User Flows, Wireframes und Prototypen.
• Handwerk und Systeme: Layout, Schrift und Komponenten, Designsysteme und das Tool, das die meisten Teams teilen, FigmaAbläufe, Komponenten, Varianten und Prototypen in dem Tool, das die meisten Teams mit den Entwicklern teilen..
• Barrierefreiheit: WCAG, die Richtlinien für barrierefreie Webinhalte, und Gestaltung für Tastatur, Screenreader und Sehschwäche.
• Team und Ergebnisse: Arbeit mit Entwicklern und Produktmanagern in agilenIn kurzen Zyklen neben der Entwicklung gestalten, einen oder zwei Schritte vor dem Bau. Teams und messen, ob ein Entwurf funktioniert hat, mit ProduktdatenProduktdaten lesen, um zu sehen, wo Menschen hängen bleiben, und zu prüfen, ob eine Änderung geholfen hat..

Dein Portfolio und dein Vorgehen

Führ mich durch eine Fallstudie aus deinem Portfolio.

Worauf sie achten: wie du denkst, vom Problem bis zum Ergebnis, und was dein Anteil war.

Kurze Antwort: „Ich erzähle sie in fünf Teilen: das Problem und wer es hatte, was wir aus dem Research gelernt haben, die Optionen, die wir ausprobiert haben, was wir gewählt haben und warum und was nach dem Release passiert ist. Ich sage, welche Rolle ich im Team hatte, und zeige den Moment, in dem das Research unseren Plan geändert hat.“

Die ausführliche Antwort in fünf Teilen:

1. Das Problem. Ein oder zwei Sätze mit einer Tatsache: „Die Hälfte der neuen Kunden brach die Registrierung beim Schritt zur Identität ab.“ Nenne die Nutzer und das Ziel des Geschäfts.
2. Was du gelernt hast. Das Research, das du gemacht hast, etwa Interviews, einen Usability-Test oder Analytics, und die zwei oder drei Erkenntnisse, die gezählt haben.
3. Die Optionen. Zeig ein paar Richtungen, die du ausprobiert hast, und warum du manche verworfen hast. Hier sehen die Interviewer dein Urteilsvermögen.
4. Die Entscheidung. Was du gestaltet hast, die Abwägungen und was du mit den Entwicklern und dem Produktmanager als Erstes ausliefern wolltest.
5. Das Ergebnis. Eine Zahl, wenn du eine hast, etwa die Abschlussquote oder Supporttickets, und was du heute ändern würdest.

Schwache Antwort: fertige Screens einen nach dem anderen zeigen und die Farben beschreiben. Das Vorgehen ist die Antwort.

Nachfrage: „Was hättest du mit doppelt so viel Zeit gemacht?“ Nenne das Research, das du ausgelassen hast, und das Risiko, das es hinterlassen hat, etwa Tests mit Menschen, die assistive Technologien nutzen.

Wie wählst du eine Research-Methode für eine Frage?

Worauf sie achten: dass du die Methode danach wählst, was du herausfinden musst.

Kurze Antwort: „Ich gehe von der Frage aus. Kennen wir das Problem noch nicht, nutze ich generatives Research wie Interviews oder Besuche vor Ort. Haben wir einen Entwurf zu prüfen, nutze ich evaluatives Research wie Usability-Tests. Muss ich wissen, wie viele Menschen etwas tun, nutze ich Analytics oder eine Umfrage. Kleine qualitative Studien sagen mir, warum; Zahlen sagen mir, wie viel.“

Die ausführliche Antwort: Zwei Achsen helfen: was Menschen sagen gegen was sie tun, und warum gegen wie viele. Interviews erfassen, was Menschen sagen und warum; Usability-Tests zeigen, was sie tun; Analytics zeigt, was viele Menschen tun, aber nicht warum; Umfragen zählen Meinungen. Kombiniere sie: Analytics findet den Schritt, an dem Menschen abspringen, ein Test zeigt, warum. Budget und Zeit zählen auch: Fünf schnelle Tests jetzt schlagen oft eine perfekte Studie im nächsten Quartal.

Schwache Antwort: „Ich mache immer eine Umfrage.“ Nachfrage: „Du hast eine Woche und kein Budget.“ Mach ein paar Tests aus der Ferne mit Menschen aus der Kundenliste oder Kollegen außerhalb des Projekts und sag klar, was diese Stichprobe dir nicht sagen kann.

Wie führst du ein Nutzerinterview, das dir ehrliche Antworten bringt?

Worauf sie achten: Können im Interview: offene Fragen, keine Suggestivfragen und Zuhören.

Kurze Antwort: „Ich frage danach, was Menschen kürzlich getan haben, nicht, was sie tun würden: ‚Erzähl mir vom letzten Mal, als du eine Reise gebucht hast‘ statt ‚Würdest du diese Funktion nutzen?‘. Ich halte die Fragen offen, bleibe nach Antworten still, damit sie mehr erzählen, und verkaufe nie das Produkt. Jemand anderes schreibt mit, damit ich zuhören kann.“

Die ausführliche Antwort: Bereite einen kurzen Leitfaden mit Themen vor, kein Skript. Fang leicht an, geh dann in die Momente, die zählen, und frag „warum“ und „was ist dann passiert“. Achte auf die Lücke zwischen dem, was Menschen sagen, und dem, was sie getan haben. Menschen sind höflich, deshalb bedeutet Lob wenig; Umwege und Beschwerden bedeuten viel. Nach fünf bis acht Interviews beginnen sich die Muster meist zu wiederholen.

Schwache Antwort: „Ich zeige ihnen den Entwurf und frage, ob er ihnen gefällt.“ Nachfrage: „Ein Teilnehmer wünscht sich eine bestimmte Funktion.“ Frag, welches Problem sie für ihn lösen würde; das Problem ist die Erkenntnis, nicht die Funktion.

Wie machst du aus Erkenntnissen im Research Designentscheidungen?

Worauf sie achten: Synthese: von vielen Notizen zu wenigen klaren Erkenntnissen, nach denen das Team handelt.

Kurze Antwort: „Ich gruppiere die Notizen aus allen Sessions nach Themen, oft auf einem gemeinsamen Board; das nennt man Affinity Mapping. Aus den Themen werden ein paar Erkenntnisse, jede mit Belegen und damit, wie oft sie vorkam. Ich teile sie in einer kurzen Session mit dem Team und wir legen fest, nach welchen wir handeln, verknüpft mit den Zielen des Produkts.“

Die ausführliche Antwort: Hol Entwickler und den Produktmanager in die Sessions oder in die Synthese; Menschen glauben, was sie gesehen haben. Schreib jede Erkenntnis als Problem, nicht als Lösung: „Die Leute trauen dem Preis erst, wenn sie die Gebühren sehen“ lässt Raum für Ideen. Ordne danach, wie viele Nutzer es betrifft und wie stark, und behalte die Rohnotizen, damit jeder nachprüfen kann. Mach aus den wichtigsten Erkenntnissen Designziele, die du später testen kannst.

Schwache Antwort: „Ich schreibe einen langen Bericht.“ Wenige lesen ihn. Nachfrage: „Die Erkenntnisse widersprechen dem, was der CEO glaubt.“ Zeig die Belege, Videoclips, wenn du welche hast, und schlag einen kleinen Test vor, der die Frage klärt.

Tests, Struktur und Barrierefreiheit

Wie planst du einen Usability-Test, und wie führst du ihn durch?

Worauf sie achten: einen Usability-Test, der klare, brauchbare Ergebnisse liefert.

Kurze Antwort: „Ich lege fest, was wir herausfinden müssen, schreibe realistische Aufgaben dazu, gewinne etwa fünf Menschen, die zu unseren Nutzern passen, und bitte sie, laut zu denken, während sie die Aufgaben an einem Prototyp oder am Live-Produkt versuchen. Ich notiere, wo sie zögern oder scheitern, messe den Aufgabenerfolg und teile die wichtigsten Probleme noch in derselben Woche mit dem Team.“

Die ausführliche Antwort in fünf Schritten:

1. Ziel. Eine oder zwei Fragen, etwa „Können neue Kunden ihren Liefertermin ohne Hilfe ändern?“.
2. Aufgaben. Realistische Szenarien in den Worten der Nutzer, ohne die Wörter auf den Buttons, damit du die Antwort nicht verrätst.
3. Menschen. Etwa fünf pro Nutzergruppe finden die meisten großen Probleme; teste nach dem Beheben noch einmal, statt einmal mehr Menschen zu testen.
4. Session. Bitte sie, laut zu denken, bleib neutral und hilf nur, wenn sie endgültig festhängen. Zeichne mit Erlaubnis auf.
5. Ergebnisse. Aufgabenerfolg, Zeit und Fehler pro Aufgabe und die Probleme, geordnet danach, wie schwer und wie häufig sie waren, mit einem Clip zu jedem.

Schwache Antwort: „Ich frage die Nutzer, ob sie es einfach finden.“ Beobachte stattdessen, was sie tun. Nachfrage: „Nur zwei von fünf Menschen sind an einer Aufgabe gescheitert. Ist das ein Problem?“ Ja, wenn die Aufgabe wichtig ist; kleine Tests finden Probleme, sie messen keine genauen Quoten.

Wie würdest du die Informationsarchitektur einer großen Website oder App gestalten?

Worauf sie achten: eine Struktur, die zum Denken der Nutzer passt, getestet statt geraten.

Kurze Antwort: „Informationsarchitektur ist, wie Inhalte geordnet und benannt sind, damit Menschen sie finden. Ich beginne mit einer Bestandsaufnahme dessen, was es gibt, und mache dann ein Card Sorting, bei dem Nutzer Themen so gruppieren, wie es für sie Sinn ergibt. Ich entwerfe eine Struktur, teste sie mit einem Tree Test, bei dem Menschen Einträge in einem reinen Textmenü suchen, und passe die Bezeichnungen an, bis die meisten die Dinge beim ersten Versuch finden.“

Die ausführliche Antwort: Ein offenes Card Sorting, bei dem Nutzer ihre Gruppen selbst benennen, zeigt ihr mentales Modell; ein geschlossenes prüft eine Entwurfsstruktur. Tree Tests messen die Auffindbarkeit, ohne dass das visuelle Design im Weg steht. Bezeichnungen zählen so viel wie die Struktur: Nutze die Wörter der Nutzer, die du in Suchprotokollen und Supporttickets findest. Plane für Wachstum, damit neue Inhalte einen klaren Platz haben, und biete eine Suche für alle, die sie bevorzugen.

Schwache Antwort: „Ich übertrage die Abteilungen der Firma ins Menü.“ Nutzer denken nicht in Abteilungen. Nachfrage: „Zwei Teams wollen beide ihren Bereich ganz oben.“ Zeig die Ergebnisse des Tree Tests; die Erfolgsquote der Nutzer entscheidet.

Wie machst du einen Entwurf barrierefrei?

Worauf sie achten: Barrierefreiheit von Anfang an eingebaut, auf der Stufe WCAG AA.

Kurze Antwort: „Ich gestalte nach den WCAG, den Web Content Accessibility Guidelines, auf Stufe AA: genug Farbkontrast, Text, der sich vergrößern lässt, jede Aktion per Tastatur möglich, ein sichtbarer Fokus, Beschriftungen für Screenreader, Fehlermeldungen, die sagen, wie man den Fehler behebt, und nichts, was sich allein auf Farbe verlässt. Ich halte das in den Entwürfen für die Entwickler fest und teste mit assistiven Technologien.“

Die ausführliche Antwort: Barrierefreiheit hilft viel mehr Menschen als denen mit einer dauerhaften Behinderung: jemandem mit gebrochenem Arm, bei grellem Sonnenlicht auf dem Handy, älteren Nutzern. Prüf den Kontrast, während du die Farben wählst, nicht danach. Gestalte Fokuszustände, Fehlerzustände und die Lesereihenfolge und schreib die Texte für Icons und Bilder. Teste selbst mit Tastatur und Screenreader und bezieh Menschen mit Behinderung ins Research ein. In der EU macht der European Accessibility Act (EAA) Barrierefreiheit für viele Dienste für Verbraucher zur gesetzlichen Pflicht statt zur Kür; Deutschland setzt ihn mit dem Barrierefreiheitsstärkungsgesetz (BFSG) um, Österreich mit dem Barrierefreiheitsgesetz (BaFG).

Schwache Antwort: „Die Barrierefreiheit prüfen die Entwickler am Ende.“ Nachfrage: „Die Markenfarbe fällt beim Kontrast durch.“ Behalte sie für große Elemente und nimm für Text und Buttons einen dunkleren Ton, abgestimmt mit dem Markenteam.

Designsysteme, Prototypen und die Arbeit im Team

Was lässt ein Designsystem funktionieren?

Worauf sie achten: dass du ein Designsystem als gemeinsames Produkt siehst, nicht als Stickerbogen.

Kurze Antwort: „Ein Designsystem ist ein gemeinsamer Satz aus Komponenten, Regeln und Anleitungen, den Designer und Entwickler beide nutzen, damit das Produkt überall gleich aussieht und funktioniert. Es funktioniert, wenn die Komponenten in FigmaAbläufe, Komponenten, Varianten und Prototypen in dem Tool, das die meisten Teams mit den Entwicklern teilen. denen im Code entsprechen, wenn es klare Regeln gibt, wann was zu nutzen ist, und wenn jemand es verantwortet und Teams Änderungen vorschlagen können.“

Die ausführliche Antwort: Fang bei dem an, was das Produkt schon am meisten nutzt, etwa Buttons, Formularfelder und Meldungen, nicht bei einer vollständigen Bibliothek. Design Tokens, benannte Werte für Farben, Abstände und Schrift, halten Design und Code im Gleichschritt. Jede Komponente dokumentiert ihre Zustände, ihre Barrierefreiheit und Dos and Don'ts. Behandle es als Produkt: ein Backlog, Releases und ein Weg, auf dem Teams beitragen können. Miss die Nutzung, nicht die Zahl der Komponenten.

Schwache Antwort: „Es ist unsere Figma-Datei mit Komponenten.“ Ohne Code und Verantwortliche driftet es auseinander. Nachfrage: „Ein Team braucht eine Komponente, die das System nicht hat.“ Lass es sie innerhalb der Regeln bauen und prüf dann, ob sie für alle ins System gehört.

Wann baust du Prototypen in Low Fidelity, und wann in High Fidelity?

Worauf sie achten: dass sich der Aufwand für den Prototyp nach der Frage richtet, die du beantworten musst.

Kurze Antwort: „Low Fidelity, Skizzen oder einfache Wireframes, wenn es um die Idee oder den Ablauf geht, weil die Menschen dann das Konzept kommentieren und nicht die Farben, und Änderungen Minuten kosten. High Fidelity, ein klickbarer Prototyp, der echt aussieht, wenn ich Details wie Formulierungen, Layout oder eine komplexe Interaktion testen oder die endgültige Richtung zeigen muss.“

Die ausführliche Antwort: Pass den Prototyp an das Risiko an. Früh probierst du mehrere Richtungen schnell auf Papier oder in groben Frames aus. Später testest du die gewählte in der Detailtiefe der Entscheidung: Die Fehlermeldungen eines Formulars brauchen echten Text, eine Idee für die Navigation nicht. Manche Interaktionen, etwa Drag-and-drop, fühlen sich erst im Code richtig an; dann baust du mit einem Entwickler zusammen einen Prototyp in Code.

Schwache Antwort: „Ich mache immer pixelgenaue Prototypen.“ Das ist langsam und lädt zu falschem Feedback ein. Nachfrage: „Ein Stakeholder hält das Wireframe für endgültig.“ Sag zu Beginn klar, wofür der Prototyp da ist und wofür nicht.

Wie arbeitest du mit Entwicklern vom Entwurf bis zum Release?

Worauf sie achten: Zusammenarbeit, die den Entwurf gut gebaut ins Produkt bringt, statt ihn über den Zaun zu werfen.

Kurze Antwort: „Ich hole Entwickler früh dazu, damit sie sagen können, was schwierig ist, bevor der Entwurf fertig ist. Die Übergabe deckt jeden Zustand ab, etwa leer, ladend, Fehler und sehr langer Text, nicht nur den Happy Path. Ich nutze die gemeinsamen Komponenten, beantworte Fragen während der Umsetzung schnell und prüfe das Ergebnis im Browser vor dem Release.“

Die ausführliche Antwort: Die meiste Reibung kommt von Überraschungen: ein Entwurf, der Daten braucht, die das System nicht hat, oder eine Komponente, die es nicht gibt. Kurze Abstimmungen während des Entwurfs vermeiden sie. Wenn du weißt, wie Screens gebaut werden, mit HTML und CSSWissen, wie Screens gebaut werden, damit deine Entwürfe ins Web passen und du mit Entwicklern in ihren Begriffen sprichst. oder den Komponenten von ReactEin verbreitetes Framework für Oberflächen; wer seine Komponenten kennt, entwirft welche, die Entwickler wiederverwenden können., gestaltest du Dinge, die Vorhandenes wiederverwenden. Weicht die gebaute Version ab, entscheidet ihr gemeinsam, ob es für die Nutzer zählt, bevor du um Änderungen bittest.

Schwache Antwort: „Ich schicke die fertige Datei, und sie bauen es.“ Nachfrage: „Ein Entwickler sagt, deine Interaktion dauert zwei Wochen.“ Frag, was zwei Tage dauern würde, und prüf, ob diese Version das Problem der Nutzer noch löst.

Ein Produktmanager will eine Funktion, die deiner Meinung nach den Nutzern nicht hilft. Was tust du?

Worauf sie achten: Zusammenarbeit mit Produktmanagern über Belege, nicht über Meinungen.

Kurze Antwort: „Ich frage zuerst, welches Problem die Funktion lösen soll und woran wir erkennen, dass sie funktioniert hat. Oft sind wir uns beim Ziel einig und nur bei der Lösung nicht. Dann bringe ich ein, was wir über die Nutzer wissen, und schlage den kleinsten Test vor, der die Frage klärt, etwa einen Test mit einem Prototyp oder ein kleines Release für einen Teil der Nutzer.“

Die ausführliche Antwort: Der Produktmanager verantwortet das Was und Warum des Produkts; der Designer verantwortet, wie es für die Nutzer funktioniert; beide stehen für das Ergebnis ein. Uneinigkeit ist gesund, wenn sie in einem Test endet statt in einem Wettstreit der Meinungen. Hol die anderen BetroffenenProdukt, Entwicklung und Fachbereich zu einer Entscheidung bringen, die auf dem beruht, was Nutzer brauchen. früh dazu, etwa Support oder Vertrieb. Fällt die Entscheidung gegen dich aus, steh dazu und miss sie ehrlich.

Schwache Antwort: „Ich weigere mich, es zu gestalten.“ Nachfrage: „Es gibt keine Zeit zum Testen.“ Einigt euch vor dem Release auf die Kennzahl und einen Termin für die Auswertung, damit das Ergebnis entscheidet, was bleibt.

Wie misst du, ob ein Entwurf funktioniert hat?

Worauf sie achten: dass du Design mit Kennzahlen verbindest, vor und nach dem Release.

Kurze Antwort: „Vor dem Release lege ich die Kennzahlen mit dem Team fest: eine Kennzahl für Verhalten, etwa Aufgabenerfolg oder Abschlussquote, eine für das Geschäft, etwa Conversion oder Supporttickets, und manchmal einen Wert für die Zufriedenheit. Nach dem Release vergleiche ich mit dem Ausgangswert, schaue, wo Menschen noch abspringen, und teste erneut.“

Die ausführliche Antwort: Kennzahlen zur Usability kommen aus Tests: Aufgabenerfolg, Zeit pro Aufgabe und Fehler. Produktkennzahlen kommen aus Analytics, etwa Funnels in Google AnalyticsFunnels, Events und Absprünge in dem Analysetool, das viele Websites nutzen.. Kennzahlen zur Einstellung kommen aus Umfragen, etwa der System Usability Scale, einer Umfrage aus zehn Fragen mit einem Standardwert. Ein A/B-Test, der verschiedenen Nutzern zur selben Zeit zwei Versionen zeigt, trennt die Wirkung des Designs von der Saison, wenn der Traffic hoch genug ist und die StatistikGenug, um zu wissen, wann ein Unterschied in einem Test echt ist und wann er Zufall ist. sorgfältig gelesen wird.

Schwache Antwort: „Die Nutzer haben gesagt, dass es ihnen gefällt.“ Nachfrage: „Die Conversion ist gestiegen, aber die Beschwerden auch.“ Schau, wer sich beschwert und warum; ein Entwurf kann Menschen durch einen Schritt drängen, den sie später bereuen.

Senior, Lead, Principal, Design Manager und Head of Design

Diese Fragen kommen bei Rollen als Senior, Lead und Principal UX Designer, Design Manager und Head of Design.

Wie hebst du als Lead oder Principal Designer die Designqualität über Teams hinweg?

Worauf sie achten: Einfluss auf Arbeit, die du nicht selbst machst.

Kurze Antwort: „Ich mache gute Arbeit einfach und sichtbar: ein Designsystem, das die Leute nutzen wollen, regelmäßige Critiques, in denen Designer laufende Arbeit zeigen, gemeinsames Research, das jeder findet, und ein paar Prinzipien, auf die wir uns geeinigt haben. Die riskantesten Entwürfe prüfe ich selbst, und beim Rest coache ich die Designer.“

Die ausführliche Antwort: Ein Lead Designer leitet die Designarbeit eines Teams im Alltag; ein Principal Designer löst die schwierigsten Designprobleme und setzt den Maßstab, ohne Menschen zu führen. Beide wirken über andere. Critique funktioniert, wenn es um das Ziel geht, nicht um Geschmack: „Hilft das einem neuen Nutzer, den Preis zu finden?“ Arbeite eng mit den Leads aus Produkt und Entwicklung, damit Designqualität Teil der Produktplanung ist und keine Prüfung am Ende.

Schwache Antwort: „Ich gestalte ihre Screens neu, wenn sie nicht gut genug sind.“ Nachfrage: „Ein Team liefert immer wieder ohne Design-Review aus.“ Finde heraus, warum, oft aus Zeitmangel, und biete ein leichteres Review an, das zu seinem Tempo passt.

Wie baust und führst du als Design Manager oder Head of Design ein Designteam?

Worauf sie achten: oben auf der Leiter: Einstellungen, Entwicklung, Prozesse und der Platz des Designs in der Firma.

Kurze Antwort: „Ich gehe davon aus, was die Firma vom Design braucht, und stelle dann für die Lücken ein, etwa Research oder ein Designsystem. Jeder Designer bekommt einen klaren Bereich und einen Karriereweg; ich führe regelmäßige Einzelgespräche und Critiques und baue die Abläufe auf, die Zeit sparen, etwa die Rekrutierung für Research und gemeinsame Tools. Der Führungsebene zeige ich die Ergebnisse des Designs in ihren Begriffen.“

Die ausführliche Antwort: Ein Design Manager führt Designer: Einstellungen, Feedback, Entwicklung und Auslastung. Ein Head of Design prägt zusätzlich, wie Design in der ganzen Firma arbeitet: die Struktur des Teams, das Budget, das Designsystem und die Research-Praxis und einen Platz dort, wo Produktentscheidungen fallen. Schreib auf, was jede Stufe bedeutet, damit Beförderungen fair sind. Schütze Zeit für Research und Handwerk gegen den Druck, nur Screens auszuliefern.

Schwache Antwort: „Ich gestalte weiter und führe nebenbei.“ Nachfrage: „Die Führungsebene fragt, was Design beiträgt.“ Zeig zwei oder drei Ergebnisse mit Zahlen, etwa ein Redesign, das Anrufe beim Support gesenkt hat, und die Kosten der Probleme, die das Research verhindert hat.

Dein Lebenslauf und Portfolio für diese Fragen

Interviewer fragen nach dem, was dein Portfolio und dein Lebenslauf behaupten. Schreib deshalb Zeilen, die zu den Antworten oben führen, und sorg dafür, dass hinter jeder eine Fallstudie steht:

Eine Bewertung an einem echten Job als UX Designer zeigt dir, welche dieser Punkte der Arbeitgeber verlangt, damit du weißt, welche Fallstudien im Portfolio nach vorn gehören.