日本語

UXデザイナーによくある失敗パターン（2年目に繰り返しを止めるには）

パフォーマンスレビューは悪くなかった。「実行力は確か。より戦略的なインパクトが必要」。あなたは頷き、成果をもっと自分で持つことについて適切なことを言いました。そしてデスクに戻りながら足元が傾くような感覚を覚えました。14か月間休みなく動いてきたのに、自分が動かしたビジネス指標を一つも名指しできないことに気づいたからです。

以下のパターンのうち一つを見つけて壊さない限り、6か月後も何も変わりません。2年目のデザイナーがシニアICへと成長する人と、チケット処理係として停滞する人に分かれるのは、だいたい入社18か月前後です。ほぼ例外なくFigmaのスキルの問題ではありません。7つの習慣の問題であり、そのすべてが当人には見えず、レビューを書くマネージャーには見えています。

これは自分を映す鏡です。TED講演ではありません。最も悪いパターンを1つ選んでください。修正してください。来月また次のパターンに戻ってきてください。

なぜ18か月目にこれが起きるのか

UXロールの最初の12か月は寛容です。製品、チーム、design system、ツールを学んでいます。4か月目に戦略的なインパクトを期待する人はいません。18か月目になると猶予期間が終わり、評価委員会は別の問いを立てます：この人は2年後にシニアになるのか、それとも着実にポリッシュ作業をこなすジュニアのまま永遠にいるのか？

その答えはほぼ例外なく技術的なスキルにありません。7つの繰り返すパターンにあります。どれも、その瞬間は生産的に感じられます。どれも、昇進の記録には「コンテキストの欠如」として現れます。

7つの失敗パターン

パターン1：「きれいにして」の割り込みに振り回されるIC

症状： PMからSlackのDMが週に4〜6回届き「この画面を素早くきれいにして」という依頼が来る。カレンダーの70%が受け身の対応、30%が自分の仕事。金曜日に疲れたが役に立てたと感じながら退勤し、自分が主導したものを何も指摘できない。

実際の数値： 週5件以上の予定外依頼を受けるデザイナーは、それを1つのブロックにまとめて対応する同僚と比べて、四半期あたりの担当プロジェクトリリース数が40%少ない。さらに厳しいのは、その予定外の作業が昇進書類に自分の仕事として記録されないことです。その機能の成果はPMのものになります。あなたの成果は「対応が速い」になります。

改善策： ポリッシュ依頼のためのオフィスアワーブロックを週1回（例：火曜と木曜の14〜16時）設ける。それ以外はLinearチケットを作成して通常のトリアージに回す。チームに一度伝える。2週間ラインを守る。PMがそれを尊重するからではなく、制約に適応するから流入が止まります。受け身対応は双方向の習慣です。

パターン2：「PMがすでに顧客と話した」を理由にユーザーリサーチをスキップする

症状： すべてのデザイン根拠が「PMがユーザーは…と言っていた」から始まる。過去60日間のユーザーとの直接接触がゼロ。エンジニアリングがフローに疑問を呈したとき、ユーザーが実際に何をするかではなくPMが覚えている内容しか言えない。

実際の数値： デザイナー主導のリサーチなしに設計された機能は、デザイナーが少なくとも1回のユーザーセッションを実施した機能と比べて、ローンチ後のリデザイン率が約2.3倍高い。PMは問題の枠組みが得意でデザインへの影響を読むのが苦手です。必要なシグナルは二次的な行動（カーソルがどこで止まるか、何を読み返すか、どのフィールドが放棄されるか）にあり、PMはそれを観察していません。

改善策： 四半期あたり5件のユーザーコール。交渉の余地なし。余裕ができたときではなく、四半期開始前にカレンダーに入れる。1回30分。最初から最後まで視聴して2つのパターンを書き出すなら、非モデレートのUserTestingのクリップでも構いません。次のデザインクリティークに証拠を持ち込む。逐語引用を持ってくるデザイナーのためにマネージャーはヘッドカウントを確保します。PMの言葉を言い換えるだけのデザイナーのためには確保しません。

パターン3：仕様の規律なしにFigmaに頼りすぎる

症状： エンジニアから毎回のハンドオフで同じ質問が来る。空の状態。エラー状態。ローディング。ブレークポイント。Slackスレッドで回答して、ファイルを更新しない。3週間後、Slackスレッドが埋もれているため別のエンジニアから同じ質問が来る。

