新人UXデザイナーの最初の30・60・90日

初日。Figmaにログインし、チームワークスペースを開くと、「OLD-DO-NOT-USE-final-v4」というファイルに47件の未読コメントが残っています。ワークスペースの上部にはFigmaライブラリが3つ固定されています：v2、v2.1、v3-WIP。どれも今しがた本番環境でリリースされたものと一致しません。PMから翌朝10時の「デザインレビュー」の予定が届きます。アジェンダはありません。

B2B SaaSにおけるUXへようこそ。

このガイドはプロダクトデザイナーの求人票テンプレートとセットです。求人票には採用の理由が書かれています。本記事は実際の業務の姿です。入社前に読んでいる方は印刷しておいてください。3週間目に読んでいる方も遅くありません。ほとんどの新人UXデザイナーは90日間のプランを持っておらず、だからこそ組織が望まない形のプランを押しつけてきます。

デザイナーにとって特に書面による30/60/90日プランが重要な理由

エンジニアリングにはスタンドアップがあります。PMにはロードマップとスプリント計画があります。営業には数字があります。デザイナーには…雰囲気？誰かが予約を覚えていれば月次デザインクリティークがある？

書面によるプランがなければ、最初の90日は最も声の大きいステークホルダーがその週に必要なものに塗りつぶされます。PMがスプリント計画の30分前に「ちょっとデザインレビュー」を設定してモックアップを持ち帰ります。エンジニアが16進数カラーコードについて連絡してきて、40分Figmaを触ることになります。3か月後には60件の小さなビジュアル修正をリリースして戦略的な作業はゼロ、マネージャーにどんな成果があったかを問われています。

書面による30/60/90日プランは、スコープの拡大、「きれいにして」の割り込み、「便利な画像ツール担当」扱いに対する最善の防衛手段です。4週目に誰かがなぜダッシュボードをリデザインしていないのかを尋ねてきたときに指し示せるものにもなります。

以下のプランは、中間レベルのUX採用（実務経験2〜5年）、個人貢献者として、シリーズAから上場企業まで幅広いB2B SaaS企業に入社した場合を想定しています。真剣なプロダクト業務のために採用されたはずです。マーケティングサイトのリデザインやブランドリフレッシュではありません。

1〜30日目：現状調査のみ。リリースしない。

新人UXデザイナーが犯す最大の間違いは、2週目に目立つ何かをリリースすることです。ダッシュボードのリデザイン。「モダン化した」空の状態。新しいカラートークン。生産的に見えます。進捗に見えます。6か月後、それがあなたが静かに業務から外されている理由にもなります。それを正当化するユーザーリサーチが誰にも見つからず、タイトなスプリントで3つのコンポーネントを作り直したエンジニアたちはあなたの味方ではなくなっているからです。

入社1か月目では、実際に正しいものをリリースするためのコンテキストがありません。だからリリースしないでください。

Design Systemの現状調査

ワークスペース内のすべてのFigmaファイルを開きます。一つ残らず全部。リストを作ります。各ファイルについて、最終編集日、最後に編集した人物、アクティブな仕様から参照されているか、チームの誰かが現在使用しているかを確認します。

次に、Figmaにあるものと本番環境にあるものを比較します。ライブアプリを開きます。ボタンを検査します。v2、v2.1、v3-WIPのボタンコンポーネントと比較します。乖離が見つかります。パディングが数ピクセル違う、角丸が異なる、Figmaには存在するがコードにはないホバー状態。これを記録します。

成果物：1ページの「design systemの実態確認」ドキュメント。コンポーネント名、存在するFigmaバージョン、本番環境バージョン、乖離の概要、所有者の曖昧さ。修正案はまだ提案しません。ただ記録します。このドキュメントが、整理しようとする前に混乱を理解していたことを証明する成果物になります。またQ1末の予算検討時にdesign systemへの投資の根拠となります。

ユーザーリサーチコール5件への参加

アクティブなリサーチ機能があれば、リサーチャーに今後のセッションへのサイレントオブザーバーとして追加してもらうよう依頼します。ない場合（200名未満のほとんどのB2B SaaS企業にはありません）は工夫が必要です。

営業に過去の録音済みディスカバリーコール5件を転送してもらいます。サポートにFullStoryまたはHotjarで最もよく見られているセッション録画10件を聞きます。新規顧客のオンボーディングコール2件に参加します。可能であれば解約コール2件も聞きます。

