UI-UX-Designer-Interviewfragen

Beschreibe deinen Designprozess vom Briefing bis zum finalen Mockup.

Man beginnt damit, das Problem und die Erfolgskriterien zu verstehen, nicht die angefragte Lösung – hinter einem Briefing für ein Dashboard steckt oft eigentlich die Frage nach einer einzelnen Zahl. Danach folgt Recherche zu bestehendem Verhalten und Rahmenbedingungen, breite Skizzen mehrerer Richtungen, bevor man eine verfeinert, ein Prototyp in der Detailtiefe, die die Frage verlangt, Tests mit Nutzern und Iteration. Handoff und Messung nach dem Launch gehören zum Prozess dazu, nicht als Nachgedanke.

Was ist der Unterschied zwischen UX und UI? Gib ein Beispiel für schlechte UX bei guter UI.

UX ist die gesamte Erfahrung beim Erreichen eines Ziels – Struktur, Ablauf und ob das Ding das Problem überhaupt löst. UI ist die visuelle und interaktive Ebene, über die das geschieht. Ein wunderschön gestalteter Abo-Bildschirm, bei dem die Kündigung eine E-Mail an den Support erfordert, ist exzellente UI und feindselige UX; umgekehrt ist ein schlichtes, unschönes Formular, das dich in zehn Sekunden durchbringt, gute UX mit schwacher UI.

Wie führst du Usability-Tests durch? Wie viele Teilnehmer brauchst du?

Man gibt Teilnehmern realistische Aufgaben statt sie nach ihrer Meinung zu fragen, beobachtet still und widersteht der Versuchung, die Oberfläche zu erklären – sobald man hilft, sind die Daten verloren. Fünf Teilnehmer pro Nutzergruppe decken meist die schwerwiegendsten Probleme auf, und mehr Teilnehmer liefern in der Regel dieselben Erkenntnisse; es ist besser, mehrere kleine Runden zwischen den Iterationen zu machen als eine große Studie am Ende.

Was ist ein Design-System, und wozu wird es gebraucht?

Ein Design-System ist eine gemeinsame Bibliothek aus Komponenten, Tokens und Nutzungsregeln, die ein Produkt konsistent hält, während mehr Leute daran arbeiten. Es erspart die wiederkehrenden Kosten, einen Button immer wieder neu zu gestalten, und lässt Designer Zeit auf echte Probleme verwenden. Es überlebt nur, wenn es einen Verantwortlichen und einen Beitragsprozess hat – ein ungepflegtes System wird zum Museum, um das alle einen Bogen machen.

Wie verteidigst du deine Lösung, wenn ein Stakeholder anderer Meinung ist?

Präferenz von Evidenz trennen: fragen, welches Ergebnis die Person beunruhigt, und dann mit Forschung, Nutzungsdaten oder einem heuristischen Prinzip antworten statt mit Geschmack. Bleibt die Uneinigkeit bestehen und ist die Datenlage dünn, einen Test vorschlagen statt die Diskussion zu gewinnen. Sagen zu können, was die eigene Meinung ändern würde, überzeugt weit mehr als die Arbeit zu verteidigen.

Was ist a11y? Nenne die grundlegenden Anforderungen.

Barrierefreiheit bedeutet, dass Menschen mit Behinderungen das Produkt nutzen können. Die Basis ist ein Kontrast von 4,5:1 für Fließtext, Bedeutung niemals allein über Farbe zu vermitteln, vollständige Bedienbarkeit per Tastatur mit sichtbarem Fokuszustand, korrekte semantische Struktur und Labels für Screenreader sowie Text, der sich bei 200 Prozent Zoom neu umbricht. All das verbessert nebenbei die Nutzbarkeit für alle, und das ist meist das Argument, das das Budget gewinnt.

Wie übergibst du Designs an Entwickler?

Ein Handoff umfasst Zustände, nicht nur Screens: leer, ladend, Fehler und Grenzfälle wie ein sehr langer Name oder null Ergebnisse. Er deckt responsives Verhalten, Details zu Interaktion und Bewegung sowie ab, welche Design-System-Komponenten verwendet werden. Der beste Indikator für einen reibungslosen Handoff ist, dass Entwickler die Arbeit schon im Entstehen gesehen haben – ein Handoff, der das erste Gespräch darüber ist, kommt bereits zu spät.

Wie arbeitest du mit Einschränkungen, wenn die ideale Lösung nicht umsetzbar ist?

Zunächst klären, worin die Einschränkung wirklich besteht – meist Aufwand, technische Limitierung oder Timing – und herausfinden, welcher Teil des Werts auch mit geringerem Aufwand erhalten bleibt. Die reduzierte Version bewusst ausliefern, dokumentieren, was gestrichen wurde und warum, und vereinbaren, was Anlass wäre, es später zu überarbeiten. Designer, die Einschränkungen als Teil des Problems statt als Hindernis behandeln, bekommen deutlich mehr von ihrer Arbeit tatsächlich umgesetzt.