X 風オンボーディングチェックリストの実装 — 初回体験で離脱を防ぐ UX パターン

SaaS に登録した直後、「で、何をすればいいの？」と戸惑ったことはないでしょうか。ダッシュボードが真っ白で、メニューは並んでいるけれど、どこから手をつければいいかわからない。その瞬間にブラウザのタブを閉じてしまった経験は、誰にでもあるはずです。

フリーランス向けの案件管理ツール Wakulier の開発でも、まさにこの問題に直面しました。登録してくれたユーザーが、最初の画面で何をすべきかわからず離脱してしまう。機能がどれだけ充実していても、初回体験で迷子になったら意味がありません。

この記事では、X（Twitter）のアカウント設定UIを参考に Claude Code で実装した「オンボーディングチェックリスト」の設計判断と、そこから得た学びを共有します。

なぜオンボーディングが重要なのか

SaaS の世界では「初回体験（First Time Experience）」が継続率を大きく左右するといわれています。ユーザーが最初の数分で価値を感じられなければ、二度と戻ってきません。

Wakulier は依頼者（クライアント）とワーカー（フリーランス）の双方が使うサービスです。特に依頼者側は、「案件を登録して、ワーカーに依頼する」という一連の流れを体験しないと、ツールの価値がわかりません。しかし登録直後のダッシュボードは空っぽで、何から始めればいいかが見えない。

2026年1月5日の開発日記にはこう書いています：

オンボーディングチェックリスト: 新規ユーザーが「次に何をすべきか」を迷わないように。Xのアカウント設定を参考

「迷わないように」。この一言に、課題のすべてが集約されています。ユーザーは「このツールは使えそうだ」と思って登録したのに、最初の画面で迷子になると「やっぱり難しいかも」に変わる。その落差が離脱を生みます。

X のオンボーディングから学んだこと

オンボーディングの UI パターンにはいくつかの選択肢があります。ウィザード形式（ステップバイステップのモーダル）、ツールチップ形式（画面の要素を一つずつ説明）、そしてチェックリスト形式。

X（Twitter）のアカウント設定では、プログレスバー付きのチェックリストが使われています。このパターンが優れているのは、以下の3点です。

1. 非強制的であること -- ウィザード形式と違い、ユーザーは自分のペースで進められる。モーダルで強制的にステップを踏ませると、「後でやりたいのに」というストレスが生まれる
2. 全体像が見えること -- 「あと何ステップ残っているか」が一目でわかる。ゴールが見えると人は動きやすい
3. 達成感があること -- チェックが一つ埋まるたびに進捗バーが伸びる。ゲーミフィケーションの効果で「全部埋めたい」という心理が働く

Wakulier でもこのパターンを採用しようと決めました。ウィザード形式はファーストインプレッションのコントロールには強いですが、「まず触ってみたい」タイプのユーザーにはストレスになります。ツールチップ形式は文脈に沿った説明ができる反面、画面遷移すると消えてしまい、全体像がつかめません。チェックリスト形式は「今どこにいて、あと何が残っているか」を常に提示できる点で、Wakulier のようにセットアップ項目が複数あるサービスに適していました。

ただし、X のデザインをそのままコピーするのではなく、Wakulier の利用フローに合わせたステップ設計が必要でした。

ステップ設計の判断 -- いくつが最適か

オンボーディングチェックリストで最も悩んだのは、ステップ数です。多すぎるとユーザーは「面倒だ」と感じて離脱するし、少なすぎると初期設定が不十分なまま使い始めてしまう。

この判断について、Claude Code と相談しました。

Zeronova

オンボーディングのステップ数を決めたい。Wakulier は依頼者向けだから、「プロフィール設定」「最初の案件登録」「料金表の設定」「ワーカーへの初回依頼」くらいを考えている。4ステップだけど、多すぎないかな。

Claude Code

