日本語

UXデザイナーの1日(B2B SaaS・IC編)

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

求人票には「美しい体験をデザインし、プロダクトの未来を形づくる」と書いてありました。実際に昨日やったことは、確認モーダルにキャンセルボタンが必要かどうかをエンジニアと90分議論し、その後「もっとパッとさせて」というのはデザインブリーフにならないことを営業担当に40分かけて説明することでした。B2B SaaSのUX、ようこそ。

理想と現実は別の仕事です。理想はDribbbleのショット、ムードボード、ステークホルダーから拍手喝采を浴びる瞬間です。現実はリサーチメモ、仕様の議論、そして「Frame 142」「Frame 143」「Frame 144」という名前のフレームが47個並んだFigmaファイルです。どちらも現実に存在します。ただし、あなたの仕事は後者の方です。

これは、実務経験1〜5年のUXデザイナーの普通の平日の姿です。華やかさはありません。ポートフォリオ映えする瞬間もありません。ただ業務の実際のリズム、誰も事前に教えてくれない時間を奪う作業、そして「疲れたけどよかった」という気持ちで帰れるか「疲れてやりきれない」という気持ちで帰るかを左右する小さな習慣があるだけです。

午前8時02分:FigmaとSlackのトリアージ

まずFigmaを開きます。3つのファイルに夜間のコメントが入っています。別のタイムゾーンにいるエンジニアから2件、遅い時間まで働いているPMから1件です。

次にSlackを開きます。DMと#design-teamチャンネルに未読が12件。そのうち1件はダッシュボードのスクリーンショットを添付した営業担当から「もっとモダンに見せてほしい」というメッセージ。もう1件はカスタマーサクセス担当がエクスポートボタンが見つからないという顧客のスレッドにあなたをタグ付けしたもの。残りはノイズです。

正しくやれば、このトリアージは10分で終わります。3つのカテゴリに分けます。

エンジニアリングを止めている問題。 Figmaファイルにある状態の仕様が不明でエンジニアが止まっています。後回しにするとコストが最も高い割り込みです。3時間待つと、彼らは別のタスクに切り替え、そのコンポーネントのリリースが1週間遅れます。今すぐFigmaのコメントで返答します。2文の回答、仕様フレームのスクリーンショット、Storybookコンポーネントがあればリンク。終わったら次へ。

「きれいにして」系の依頼。 営業担当がダッシュボードを「もっとパッとさせて」と言っています。実在する人物からの現実的な要望であり、誠実な返答は必要です。ただし、あなたの午前を使う必要はありません。Slackで返信します:「ビジュアルポリッシュのバックログに追加します。1つ確認させてください。見た目が課題で具体的に取りたいと思っているお客様がいるのでしょうか、それとも全体的な印象の話でしょうか?」9割のケースで「全体的な印象」という答えが返り、依頼は自然に消えます。残りの1割は実際の顧客エスカレーションで、デザインリードに引き継ぎます。

仕様の質問。 「ユーザーの検索結果が0件のとき、この状態はどう表示されますか?」これは本物の問いで、時間を使う価値があります。ただし同期での回答は不要です。午前10時の非同期ブロックに回します。

朝のトリアージは華やかではありません。それでも1日の中で最もレバレッジの高い15分です。トリアージをしないデザイナーは1日ずっと受け身です。上手にやるデザイナーは自分の1日の形を自分でつくります。

午前10時:非同期スペックブロック

学校では誰も教えてくれなかった仕事の内側がここにあります。「デザイン」時間のほとんどは書くことです。

Notionを開きます。朝のトリアージから持ち越した未回答の仕様の質問が3件あります。それぞれに対して議論を再燃させない、議論を終わらせる書き言葉による回答が必要です。

悪い回答:「トースト通知にすべきだと思いますが、どう思いますか?」これは6往復のスレッドを生みます。決断をエンジニアに投げ返しているからです。

良い回答:「トースト通知、右上、4秒で自動非表示。Storybookの既存 <Toast variant='success'> コンポーネントを再利用。仕様はファイルのFrame 47参照。APIのレスポンスが8秒超の場合、トーストではなく永続表示のインラインバナーに切り替え(Frame 48にそのバリアント)。Linearチケットのリンクは下記。」

良い回答を書くのに6分かかります。悪い回答は30秒で書けますが、その後2日間でチームから1時間を奪います。これは身をもって学びました。

習慣として:すべての仕様の回答は3つのことで終わります。決断の内容、コンポーネントの参照(StorybookリンクまたはFigmaのフレーム番号)、そしてLinearまたはJiraのチケットへの紐付け。例外なし。この証跡こそが目的です。6か月後に「なぜこう作ったのか」と誰かに問われたとき、その証跡が過去の決断を蒸し返さずに済む手段になります。

