Deutsch

7 Fallen, die Product-Designer-Karrieren still zum Entgleisen bringen (und wie Sie sie an sich selbst erkennen)

Sie sind aus Ihrem zweiten Leistungsgespräch herausgekommen und haben dasselbe gedacht wie nach dem ersten: schon wieder "erfüllt die Erwartungen." Dieselben Screens. Dieselben Zahlen. Dasselbe Kalibrierungskomitee, das anscheinend kein Figma-File lesen kann. Sie haben die E-Mail fast nochmals geöffnet, um eine Antwort zu verfassen, haben es aber nicht getan, weil irgendwo unter der Frustration eine leisere Frage steckte: Was, wenn es nicht an ihnen liegt?

Ich habe in den letzten Jahren ungefähr 200 Mid-Level-Designer-Portfolios gesichtet, und ich spare Ihnen viel Rätselraten. Der Grund, warum die meisten Product Designer zwischen IC2 und IC3 stagnieren, ist nicht Talent. Nicht Geschmack. Nicht einmal das Kalibrierungskomitee, obwohl es manchmal auch irrt. Es liegt daran, dass Sie eines bis drei der sieben folgenden Muster unsichtbar betreiben, und jedes Quartal, in dem Sie sie nicht erkennen, sind drei Monate falsche Gewohnheiten, die sich aufschaukeln.

Ich habe alle sieben selbst gemacht. Deshalb weiß ich, wie sie von innen aussehen.

Warum das jetzt wichtig ist

Mid-Level ist das längste Stück einer Design-Karriere und das, in dem man am leichtesten stecken bleibt. Senior-IC-Rollen sind bei jedem Unternehmen auf unterschiedlichem Niveau gedeckelt, aber das strukturelle Muster ist dasselbe: Unternehmen haben viele IC2s, weniger IC3s, und die Lücke zwischen ihnen hat selten mit geleisteten Stunden zu tun. Es geht darum, welche Muster Sie auf Autopilot betreiben.

Das Ärgerliche ist, dass sich alle sieben Fallen produktiv anfühlen, während man in ihnen steckt. PM-Specs ausführen fühlt sich wie Ausliefern an. Critique überspringen fühlt sich wie Fokus an. Den Empty State polieren fühlt sich wie Handwerk an. Die Arbeit verbirgt das Problem vor Ihnen, weshalb Sie eine Checkliste brauchen, denn Ihr Bauchgefühl hat bereits alle diese Entscheidungen abgesegnet.

Das möchte ich von Ihnen. Lesen Sie jede Falle. Bewerten Sie sich am Ende ehrlich. Nehmen Sie sich die schlimmste vor. Führen Sie den Fix eine Woche lang durch. Kommen Sie in 30 Tagen zurück und bewerten Sie erneut.

Falle 1: PM-Specs ausführen ohne Discovery

Symptom: Sie haben Figma geöffnet, bevor Sie das Research-Dokument gelesen haben. Sie können im Detail beschreiben, was das Feature tut, aber wenn ich frage "Welches Problem lösen wir und für wen?", beschreiben Sie eine Lösung, kein Problem.

Die Zahl: Bei meinen eigenen Portfolio-Reviews können etwa zwei Drittel der Mid-Level-Designer das Nutzerproblem hinter ihrem letzten ausgelieferten Feature nicht ohne Bezug auf das PRD des PM beschreiben. Sie können das Feature beschreiben, nicht aber den Nutzer. Das ist das Zeichen.

Warum es Sie aufhält: Designer, die Specs ausführen, sind austauschbar mit jedem kompetenten Auftragnehmer. Designer, die das Problem neu formulieren, sind die, für die PMs kämpfen, um sie in ihrem Team zu behalten. Staff Designer werden nicht befördert, weil sie das Briefing ausgeführt haben. Sie werden befördert, weil sie das Briefing verändert haben.

Der Fix (diese Woche): Bevor Sie Figma auf dem nächsten Ticket öffnen, schreiben Sie in eigenen Worten ein 100-Wort-"Problem-Briefing." Nur drei Dinge: Wer hat das Problem, welchen Schmerz umgehen sie derzeit, was wäre in ihrer Woche anders, wenn wir es lösten? Schicken Sie es Ihrem PM mit einer Frage: "Ist das, was wir lösen?" Wenn der PM Sie korrigiert, gut, Sie haben etwas gelernt. Wenn der PM zustimmt, haben Sie jetzt gemeinsamen Kontext, der stärker ist als jedes PRD. Tun Sie das für vier Tickets hintereinander. Beim fünften Ticket wird der PM Ihnen das Problem-Briefing anstelle der Spec schicken.