スライドデッキ的な意味での「インサイト」を探しているのではありません。言葉を学んでいます。ユーザーは製品をどう表現するか。機能を何と呼ぶか。フラストレーションを感じているときに繰り返し出てくる言葉は何か。課題だけでなく言語をメモします。2週目に習得した語彙は、6か月目にマイクロコピーを書き直す100時間を節約してくれます。

デザインからエンジニアリングへのフロー確認

最近UIの変更をリリースしたエンジニアひとりに座ってもらいます。Figmaフレーム、仕様の場所、design tokenの出所、パディングと色をコードに変換した方法、前のデザイナーに何を確認しなければならなかったか、何を独自に考案しなければならなかったかを端から端まで説明してもらいます。

それを1ページに図示します。デザイナー → Figmaフレーム → 仕様ドキュメント（どこに？）→ トークン（どこに？）→ エンジニア → Storybook（存在するか？最新か？）→ 本番環境。

ハンドオフが壊れている場所が少なくとも3か所見つかります。トークンが3つの異なるソースに存在する。Storybookが11か月更新されていない。仕様が誰が書いたかによってNotion、Confluence、Figmaコメントに分散している。これを記録します。90日間レポートのための2つ目の証拠成果物です。

UX負債の上位3件を特定する

「ホームページが古く見える」は対象外です。本物のフリクション。ビジネスコストを生んでいるか、サポート予算を消費しているものです。

該当する例：

• フィルターがページ再読み込み時に状態を失うため、ユーザーが別のページに移動するたびに作業をやり直している。
• オンボーディングに4つの行き止まり状態があり、ユーザーが回復パスなしで壁にぶつかっている。
• 一括操作バーがテーブルフッターのページネーションを覆っているため、1ページ目以降のアイテムを選択していることがわからない。

該当しない例：

• 「ボタンが古く見える」
• 「アイコンが統一されていない」
• 「モダンな感じがしない」

上位3件の特定方法：サポートチケット数、NPSのコメント、営業の反論点、参加したユーザーコールの4つを照合します。それぞれを次の形で記述します：観察された行動、証拠（チケット数、コールでの発言、セッション録画）、ビジネスへの影響。この3件が60日目と90日目の成果証明点になります。

1〜30日目に行わないこと

リリースです。

最初の1か月に目に見える成果物を提出するあらゆる依頼を断ります。「小さな勝利」も断ります。リデザインも断ります。ブランドリフレッシュも断ります。2週目に目立つものをリリースする新人デザイナーは、コンテキストがないために正しくなく、6か月後に静かに取り消される仕事をする同じ人物です。

PMが強く求めてきたら、返答はこうです：「最初のリリースはデータで正当化できるものにしたいです。4〜6週間後にそれが準備できます」。理性的なPMはほとんどこれを尊重します。そうでないPMはチームについて有用な情報を教えてくれています。

31〜60日目：実行、コントリビュート、小さくリリース

コンテキストが手に入りました。それを証拠とリリース済みの成果物に変えるときです。ただし小さく、スコープを絞り、正当化できるものにします。

ユーザビリティテストを1回実施する

UX負債の3件のうち1件を選びます。ユーザビリティテストを実施します。5名のユーザー。非モデレートで構いません。MazeまたはUserTestingなら200ドル以内で1週間以内にデータが得られます。リサーチ機能があれば、1セッションのモデレートを共同で行えるよう協力を求めます。なければ、5名の非モデレートユーザーのMazeがデータなしに勝ります。

2か月目の目標は「優れたリサーチ」ではありません。変更を提案する前にデータを提出することです。初めてデザインレビューに臨んで「5名のユーザーでテストしました。タスク完了率はこれで、詰まったのはここです」と言えたとき、会話の性質が永続的に変わります。意見を持つ人から証拠を持ってくる人になります。最初の90日間で得られる最大の信頼構築はこれです。

Design Systemにパターンを1件コントリビュートする

design system全体を修正しようとしないでください。それは底なし沼です。あなたより前にも試みた人がいて、中途半端に終わって、半分未完成のv3-WIPファイルを証拠として残しました。

1つのコンポーネントを選びます。フォーム入力フィールド。空の状態。トースト通知。Figmaにあるものと実際にリリースされているものを照合し、エンジニアに整合の取れたバージョンをStorybookにコミットしてもらい、トークンを文書化します。完了です。