実際の数値： 仕様が不完全な場合のFigmaハンドオフあたりの平均エンジニアリング質問件数は12〜18件。仕様が整っている場合は2〜3件。チケットあたり4〜6時間の開発時間節約に加え、より大きな成果があります：あなたの評判。「デザインの質」についての評判の半分はこの成果物に宿ります。エンジニアはポリッシュを見るのではなく、質問する前にファイルが問いに答えているかどうかを見ています。

改善策： すべてのカバーフレームに固定したハンドオフチェックリスト。空の状態・ローディング・エラー・320px・無効化・ホバー・アクセシビリティメモ。任意ではありません。「時間があれば追加する」でもありません。状態がファイルにない場合、エンジニアはそれが存在しないと判断して最善の推測でリリースします。そして次のスプリントでその推測をベースにリデザインすることになります。チェックリストをFigmaコンポーネントにしてください。初日からすべてのカバーフレームに配置してください。

パターン4：design systemを使う代わりに場当たり的なコンポーネントを作る

症状： 前回のリリースに微妙に異なるボタンスタイルが3種類ある。「少し大きくする必要があった」「DSのものがこのレイアウトにはうまく合わなかった」「後でシステムに戻す」。戻すことはない。

実際の数値： DS規律なしに半年経った製品を監査してください。ボタンバリアントが30〜60種類、モーダルパターンが8〜12種類、そしてエンジニアリング四半期単位で測定される保守コストが見つかります。今日リリースする場当たり的なコンポーネントは1つひとつ、DSチームが吸収するか戦うかしなければならない技術的負債です。彼らは気づいています。覚えています。

改善策： design systemにそれがない場合、画面のデザインを始める前にDS依頼を提出する。「ちょっと場当たり的に作ろう」をコードスメルとして扱う。本当に外れる必要があるとき（マーケティングの画面がプロダクトのルールに従わないなど、正当な理由がある場合）は、ファイルにその理由を記録する。DSチームには謝罪より、そのシグナルの方が必要です。理由なしの場当たりは不注意に見えます。理由ありの場当たりはデザイン判断に見えます。

パターン5：QAがフラグを立てるまでアクセシビリティを後回しにする

症状： コントラスト不合格、フォーカス状態の欠落、キーボードトラップがローンチの48時間前に発見される。最低でも四半期に2回。そのたびに、次回は早めにアクセシビリティを組み込もうと自分に言い聞かせる。そのたびに、次のスプリントが始まってデッドラインの圧力でQAまで先送りになる。

実際の数値： WebAIM Millionの年次スキャンによれば、ホームページの約96%に検出可能なWCAG違反があります。修正コストはデザイン段階で発見するよりローンチ後の方が10倍高くなります。アクセシブルなパターンを後からコードに組み込む作業は、最初から正しく設計するよりも多くのファイルに影響するからであり、また修正する最適な立場にある人物（元のデザイナー、元のエンジニア）がすでに次の作業に移っているからです。

改善策： レビュー前にすべてのフレームでStarkプラグインを実行する。ハンドオフ仕様にキーボードフローのメモを含める（「タブ順序、フォーカスリングの色、エスケープキーでモーダルを閉じる」、3行、すべてのモーダルに対して）。WCAG AAをチケットのP1受け入れ基準として扱う。後で対処する好ましい選択肢ではなく。アクセシビリティの向上のほとんどは決断であって作業ではありません。コンポーネント選択時に適切なコントラスト比を選択するのに追加の工数はかかりません。QAがフラグを立てた後に選択すると、1日分の手直し作業とリビルドがかかります。

パターン6：データを示す代わりに「信頼してほしい」と言う

症状： デザインクリティークでの回答が「ユーザーはこれを混乱すると感じるだろう」であり根拠がない。PMやエンジニアが反論しなくなり、議論に勝ったように感じる。そして自分の提案が優先されなくなっていることに気づく。信頼するのをやめた。議論するのをやめただけです。

実際の数値： 主要なデザインレビューでデータポイントを少なくとも1つ示すデザイナーは、直感から始めるデザイナーと比べて提案の採用率が2倍高い。データポイントは定量的なリサーチである必要はありません。サポートチケット数でも構いません。ファネルの離脱でも。NPSのコメントでも。セッション録画のタイムスタンプつきのクリップでも。基準は「厳密な調査」ではありません。「自分の頭の外からの証拠が1件ある」です。

改善策： すべての提案を1つの数値で始める。1つだけ。5つではありません（5つは守りに見えます）。ゼロでもありません（ゼロは意見に見えます）。ファネル離脱率、サポートチケット数、NPSコメント、セッション録画のタイムスタンプ、手元にあるものなら何でも。その数値が最強の議論である必要はありません。存在することが必要です。存在すれば、残りの推論が好みではなく分析として届きます。