Falle 2: Beim Handoff übergeben und danach abtauchen

Symptom: Ein Feature, das Sie entworfen haben, wurde vor sechs Wochen ausgeliefert. Können Sie mir spontan die Adoptionsrate nennen? Das Conversion-Delta? Das häufigste Support-Ticket, das es erzeugt hat? Wenn Sie raten, haben Sie beim Handoff übergeben und sind untergetaucht.

Die Zahl: Die meisten Mid-Level-Designer, die ich gesichtet habe, können weniger als zwei Post-Launch-Metriken für die letzten drei von ihnen ausgelieferten Features nennen. Die starken können fünf für ein einziges Feature nennen. Diese Lücke ist die Lücke zwischen "Designer" und "Product Designer."

Warum es Sie aufhält: Ihre Arbeit endete nicht, als der Engineer den PR gemergt hat. Der gesamte Sinn des Titels "Product Designer" liegt im Wort "Product", und Produkt bedeutet Ergebnisse, keine Artefakte. Wenn Sie nicht wissen, was nach dem Launch passiert ist, können Sie nicht lernen, nicht iterieren und keinen Fall für Ihre eigene Beförderung aufbauen. Ihre Selbstbeurteilung liest sich wie eine Feature-Liste, weil Sie kein Ergebnisprotokoll haben.

Der Fix (diese Woche): Nehmen Sie Ihre letzten drei ausgelieferten Features. Finden Sie für jedes eine Zahl (Adoption, Conversion, Retention, NPS, Support-Ticket-Anzahl, irgendetwas Quantitatives). Wenn Ihr Unternehmen Amplitude oder Mixpanel betreibt, lernen Sie das grundlegende Chart in 30 Minuten. Wenn nicht, fragen Sie Ihren PM oder Data-Analysten namentlich in Slack: "Wie hoch ist die Adoptionsrate bei X nach sechs Wochen?" Tun Sie das an einem Freitag. Fügen Sie die Zahlen einem laufenden Dokument namens "ausgeliefert und gemessen" hinzu. Dieses Dokument ist Ihr nächstes Beförderungspaket.

Falle 3: Critique überspringen, weil es unangenehm ist

Symptom: Im Kalender gibt es eine regelmäßige Team-Crit. Sie waren bei drei der letzten fünf Sessions "im Flow-Zustand" und haben sie übersprungen. Sie sagen sich, das sei geschützte Designzeit. Das ist sie nicht. Das ist geschützte Ego-Zeit.

Die Zahl: Designer, die regelmäßig an Critiques teilnehmen, verbessern sich bei Craft-Scores in 360-Reviews etwa 1,5- bis 2-mal schneller als diejenigen, die sie überspringen, in jedem Team, das ich bei der Nachverfolgung beobachtet habe. Der Mechanismus ist nicht rätselhaft. Sie können Ihre eigenen blinden Flecken nicht sehen. Critique ist buchstäblich die einzige Zeit, in der ein anderer Designer bezahlt wird, sie für Sie zu finden.

Warum es Sie aufhält: Sie betreiben ein Experiment ohne Feedbackschleife. Sie liefern Arbeit aus, erhalten einen Daumen hoch von einem PM der kein Designer ist, liefern mehr Arbeit mit denselben verborgenen Mängeln aus. Senior Designer, die das Muster in 30 Sekunden während einer Critique hätten aufzeigen können, sehen Ihre Arbeit nie, bis sie bereits in Produktion ist, wo sie zu reparieren 50-mal teurer ist.