これはどんなリデザインよりも速くエンジニアからの信頼を獲得します。エンジニアはdesign systemの乖離がいかに辛いかを知っています。あなたが入社する前から対処してきました。1つのコンポーネントを完全に修正することで、本当の仕事を理解していることが伝わります。90日間レポートでも指し示せる本物の成果物になります：「照合済みのコンポーネントを1件リリースしました。変更前後を示します。来四半期の同様の作業での速度向上を示します」。

小さなリデザインを1件リリースする

UX負債の3件のうち2件目を取り上げます。1スプリント（2か月ではなく2週間）に収まるようスコープを絞ります。1ページのブリーフを書きます：課題、証拠（ユーザーコールとユーザビリティテストから）、提案する変更、注目する指標。

指標が重要です。具体的なものを選びます。対象フローでのタスク完了率。対象画面のサポートチケット数。リデザインするアクションの初期価値実現時間。リリース前2週間測定し、リリースし、リリース後2週間測定します。結果が混在していても、「感覚的に良くなった」に頼らずデザインの影響を測定する習慣を身につけています。

初めての「きれいにして」チケットに返答する

B2B SaaSに届くデザイン依頼の約60%は、エンジニアやPMによるビジュアルの微調整依頼です。「このボタンを青にできますか」「ここのスペーシングをもう少し詰めてほしい」「このカードに影をつけてほしい」。

これらのほとんどは本物のUX課題ではありません。誰かの美的好みか、まだ明確に表現できていない本当の問題への対処法です。

SlackやチケットにペーストできるI文の返答を用意しておきます：

「確認します。どのようなユーザー行動がきっかけでこの依頼になりましたか？ビジュアルの好みであれば、次のdesign systemの改善と合わせて対応します。ユーザーが詰まっている場合は、表面ではなく根本的な問題を修正したいと思います」

一度、文章で、公開チャンネルで使ってください。1週間以内に「きれいにして」チケットの量が目に見えて減ります。作業を断っているのではありません。枠組みを変えているのです。ユーザーを気にするPMやエンジニアは根本的な問題を教えてくれて、本物の修正ができます。単なるビジュアル修正を求めていただけの人は静かにチケットを取り下げます。

61〜90日目：指標を担当し、後半の計画を立てる

1か月目と2か月目は方向性を設定する権利を得ることでした。3か月目はそれを設定するときです。

UX指標を1件担当する

測定可能で可視化されたUX指標を1件選び、自分の名前を紐付けます。5件ではありません。1件です。

B2B SaaSで機能する候補：

• 主要なオンボーディングフローでのアクティベーション率
• 製品で最も使われるワークフローのタスク完了率
• 担当している特定の機能領域でのNPS
• 自分のスコープ内の画面でのサポートチケット数
• 新規ユーザーの初期価値実現時間

可視化します。毎週Slackチャンネルに投稿します。チームダッシュボードに追加します。デザインクリティークで参照します。目的は数字を守ることではありません。特定のフローのユーザーの状況を信頼性高く把握しているチームメンバーになることです。1四半期以内に、誰かが「オンボーディングの調子はどうか」と聞いたとき、周囲の人があなたのことを思い浮かべるようになります。

90日間レポートを提出する

1つのドキュメント。5つのセクション。各1ページ。90日目までにマネージャー、PM、エンジニアリードに送ります。

1. 調査した内容。 design systemの乖離の発見、デザインからエンジニアリングへのフロー図、UX負債の上位3件。
2. リリースした内容。 照合済みコンポーネント、小さなリデザイン、変更前後の指標。
3. ユーザーについて学んだこと。 5件のコール + ユーザビリティテストからの主要パターン。汎用的なインサイトではなく、引用つきの具体的な行動。
4. 壊れているもの。 連携の欠如、ツールのギャップ、リサーチのギャップ。
5. 後半に向けた提案。 3〜5件の施策。それぞれの形式：仮説、証拠、実験、成功指標。

このレポートをスキップすることが、新人デザイナーが犯す最大の自滅的な間違いです。自分の仕事についてのナラティブを自分で設定できる唯一の機会です。これを逃すと、6か月後の評価で誰かが代わりにそれを設定します。

後半のデザイン計画を提案する

