Product Designer:in

Fähigkeit, eine Entscheidung unter Unsicherheit zu strukturieren: Identifikation der Bedingungen, expliziter Abwägungen (Nutzungsklarheit vs. Geschäftsanforderung, Aufwand vs. Wirkung), Konsultation der betroffenen Personen, nachträgliche Validierung mit Daten oder Nutzungs-Feedback. Bonus: die:der Kandidat:in erwähnt, im Verlauf die Meinung geändert oder die Entscheidung dokumentiert zu haben. Wer rückblickend eine offensichtliche Entscheidung beschreibt, hat selten ernsthaft abgewogen.

Offenheit für Daten und Nutzungssignale, Trennung von Ego und Produkt. Bonus: die:der Kandidat:in benennt die konkrete Quelle des Umdenkens (ein Usability Test, eine Aktivierungsmetrik, ein Support-Pattern) und den Abstand zwischen Signal und Entscheidung. Wer noch nie ein eigenes Design ernsthaft überarbeiten musste, hat entweder nichts ausgeliefert oder nicht gemessen.

Partnerschaftliche Haltung statt Autoritätsdruck: Bereitschaft, die technische oder produktbezogene Sicht zu hören, bevor entschieden wird; Kompromiss oder Experiment vorschlagen; anerkennen, wenn das Gegenüber recht hatte. Kandidat:innen, die Ingenieur:innen oder PMs als „verstehen Design nicht“ beschreiben, zeigen eine Schwäche im bereichsübergreifenden Teamspiel, die im KMU mit kleinem Produktteam besonders teuer wird.

Klärung des Problems vor der Lösung: nicht direkt in den Pixelmodus springen, sondern das Problem, die Zielnutzer:innen, die Erfolgsmetrik und die Bedingungen klären. Erwartet: 2-3 strukturierte Fragen, eventuell ein Quick-Sketch oder Wireframe als erste Hypothese, kein Hochglanz-Mock. Wer einfach in 48 Stunden ein fertiges UI liefert, ohne zu rahmen, zeigt eine ausführende statt einer urteilsstarken Haltung.

Sachliche Klärung statt Eskalation: zuerst verstehen, warum vereinfacht wurde (technische Komplexität, Edge Case, missverstandener Brief), dann die Auswirkung auf die Nutzung bewerten. Bonus: die:der Kandidat:in nennt einen Fall, in dem die Vereinfachung tatsächlich besser war. Wer reflexhaft auf Wiederherstellung des Originals besteht, ohne den Grund zu prüfen, zeigt eine Pixelfokus-Haltung statt Produktdenken.

Pragmatische Priorisierung: nicht alles auf einmal reparieren wollen. Erwartet: (1) Audit der bestehenden Komponenten und der wiederkehrenden Patterns, (2) zuerst die 8-12 meistgenutzten Komponenten konsolidieren (großer Hebel, geringes Risiko), (3) Abstimmung mit Frontend zur Reihenfolge der Migration, (4) leichtgewichtige Dokumentation in Figma. Wer sofort eine vollständige Design-System-Migration nach Material oder Tailwind UI ausruft, zeigt fehlenden Pragmatismus.

Strukturierte Herangehensweise: (1) Aktivierungsdefinition schärfen (Schritt A, B oder C?), (2) den aktuellen Funnel quantitativ und qualitativ instrumentieren (Drop-off pro Schritt, Usability Tests an den Bruchstellen), (3) 5-10 Hebel-Hypothesen auflisten (Onboarding-Tour, Friktion im Signup, wahrgenommener Wert), (4) Impact mal Aufwand pro Hypothese schätzen, (5) in 2-Wochen-Iterationen sequenzieren mit Effektmessung. Wer in Lösungen springt (wir bauen ein Tutorial), ohne den Funnel zu rahmen, zeigt eine Methoden-Schwäche.

Klärung vor dem Vorschlag (erwartetes Volumen, Latenzanforderungen, unterstützte Geräte, Persistenz ungelesener Benachrichtigungen, Channel-Mix In-App vs. E-Mail vs. Push). Kohärente Lösung: Inbox-Struktur, Lesestatus, Priorisierung dringender vs. informativer Benachrichtigungen, Stummschalten und Filterung, E-Mail-Fallback. Bonus: Anerkennung der Unsicherheitszonen (Ich würde drei niedrigfidele Varianten testen, bevor ich mich auf eine Inbox-Architektur festlege). Wer ohne Klärung sofort in Hochglanz-Mocks springt, zeigt eine UI-Designer:innen-Haltung statt Produktdenken.