Der Fix (diese Woche): Bringen Sie etwas zur nächsten Crit. Nicht Ihre beste Arbeit. Ihre unsicherste Arbeit. Konkret: den Screen, den Sie viermal neu gezeichnet haben und immer noch nicht mögen. Stellen Sie eine Frage: "Ich kann nicht sagen, ob die Hierarchie hier richtig gelesen wird. Wo landet Ihr Auge zuerst?" Diese Frage verwandelt Critique von einer Vorführung in eine Diagnose. Wenn Ihr Team keine regelmäßige Crit hat, vereinbaren Sie einmal pro Woche eine 30-minütige "Design-Sprechstunde" mit einem Senior Designer. Bringen Sie zwei Screens, stellen Sie zwei Fragen, gehen Sie pünktlich.

Falle 4: Daten ignorieren, wenn sie Ihrem Geschmack widersprechen

Symptom: Die Analytik zeigt, dass Nutzer die Variante bevorzugen, die Sie nicht entworfen haben. Sie hören sich sagen: "Die Daten sind nur richtungsweisend" oder "Der Test war nicht sauber" oder "Nutzer wissen nicht, was sie wollen." Sie haben diese Sätze nie verwendet, wenn die Daten Ihnen recht gegeben haben.

Die Zahl: Bei einem Unternehmen, für das ich gearbeitet habe, führten wir eine stille Überprüfung der Reaktionen von Designern auf A/B Tests durch. Wenn der Test die bevorzugte Variante des Designers bestätigte, akzeptierte der Designer das Ergebnis zu 95%. Wenn der Test dem Designer widersprach, fiel die Akzeptanzrate auf etwa 40%, und der häufigste Ablehnungsgrund waren "methodische Bedenken." Dieselben Designer, dieselbe statistische Strenge, völlig unterschiedliche Akzeptanz. Das ist keine Analyse. Das ist Abwehrhaltung.

Warum es Sie aufhält: Sie sind kein Designer, wenn Sie nur auf Daten hören, die Ihnen schmeicheln. Sie sind ein Künstler mit einer Figma-Lizenz. Der einzige Grund, warum Design in den letzten 15 Jahren einen Platz am Produkttisch verdient hat, ist der Anspruch, dass wir das Nutzerverhalten empirisch betrachten. In dem Moment, in dem Sie das zugunsten des Egos aufgeben, geben Sie den Platz auf.

Der Fix (diese Woche): Finden Sie eine Entscheidung im letzten Quartal, bei der Sie Daten überstimmt oder heruntergespielt haben. Schreiben Sie auf, was die Daten sagten und was Sie entschieden haben. Schreiben Sie jetzt die Nachbetrachtung: Hat Ihre Entscheidung funktioniert, oder hatten die Daten letztendlich recht? Machen Sie diese Übung allein, nicht in einem Meeting. Der Punkt ist nicht öffentliche Reue, sondern den Muskel aufzubauen, "Ich habe recht" von "Ich möchte recht haben" zu trennen. Einmal im Quartal wiederholen. Nach einem Jahr werden Sie Ihrem Gespür mehr vertrauen, weil Sie wissen werden, in welchen Fällen es sich wirklich bewahrheitet hat.

Falle 5: Einmalige Komponenten statt System-Beiträge ausliefern

Symptom: Ihr neuestes Feature hat 14 Button-Varianten in der Figma-Datei. Das design system hat 3. Die meisten davon haben Sie selbst auf der Seite gestylt, um 1 Uhr nachts, weil das System "nicht hatte, was Sie brauchten."

Die Zahl: In einer gesunden Design-Organisation sollten Individual Contributors 1 bis 3 design system-Beiträge pro Quartal leisten, auch als IC2. Die meisten stagnierenden Mid-Level-Designer, die ich gesichtet habe, haben in den letzten 12 Monaten null geleistet. Null. Ihre Figma-Files sind voller losgelöster Komponenten und eigener Schatten, die niemand anderes wiederverwenden kann.

Warum es Sie aufhält: Zwei Gründe. Erstens ist jede Einmal-Komponente, die Sie ausliefern, technische Schulden, die Ihre zukünftigen Teammitglieder zahlen. Zweitens sind design system-Beiträge eines der klarsten Signale für Seniorität. Beförderungskomitees können sie sehen, zählen und nachverfolgen. Ihre eigenen Tokens? Unsichtbar. Sie werden auf Ihrem Impact-Konto auf null abgerundet.