3〜5件の施策。「Xをリデザインする」ではなく、製品のKPIに結びついたものです。

悪い施策の例：「ダッシュボードをリデザインする」

良い施策の例：「データソース接続までの時間を8分から2分未満に短縮することで、ダッシュボードのアクティベーション率を34%から50%に引き上げる。仮説：新規ユーザーのほとんどがデータ接続の段階で離脱している。証拠：ユーザビリティテストで5名中4名がデータピッカーで詰まった。実験：サンプルデータフォールバックつきの3ステップガイド付きセットアップをリリース。成功指標：7日目のアクティベーション率」

各施策には仮説、証拠（調査、ユーザビリティテスト、サポートチケット）、実験、成功指標があります。5件で十分です。3件でも問題ありません。施策の数より枠組みの質が常に重要です。

業務リズムを確立する

誰かのリズムに飲み込まれる前に、自分のリズムをチームカレンダーに入れます。

• デザインクリティーク：週1回、45分、自分が運営
• リサーチレビュー：隔週、30分、ユーザーから聞いた内容を共有
• Design Systemオフィスアワー：週1回、30分、誰でもコンポーネントの質問を持ち込める
• エンジニアリードとの1on1：隔週、30分、ハンドオフとツールについて話す

これらは選択肢ではありません。設定しなければ、毎週が永遠に受け身のままです。

持ち続けるべき現実的な見方

「きれいにして」の割り込みは完全になくなりません。 何件かについて枠組みを変えれば縮小するだけです。1文の返答を手元に置いておきましょう。丁寧に使いましょう。

design systemのバージョン乖離は永続的です。 Figmaライブラリは間違っていると仮定してください。正解の情報源はリリースされているものです。まず本番環境を調査し、次にFigmaを調査します。新人デザイナーはFigma同士の照合に何週間も費やします。重要な照合はFigmaと本番環境の照合だけです。

Figmaで事前にモックアップを作るPMはあなたの敵ではありません。 空白を埋めているだけです。1週目は反論しないでください。2か月目には「方向性は気に入っています。仕様を確定する前に3名のユーザーで確認しましょう」とリダイレクトします。3か月目には、あなたが最初に方向性を求められるようになります。

UXリサーチ機能がなければ、それはあなたです。 公式にも、フルタイムでもありませんが、意思決定が意見主導から脱却するには十分な範囲で。月5件のユーザーコールは50名のSaaSにとってリサーチ機能です。週2時間のセッション録画確認はリサーチ機能です。肩書きではなく実践を確立してください。

避けるべき失敗パターン

• 1か月目にダッシュボードをリデザインする。コンテキストがありません。
• 最初のプロジェクトとしてdesign system全体を修正しようとする。底なし沼です。1つのコンポーネントを完全に修正してください。
• すべての「きれいにして」チケットにYESと言う。組織にPhotoshop担当扱いされる習慣をつけます。
• 90日間レポートをスキップする。ナラティブを設定できる最善の機会を失います。
• 90日間何も見せずに、40ページの調査報告書だけ出す。小さく目に見える成果は、大きく見えない調査報告書に常に勝ります。

90日目の成功評価

最初の90日間の終わりに、正直な評価基準はこうなります：

• 意見ではなくデータで上位3件のユーザーフリクションポイントを説明できる。
• 測定前後のある小さなリデザインを1件リリースした。
• FigmaとProductionの間でdesign systemのコンポーネントを少なくとも1件照合した。
• チームが毎週確認する可視化されたUX指標を1件担当している。
• PMとエンジニアリードと後半計画が承認済みか、活発な議論中である。
• 「きれいにして」チケットが「このユーザー行動を見てもらえますか」に大方置き換わっている。

6つのうち4つを達成できれば、90日目としてB2B SaaSのほとんどのUX採用者より先を行っています。6つすべてを達成できれば、後半に戦略的な方向性を設定する権利を得ています。そこからが本当に面白い仕事の始まりです。

採用された期待内容とここからの役割の成長についての詳細はプロダクトデザイナーの求人票テンプレートをご覧ください。このガイドの90日間の期待値は、求人票が説明している内容の実践版です。

関連記事

• プロダクトデザイナーの求人票テンプレート
• Design System監査の実施方法
• ゼロ予算でのユーザビリティテスト
• 「きれいにして」依頼への上手な対処法