非同期ブロックは午前10時から11時30分まで。4件のスペックスレッドに回答し、パターン上の決定について短いNotionドキュメントを1件書き、実際にはエンジニアがファイルを読んで自己解決していた2件のFigmaコメントをクローズします。最後のケースは静かな勝利です。自分のファイルが読むだけで理解できるということを意味します。

午後12時:モデレートユーザビリティテスト

まずランチ。テストは12時30分開始で、テスト計画を読み返す必要があるため、デスクでサンドイッチを食べます。本来はしっかり休憩を取るべきです。テスト当日はそうならないのが現実です。

テストは30分、モデレートあり、Mazeで実施。200名規模の物流会社の請求担当マネージャーという実際の顧客に参加してもらいます。新しい請求書エクスポートフローをテストしています。仮説は「新しいフローでエクスポートまでの時間が90秒から30秒未満に短縮できる」こと。帰無仮説は「新しいフローが旧フローになかった混乱を生じさせる」ことです。

新人デザイナーが陥りがちな間違いがここにあります。ユーザーが何を言うかを見ているのではありません。何をするかを見ています。言語的なフィードバックはほとんどノイズです。ユーザーは助けたいと思っています。カーソルが9秒間間違ったボタンの上で止まりながら「とても直感的です」と言います。カーソルの位置がデータです。「直感的」は礼儀です。

実際に注目していること:

  • ためらい。 カーソルが止まる。視線が画面の別の場所に動く。ユーザーがラベルを読み直す。2秒以上クリックなしでホバーしていれば要注意サインです。
  • 誤クリック。 間違ったものをクリックし、戻って、正しいものをクリックする。その誤クリックが、ビジュアル階層が優先度を誤って伝えているサインです。
  • 読み直し。 ラベルを読み、スクロールして通り過ぎ、戻って読み直す。そのラベルは不明確です。ツールチップを追加するのが仕事ではありません。ラベルを書き直すのが仕事です。

メモはNotionドキュメントの3列で:タイムスタンプ、観察内容、仮説。コメントも「こう思う」という解釈もなし。見たことと、それが示唆するかもしれないことだけを記録します。統合はあとで行います。

メモ記録の方法は、テストを続けて受けても崩れないものでなければなりません。コツは、調査ごとにカラムがあらかじめ入力された単一ページのテンプレートを使い、スクリーンショットをセッション中ではなく後から貼り付けることです。セッション中にスクリーンショットを撮ろうとすると、次の行動を見逃します。セッションを優先し、成果物は後で作ります。

請求担当マネージャーはエクスポートタスクを47秒で完了しました。旧フローよりは改善、仮説よりは劣る結果です。2回ためらいがありました。日付範囲ピッカーで8秒、ファイル形式セレクターで5秒。「今使っているものよりずっといい」と言っていましたが、これは本物ではあるものの「データ」ではありません。2回のためらいがデータです。

午後2時:デザインクリティーク

他の2人のデザイナーとデザインリードと45分間。アジェンダは3つのフロー、各15分。そのうち1つを自分がプレゼンします。

多くのデザインクリティークは同じ理由で機能しなくなります。委員会デザインに変質するのです。誰かが「青の代わりに紫にしたらどうか」と言い、別の誰かが「モーダルを右からスライドインさせたらどうか」と言い、20分後には80%完成していたフローが40%に戻っています。これはよくある失敗パターンです。「フォーカスグループの螺旋」と頭の中で呼んでいます。

回避策はこれです。フローをプレゼンするとき、最初に3つのことを伝えます。

  1. ユーザーの課題。 「エクスポートフローをリデザインしています」ではなく「中規模顧客の請求担当マネージャーは請求書のエクスポートに平均90秒かけており、サポートチケットで分かりにくいと言っています」。
  2. 制約。 「あと2四半期はAPIの契約を変更できません」。
  3. 求めているフィードバックの具体的な内容。 「今日はビジュアルポリッシュについては聞いていません。このフローがヨーロッパ顧客向けの複数通貨エッジケースに対応できているかどうかを聞いています」。

この3つを伝えると、クリティークが有益になります。最初の30秒で気になったことではなく、求めているテーマでフィードバックが得られます。

実際に欲しいクリティークのフィードバックには2種類あります。「このパターンには同意できない」は意見であり、礼儀として受け止めて却下して構いません。「エンタープライズの管理ユーザーは保存済みエクスポートが200件あるが、あなたのドロップダウンには10件しか表示されないので機能しない」は本物のクリティークです。2つ目が真の価値を持ちます。1つ目は議論の準備運動です。区別して扱ってください。