Der Fix (diese Woche): Überprüfen Sie Ihr letztes ausgeliefertes Feature. Zählen Sie die Komponenten, die Sie außerhalb des Systems gestylt haben. Fragen Sie für jede: Sollte das im System existieren? Wenn ja, schreiben Sie einen Absatz langen Vorschlag: "Wir haben Variante X in Kontext Y ausgeliefert, hier sind weitere Einsatzorte, hier ist der vorgeschlagene Token-Name." Schicken Sie ihn an denjenigen, dem das design system gehört. Wenn niemand das design system besitzt, ist das ein separates Problem, und wahrscheinlich eine Staff-Chance für denjenigen, der die Hand hebt. In jedem Fall haben Sie das seniorste Ding getan, das ein Mid-Level-Designer diesen Monat tun kann.

Falle 6: Screens mit geringem Hebel übermäßig polieren

Symptom: Sie haben zwei Tage am Empty State einer Einstellungsseite gearbeitet. Unterdessen wurde der Checkout-Flow mit einer Abbruchrate von 38% seit acht Monaten nicht angetastet, weil "niemand ihn priorisiert hat." Sie haben den Empty State gewählt, weil er Spaß machte und begrenzt war. Der Checkout-Flow ist unübersichtlich und politisch.

Die Zahl: Ich habe einmal einen feststeckenden IC2 gebeten, die Nutzerreichweite seiner letzten fünf Projekte einzuschätzen. Top drei zusammen: etwa 800 monatliche Nutzer. Die zwei, die er nicht gewählt hatte: etwa 140.000. Derselbe Designer, dieselbe Woche, zwei Größenordnungen Unterschied im Hebel, völlig unsichtbar für ihn, bis er es aufschrieb.

Warum es Sie aufhält: Handwerk auf einem wenig frequentierten Screen liest sich als Poliering. Handwerk auf einem Screen mit hohem Hebel liest sich als Urteilsvermögen. Beförderungskomitees bemerken das Zweite. Das Erste überfliegen sie. Und ehrlich gesagt ist Ihre Zeit die teuerste Ressource in Ihrer Organisation. Sie auf Screens zu verbringen, die 800 Menschen sehen, während der Flow für 140.000 Nutzer verrottete, ist der teuerste Fehler, den Sie still machen können.

Der Fix (diese Woche): Erstellen Sie eine "Hebelliste" für alles, woran Sie arbeiten. Drei Spalten: Projektname, geschätzte betroffene Nutzer, Ihre Stunden in diesem Monat. Sortieren Sie nach Stunden pro Nutzer (geringer ist besser). Alles im obersten Viertel, wo Sie viele Stunden auf Screens mit wenigen Nutzern verwenden, ist ein Kandidat, um priorisiert oder neu gerahmt zu werden. Bringen Sie diese Liste in Ihr Manager-1:1 und fragen Sie: "Arbeite ich an den richtigen Dingen?" Die meisten Manager werden Ihre Arbeit innerhalb einer Woche umverteilen. Die, die es nicht tun, werden zumindest wissen, dass Sie über Hebel nachdenken.

Falle 7: Den eigenen Impact nicht messen

Symptom: Es ist Selbstbeurteilungszeit. Sie öffnen das Formular. Sie beginnen, Features aufzulisten, die Sie ausgeliefert haben. Das Dokument liest sich wie eine Release-Notes-Seite. Es gibt keine Zahlen. Kein Vorher/Nachher. Kein "Dieses Ding, das ich getan habe, hat dazu geführt, dass sich jenes geändert hat."

Die Zahl: Ich habe hunderte von Selbstbeurteilungen gelesen. Die IC2s, die zu IC3 befördert wurden, hatten im Schnitt 4 bis 7 quantifizierte Ergebnisse in ihrem Paket (Zahlen, die an spezifische Entscheidungen geknüpft sind). Die IC2s, die nicht befördert wurden, hatten 0 bis 1, plus eine lange Feature-Liste. Dieselben Unternehmen, dieselben Kalibrierungen, in vielen Fällen dieselben Designer. Das Paket macht den Unterschied.