パターン7：ローンチ後のインパクトを測定しない

症状： リリース日がゴールライン。2週間後、リデザインが動かすべきだった指標を動かしたかどうかわからない。マネージャーに「チェックアウトのリデザインはどうでしたか？」と聞かれて「コンバージョンが上がったと思います？」と言って話題を変える。

実際の数値： リリースに紐づいた指標を持つデザイナーは、機能をリリースするだけのデザイナーと比べて30〜40%速くシニアに昇進します。理由は神秘的ではありません。昇進委員会はインパクトを評価し、インパクトには事前の数値と事後の数値が必要です。キックオフ時に事前の数値を定義しなければ、事後の数値は意味をなさず、自分の作業が昇進書類に「Xをリリースした」ではなく「AからBにYを動かした」として記録されません。

改善策： すべてのプロジェクトについて、キックオフ前に成功指標と目標を書く。デザインブリーフの1文。「目標：ローンチから4週間以内にチェックアウトコンバージョンを2.1%から2.5%に引き上げる」。ローンチ2週間後、チームに1段落の結果メモを送る。悪い結果もカウントします。「リリースした、コンバージョンは動かなかった、学んだことはこれです」はキャリアにとってプラスです。成果物だけでなく成果を追跡していることを示します。悪い結果を隠すデザイナーはジュニアに見えます。公開するデザイナーはシニアに見えます。

まとめ：2年目デザイナーの自己レビュー

これが成果物です。コピーして使ってください。今週の金曜日に実施してください。

15分の週次習慣。Notionドキュメントを開く。毎週金曜日16時、退勤前に7つのパターンそれぞれを1〜5のスコアで自己採点する。トレンドを時系列で追跡する。3か月分のデータは1年間のあいまいな自己改善の記録より価値があります。

実施週：___________

1. 割り込みに振り回されるIC          [1-5]  メモ：
2. ユーザーリサーチのスキップ        [1-5]  メモ：
3. 仕様なしのFigma                   [1-5]  メモ：
4. 場当たり的なコンポーネント        [1-5]  メモ：
5. QAまで後回しのアクセシビリティ   [1-5]  メモ：
6. 「信頼してほしい」vs データ       [1-5]  メモ：
7. ローンチ後の測定なし              [1-5]  メモ：

今週の最低スコア：___________
来週適用する改善策1つ：___________

採点基準。5は正しい行動を体現していてメンタリングできる状態。3はパターンを認識しているがデッドラインが来ると習慣が崩れる。1は座って採点するまで気づかなかった状態。2年目のデザイナーのほとんどは最初に2が3〜4つ出ます。それが普通です。重要なのは絶対的なスコアではなく、トレンドラインが動いているかどうかです。

パターン3のハンドオフチェックリスト（今週これもリリースしたい方のために）：

ハンドオフチェックリスト（カバーフレームに固定）
□ 空の状態をデザインしてラベルを付けた
□ ローディング状態をデザインした（スケルトンまたはスピナー）
□ エラー状態（ネットワーク、バリデーション、サーバー）
□ 320px・モバイルのブレークポイント
□ 無効化・ホバー・フォーカスの状態
□ アクセシビリティ：コントラスト、キーボードフロー、フォーカスリング、ARIAメモ
□ エッジケース（長い文字列、ゼロデータ、100件以上のアイテム）
□ アナリティクスイベントの文書化

以上です。8つのチェックボックス。すべてのカバーフレームに固定してください。基本的な質問がすでに回答されているため、エンジニアはより質の高い質問をするようになります。

今週やること

最もスコアの低い失敗パターンを1つだけ選んでください。その改善策だけを実施してください。他の6つは待てます。

複数の改善策を同時に積み重ねても定着しません。1つなら定着します。1週目から7つすべての習慣を改革しようとするデザイナーは、3週目にはSlackの割り込みに振り回される状態に戻っています。最もスコアの低いパターン（たとえばパターン7のローンチ後の測定）を選んで3週間それだけに取り組むデザイナーは、次のレビューに新しい1行の実績を持参します：「今四半期3件のプロジェクトでローンチ後のインパクトを追跡した。2件は目標達成、1件は未達成で、学んだことはこれです」。その1文がシニアらしい姿です。

パターンに名前をつけることが修正の80%です。2年目のデザイナーに必要なのはさらなる理論ではありません。鏡が必要なのです。

金曜日に自己採点する。1つ選ぶ。1か月続ける。繰り返す。

関連記事