クリティーク終了時には、ハンドオフ前にフローに加えるべき具体的な修正点が3つあります。いずれも色に関するものではありません。

午後4時:割り込み

PMからSlackが届きます。「金曜日までにダッシュボードを手早くリデザインしてほしいんだけど、明日取り掛かれる?」水曜日の午後4時07分です。

これがあなたがチームの「画面調整係」になるか、デザイナーであり続けるかを決める瞬間です。

間違った返答は「わかった、やってみる」です。その瞬間は助けになっている気がするので心地よく感じます。それでも間違いです。金曜日には、半分しかできていないダッシュボードのモックアップ、スキップされた2回のユーザビリティセッション、そして先週コミットした本来の作業のためのハンドオフドキュメントが未完成のまま残ります。

正しい返答は「はい」ではなく質問です。「確認します。ロードマップの何が変わってこれが金曜日の課題になったのか、そして「リデザイン」が意味するのは既存レイアウトのビジュアルリフレッシュなのか、それとも情報アーキテクチャの再構築なのかを教えてもらえますか?かなり異なる作業です」。これを90秒で送ります。そしてハンドオフの準備に戻ります。

半数のケースで、「リデザイン」は実は「グラフの色を変える」ことだとわかり、チームの別の誰かが対応できます。4分の1のケースでは、依頼は本物だが締め切りは変更可能だとわかります。残りの4分の1は本当の緊急事態で、その週の何かを外してそれに対応します。PMは反射的な「はい」より、その質問に対してより高く評価してくれます。

午後5時:ハンドオフ準備

最後の30分。多くのデザイナーが手を抜き、多くのエンジニアが翌朝「これどういう意味ですか?」とSlackで聞いてくる部分です。

ハンドオフの習慣は20分の作業で翌日90分の確認のやり取りを防ぎます。これほど安く手に入る保険はありません。

Figmaファイルを整えます。意図を込めた名前でフレームを整理:「エクスポートフロー / ステップ2 / 複数通貨バリアント」。レイヤーをグループ化。非表示のフレームを削除。コンポーネントはリンクし、デタッチしない。

1ページのNotionスペックを書きます。セクションは5つまで。課題(1文)。解決策(3文)。状態とエッジケース(リスト)。コンポーネント参照(Storybookリンク、Figmaフレーム番号)。未決事項(エンジニアとまだ決める必要があること)。

NotionドキュメントをLinearチケットに添付します。StorybookリンクをチケットコメントにDropします。エンジニアをタグ付けします。

午後5時32分にノートパソコンを閉じます。

求人票に書いていないこと

この仕事の半分はリサーチと執筆です。おそらく半分以上です。Figmaの作業(求人票が「美しい体験をデザインする」と表現している部分)は実際には週の業務の中で最も小さな割合です。多くの週で25〜35%程度です。残りはユーザーとの対話、エンジニアとの対話、仕様の執筆、クリティークへの参加、そして割り込みへの対応です。

B2B SaaSでやりきれなくなるデザイナーは、Dribbbleを期待して入ってきます。画面を作りたかった。実際に得たのは、画面についての会話と執筆が大半を占める仕事でした。そのギャップが彼らを消耗させます。

うまくやっているデザイナーはFigmaをポートフォリオではなく思考ツールとして扱います。作業中のファイルは散らかっていて、完成時には整っています。Notionには誰も読まないが「なぜこう作ったのか」と誰かに問われるたびに自分を救ってくれる1ページのスペックドキュメントが蓄積されています。デザインより書く量の方が多く、それで構わないと思っています。書くことがデザインを機能させるものだとわかっているからです。

「きれいにして」の依頼、フォーカスグループの螺旋、画面調整係の罠、これらにはすべて名前があります。パターンであって、不運ではないからです。名前を知れば、最初の5分で見抜けます。それが学校では教わらず、求人票にも書かれていないスキルです。

この仕事で目指すのは画面を作ることではありません。画面に関する決断を下し、それを文章で守り、来四半期のロードマップ変更にも生き残る形でリリースすることです。画面は成果物です。決断が仕事の本質です。

明日も今日とほぼ同じ形になります。トリアージ、非同期ブロック、ユーザーセッション、クリティーク、割り込み、ハンドオフ。ファイルは違っても形は同じ。その形がこの仕事です。

関連記事

About the author

Camellia

Camellia

Principal Product Marketing Strategist

Camellia is Principal Product Marketing Strategist at Rework, helping B2B buyers pick the right software with confidence. With 6+ years in product marketing and 150+ SaaS tools evaluated across CRM, project management, and sales engagement, Camellia turns competitive intelligence into clear, honest comparisons. Readers get vendor evaluations they can trust to cut through marketing noise and decide faster.