Warum es Sie aufhält: Beförderung ist eine Erzählübung, und der Protagonist ist Impact, nicht Output. Ihr Manager geht in die Kalibrierung mit dem, was Sie ihm geben. Wenn Sie "12 Features ausgeliefert" geben, müssen sie Sie nach Volumen verteidigen, das jeder hat. Wenn Sie "X redesignt, Aktivierung um 14% gesteigert" geben, haben sie eine klare Geschichte, die Kalibrierer sich merken. Die meisten stagnierenden Mid-Level-Designer denken, Kalibrierung dreht sich um Verdienst. Es dreht sich um Erzählqualität, und die Erzählung wird aus den Beweisen gebaut, die Sie aufgeschrieben haben.

Der Fix (diese Woche): Öffnen Sie ein Dokument namens "Impact-Log." Jeden Freitag 15 Minuten lang drei Punkte schreiben: Was wurde diese Woche ausgeliefert, welche Zahl hat sich dadurch geändert (auch eine grobe), was Sie anders machen würden. Acht Wochen davon, und Sie haben mehr quantifizierte Beweise als 80% Ihrer Peers, und das Ritual des Aufschreibens wird leise verändern, woran Sie arbeiten, denn niemand möchte acht Freitage hintereinander schreiben "Ich habe einen Empty State poliert, den niemand gesehen hat."

Das ehrliche Selbst-Audit

Freitagnachmittag, 15 Minuten, keine Geräte außer dieser Checkliste. Bewerten Sie sich 0, 1 oder 2 für jede Falle. 0 bedeutet, das trifft nicht auf Sie zu. 1 bedeutet, Sie tun es manchmal. 2 bedeutet, Sie haben es gelesen und sich ertappt gefühlt.

  1. Ich öffne Figma, bevor ich das Problem verstehe.
  2. Ich kenne die Adoptionsrate meines letzten Features nicht.
  3. Ich überspringe Critique, wenn ich beschäftigt bin.
  4. Ich ignoriere Daten, die mir widersprechen.
  5. Ich liefere Einmal-Komponenten statt System-Beiträge aus.
  6. Ich poliere Screens mit geringem Hebel übermäßig.
  7. Meine Selbstbeurteilung liest sich wie eine Feature-Liste.

Addieren Sie.

  • 0 bis 3: Sie sind in Ordnung. Nehmen Sie den höchsten Einzelscore und justieren Sie nach. Sie sind wahrscheinlich näher an IC3, als Ihr Manager bemerkt hat.
  • 4 bis 7: Stagnationsgefahr. Drei oder mehr dieser Muster laufen im Hintergrund und verstärken sich gegenseitig. Nehmen Sie den höchsten Score, führen Sie den 7-Tage-Fix durch, bewerten Sie in 30 Tagen erneut.
  • 8 oder höher: Sie stagnieren bereits. Das ist kein moralisches Urteil, sondern eine Diagnose. Dieselben Muster, die Sie zu IC2 gebracht haben, blockieren jetzt IC3. Nehmen Sie sich zwei Fallen vor, nicht eine, und führen Sie beide Fixes einen Monat lang durch. Sagen Sie Ihrem Manager, dass Sie das tun. Bitten Sie um ein 30-Tage-Check-in.

Was Sie am Montag tun

Wählen Sie eine Falle, Ihren höchsten Score oder die, bei der Sie sich beim Lesen am unwohls­ten gefühlt haben. Das ist meist dieselbe. Blockieren Sie am Montagmorgen 90 Minuten, um den 7-Tage-Fix dieser Falle durchzuführen. Fügen Sie eine wiederkehrende 30-Tage-Kalendererinnerung hinzu, um das Audit erneut zu bewerten. Das ist alles. Nehmen Sie sich nicht alle sieben auf einmal vor. Sie werden ausbrennen, alle oberflächlich angehen und in drei Monaten wieder hier sein und fragen, warum sich nichts geändert hat.

Die Designer, die IC2 zu IC3 schaffen, sind nicht die, die alle sieben beheben. Es sind die, die bemerken, dass sie zwei davon betreiben, einen beheben und den anderen still einstellen, weil das Bewusstsein allein etwa die Hälfte der schlechten Muster tötet. Das Audit ist die Arbeit.

Wenn Sie ein schärferes Bild davon möchten, wie gut auf dem nächsten Level tatsächlich aussieht, legt die begleitende Stellenbeschreibung für diese Rolle die Verantwortlichkeiten und Ergebnismetriken dar, die IC3+-Designer erfüllen sollen. Nützlich als Ziel, nicht als Falle.

Mehr erfahren