4ステップは許容範囲ですが、「ワーカーへの初回依頼」はハードルが高いかもしれません。相手がいないと完了できないステップは、ユーザー単独ではクリアできず、チェックリストが完了しないまま残り続けるリスクがあります。3ステップに絞って、依頼はオンボーディング後の自然な流れに任せるのはどうでしょうか。

Zeronova

たしかに、相手が必要なステップは自分で完了できない。3ステップでいこう。プロフィール、案件登録、料金表。この3つが揃えば「使い始められる状態」にはなる。

この判断は重要でした。オンボーディングチェックリストは「全部埋められる」ことが前提です。他人の行動に依存するステップを入れてしまうと、いつまでもチェックが埋まらず、達成感が得られません。ユーザー自身の操作だけで完了できるステップに限定する。これがポイントでした。

最終的に設定した3ステップはこうなりました。

横スクロールカードと進捗バーの設計

ステップが決まったら、UI の設計です。開発日記には以下の記載があります。

• X風のセットアップガイド
• 横スクロール可能なカード
• 進捗バー

横スクロール可能なカード形式を選んだ理由は、モバイルファーストの考え方です。Wakulier のユーザーであるフリーランスは、移動中にスマホで確認することが多い。縦に長いチェックリストだと画面を圧迫しますが、横スクロールのカードなら最小限のスペースで全ステップを表示できます。

Claude Code に実装を依頼した際、各カードには以下の情報を含めました。

• ステップ番号とタイトル
• 簡潔な説明文（1行）
• 完了/未完了のステータスアイコン
• 該当ページへの導線ボタン

進捗バーはカードの上部に配置しました。「1/3 完了」のように分数で表示し、バーの色は進捗に応じて変化します。0% のときはグレー、途中は黄色、全完了でグリーン。X のUIと同様に、視覚的なフィードバックを重視しました。パーセンテージではなく分数にしたのは、ステップ数が3つと少ないため。「33%」より「1/3」の方が、残りのタスク量が直感的にわかります。

// 進捗バーの色分けロジック
const getProgressColor = (completed: number, total: number) => {
  const ratio = completed / total;
  if (ratio === 1) return 'bg-green-500';
  if (ratio > 0) return 'bg-yellow-500';
  return 'bg-gray-300';
};

「完了したら消える」設計

開発日記の「学んだこと」セクションに、こう記録していました。

オンボーディングは「完了したら消える」設計にする

これは一見当たり前に思えますが、重要な判断です。全ステップを完了したユーザーにとって、チェックリストはもはやノイズでしかありません。ダッシュボードの一等地を占拠し続けるのは邪魔です。

Claude Code で実装したのは、全ステップ完了後にチェックリスト全体をフェードアウトさせ、代わりに「セットアップ完了！」という短い完了メッセージを表示する仕組みです。完了メッセージも数秒後に消え、通常のダッシュボードに切り替わります。

ただし、完了状態は DB に記録します。一度消えたチェックリストが再び表示されることはありません。ユーザーが「もう見た」ものを二度見せないのは、UX の基本です。

ここで気をつけたのは、「×ボタンで閉じる」機能をあえて付けなかったことです。チェックリストが邪魔に感じるなら、それは全ステップを完了すれば解決する問題です。スキップ手段を用意すると、本来必要な初期設定を飛ばしてしまうリスクがあります。完了することだけが「消す方法」という設計にすることで、最低限のセットアップを確実に促す狙いがありました。

中間状態の可視化

開発日記には、もう一つ重要な学びが記録されています。

提案中・調整中などの「中間状態」は全員に見えるべき

これはオンボーディングチェックリストとは直接関係ない文脈（納期変更提案の話）ですが、通底する考え方は同じです。ユーザーが「今どの状態にあるか」を常に把握できるようにする。

チェックリストでいえば、各ステップの状態は3つあります。

• 未着手: グレーのアイコン、「設定する」ボタン
• 途中: 黄色のアイコン、「続きを入力する」ボタン
• 完了: グリーンのチェックマーク、完了日時の表示