Strukturierte Critique-Methode: zuerst das Ziel des Flows klären (was soll erreicht werden?), dann die wahrscheinlichen Reibungspunkte identifizieren (Felder, Reihenfolge, Wortwahl, Fehlermeldungen), zuletzt konkrete Verbesserungsvorschläge mit Begründung. Tonfall: konstruktiv und konkret, nicht persönlich. Bonus: die:der Kandidat:in fragt nach Kontext (Zielnutzer:innen, Metrik), bevor pauschal kritisiert wird. Wer reflexhaft auf Visual oder Typografie zielt, ohne den Flow zu hinterfragen, zeigt eine oberflächliche Critique-Kompetenz.

Verständnis der Komponenten-Hierarchie (Tokens, Primitive, Komponenten, Pattern, Templates). Unterscheidung zwischen Pflege durch Designer:innen und Pflege durch Frontend (in KMU typischerweise geteilt). Bonus: die:der Kandidat:in nennt einen Fall, in dem das Design-System eine Inkonsistenz oder einen Bug verhindert hat, und benennt eine Komponente, die sie:er bewusst NICHT in das System aufgenommen hat. Wer pauschal mit Tailwind UI oder Material antwortet, ohne den eigenen Eingriff zu beschreiben, zeigt schwache Erfahrung.

Solide Methode: 5-8 Teilnehmende pro Test (typisch für qualitative Erkenntnisse), realistische Aufgaben (nicht zeigen Sie mir, wie..., sondern erledigen Sie X-Ziel), Beobachtung des Verhaltens statt Befragung der Meinung, Notizen oder Aufzeichnung. Bonus: die:der Kandidat:in nennt eine Erkenntnis, die das Design tatsächlich verändert hat. Wer in den letzten 3 Monaten keinen Test durchgeführt hat, ist von den Nutzer:innen entkoppelt. Wer Usability- und Präferenz-Tests verwechselt, zeigt eine Methoden-Lücke.

Pragmatische Übergabe: Figma mit klaren Komponenten und Spezifikationen (Auto-Layout, Tokens, Varianten), keine Pixel-Pushers-Mentalität, Pair-Sessions bei komplexen Interaktionen, Akzeptanz, dass Frontend kleinere Anpassungen vornimmt. Bonus: die:der Kandidat:in nennt Edge Cases, die explizit dokumentiert werden (Leerzustand, Fehlerzustand, Lade-Zustand, Responsive-Breakpoints). Wer 50-seitige Spec-PDFs liefert oder erwartet, dass das Frontend exakt jeden Pixel kopiert, hat im Tech-KMU schlechte Aussichten.

Offenheit: Fähigkeit, Design vom persönlichen Ego zu trennen. Bonus: die:der Kandidat:in nennt einen Fall, in dem sie:er durch eine Critique tatsächlich umgedacht hat. Wer beschreibt, der:dem Critique-Person die eigene Logik erklärt zu haben, anstatt zuzuhören, zeigt eine Schwäche in der Coachbarkeit; im KMU mit kleinem Designteam ist das ein hartes K.o.-Signal.

Aktive Mentorenhaltung: Pair-Sessions, pädagogische Critiques (nicht nur sieht gut aus), Dokumentation von Konventionen, Weitergabe guter Praktiken an Marketing- oder Frontend-Kolleg:innen, die im Alltag gestalten. Wer sagt Ich helfe, wenn ich gefragt werde, ohne mehr Konkretes, zeigt eine passive Haltung. Im KMU mit kleinem Designteam ist die Fähigkeit zur Weitergabe entscheidend für die Designreife des Unternehmens.

Anerkennung der Entwicklungen: Aufstieg generativer KI im Design-Workflow (UI-Generierung, Mock-Up-Drafts, Copy-Iteration), Verschiebung von reiner UI zu Discovery und Geschäftsimpact, Reife von Design-Systemen, wachsender Druck auf gemessenen Impact statt Pixel-Auslieferung. Kandidat:innen, die nur über Tools oder Buzzwords sprechen, zeigen eine oberflächliche Haltung; wer von Spannung zwischen Geschäft und Nutzer:innen, von Unsicherheit und empirischer Disziplin spricht, ist auf der Höhe.