特に「途中」の状態を明示することが大切です。プロフィールを途中まで入力して離脱したユーザーが戻ってきたとき、「あ、途中だった」とすぐ気づけます。「続きを入力する」というボタンラベルも、「最初からやり直し」ではないことを伝える工夫です。

「設定する」と「続きを入力する」。たったこれだけのラベルの違いですが、ユーザーの心理的ハードルは大きく変わります。「もう一度最初から入力し直すのか」と思わせたら、そこで離脱が起きる。入力済みのデータがちゃんと保存されていて、途中から再開できることをUIで示すだけで、復帰のモチベーションが変わります。

プロフィール完成度インジケーターとの関係

オンボーディングチェックリストと似た UX パターンに「プロフィール完成度インジケーター」があります。以前の記事「プロフィール完成度インジケーターでユーザーの入力率を上げる」で BandBridge での実装を紹介しました。

この2つは補完関係にあります。

オンボーディングチェックリストは「使い始められる状態」にするための短期的なガイド。プロフィール完成度インジケーターは「より魅力的なプロフィール」を目指す長期的なモチベーション装置。両方を組み合わせることで、初回体験から継続利用までをカバーできます。

Wakulier でも、チェックリストの「プロフィール設定」ステップは「名前と連絡先を入力する」程度の最低限です。その先の「事業内容を詳しく書く」「ポートフォリオを追加する」といった深い入力は、完成度インジケーターの役割になります。

この2つの境界線を引くのが、PM としては意外と難しかった。「料金表の設定」はオンボーディングに入れるべきか、完成度インジケーターに回すべきか。結論としては、料金表がないと依頼者が案件に値段をつけられないため、オンボーディングの方に入れました。「サービスを使い始めるために最低限必要なもの」がオンボーディング、「使い続けるうちに充実させていくもの」が完成度インジケーター。この線引きを意識すると、ステップの取捨選択がしやすくなります。

学んだこと

オンボーディングチェックリストの設計を通じて、いくつかの学びがありました。

ステップ数は「自力で完了できるもの」に絞る

他者の行動に依存するステップを入れると、チェックリストが永遠に完了しません。ユーザーが自分の操作だけで埋められるステップだけを含める。Wakulier では「ワーカーへの依頼」を外して3ステップにしたのが正解でした。

ウィザードではなくチェックリストを選ぶ理由

ウィザード（モーダル形式のステップバイステップ）は強制力がある反面、ユーザーの自由を奪います。「今はプロフィールより案件登録を先にやりたい」というユーザーに対応できません。チェックリストは順不同で進められるので、ユーザーのモチベーションに沿った体験を提供できます。

完了後は消す、ただし記録は残す

チェックリストは役目を終えたら消えるべきです。ただし、再表示しないために完了状態は DB に保存しておく。「一度消えたものがまた出てくる」のは、ユーザーにとってストレスです。

中間状態を見落とさない

「未完了」と「完了」の2値ではなく、「途中」という中間状態を明示する。これにより、離脱したユーザーが戻ってきたときのハードルが下がります。「最初からやり直し」ではなく「続きから」であることを伝えるだけで、復帰率は変わるはずです。

まとめ

Wakulier のオンボーディングチェックリストは、X のUIを参考にしつつ、フリーランス向けサービスの特性に合わせて設計しました。

1. ステップは3つに絞る -- 自力で完了できるものだけ。多すぎると離脱、少なすぎると不十分
2. 横スクロールカードで省スペース -- モバイルファーストの設計。進捗バーで全体像を可視化
3. 完了したら消える -- 役目を終えたUIは撤退させる。ただし記録は残す
4. 中間状態を明示する -- 「途中」を見せることで、復帰のハードルを下げる

初回体験の設計は、機能開発とは異なる難しさがあります。「何を見せるか」だけでなく「何を見せないか」「いつ消すか」まで考える必要がある。PM として、この視点を持てたことが一番の収穫でした。

関連記事

• プロフィール完成度インジケーターでユーザーの入力率を上げる
• Supabase Storage でアバター画像を管理する
• モバイルファーストなモーダル設計 — フルスクリーンシートの実装