SaaSの無料登録フローを Google Stitch で設計していたとき、想定外に手間取った。
「名前・メール・パスワード・プラン選択・支払い情報・確認画面」——全部で6ステップの登録フローだ。1画面に全部詰め込むのは明らかに多すぎる。だからマルチステップフォーム、いわゆるウィザード型にしようと決めていた。
ところが、いざ Stitch でプロンプトを書き始めると、「どこで区切るか」「プログレスバーはどう見せるか」「前のステップのデータはどう表示するか」といった問いが次々に出てきた。UIのデザイン問題というより、ユーザーの「入力の旅」をどう設計するかという問題だと気づいたのは、3回作り直してからだった。
この記事は、その試行錯誤の記録だ。
結論から言うと
マルチステップフォームの設計で最も重要なのは、「1つのステップで聞く情報は、1つの意思決定に絞る」ことだ。情報の量ではなく、ユーザーの認知的な「決断の単位」でステップを切ることが、離脱率を下げる設計の核心だった。
マルチステップフォームとは何か
定義と代表的なユースケース
マルチステップフォームとは、複数の入力項目を複数の画面（ステップ）に分割して順番に表示するUIパターンのことです。ウィザード型フォーム、ステッパーUIとも呼ばれる。
代表的なユースケースとして、SaaSやアプリの会員登録フロー、ECサイトの購入チェックアウト、ローン・保険の申し込みフォーム、アンケート・診断ツール、求人応募フォームなどが挙げられる。
マルチステップフォームの主なメリットは、1画面あたりの情報量を減らしてユーザーの認知負荷を下げること、進捗が可視化されることで「あとどれくらいか」がわかること、入力エラーをステップ単位で検証できることの3つだ。
Google Stitch でマルチステップフォームを生成すると何が出てくるか
Stitch で「マルチステップ登録フォーム。3ステップ。プログレスバー付き」と入力すると、上部にステップ数を示すプログレスバーまたはステップインジケーター、中央に入力フィールド、下部に「次へ」「戻る」ボタンが配置された静的な画面が生成される。
実際に使ってみた印象としては、単一ステップの見た目は問題なく生成できる。ただし「全ステップを通した体験」の設計——各ステップで何を聞くか、どの順番で聞くか——は Stitch に任せるのではなく、自分で設計してからプロンプトに落とし込む必要がある。ここが最初に気づかなかった点だ。
詰まった点その1：どこでステップを切るか
「項目数」で切ると失敗する
最初に作ったバージョンは「1ステップ3項目」というルールで機械的に分割した。
- ステップ1：名前・メールアドレス・パスワード
- ステップ2：会社名・役職・チーム人数
- ステップ3：プラン選択・支払い方法・カード番号
- ステップ4：確認画面
ユーザーインタビューをしてみると、「ステップ3で急に支払い情報が来て怖かった」という声が出た。プラン選択とクレジットカード番号の入力は、ユーザーにとって「別の意思決定」だ。プランを選ぶのは「どのサービスを使うか」の判断で、カード番号を入力するのは「実際に課金することへの合意」だ。これを同じステップにまとめると、ユーザーは「まだプランを決めていないのにカード番号を求められた」と感じる。
「意思決定の単位」で切ると離脱率が下がった
ステップの切り方を「ユーザーが行う意思決定の単位」に変えた。
- ステップ1：アカウント作成（名前・メール・パスワード）→「このサービスを試す」という意思決定
- ステップ2：プロフィール（会社名・役職・用途）→「自分の情報を教える」という意思決定
- ステップ3：プラン選択 → 「どのプランにするか」という意思決定
- ステップ4：支払い情報 → 「実際に課金を確認する」という意思決定
- ステップ5：確認・送信 → 「確定する」という意思決定
このバージョンに変えてから、テストユーザーの離脱ポイントが分散した。支払いステップでの離脱は残ったが、「急に怖かった」という感想はなくなった。
Stitch でプロンプトを書く際も、この分割を明示的に書き込むことで、各ステップの入力内容が意図どおりのデザインで出力されるようになった。
詰まった点その2：プログレスバーの設計
ステップ数を見せるか、パーセンテージで見せるか
プログレスバーの表現方法は主に3種類ある。
ステップインジケーター型は、「1 → 2 → 3 → 4」のように各ステップを番号や丸で示す。「今どのステップにいるか」が直感的にわかるため、ステップ数が少ない（2〜5ステップ）場合に向いている。Stitch でも「4ステップのステップインジケーター。現在2ステップ目がアクティブ」というプロンプトで正確に生成された。
パーセンテージバー型は、横一本の進捗バーが伸びていく表現だ。「あと少し」という感覚を強調したい場合や、ステップ数が多い（6ステップ以上）場合に向いている。ただし「何ステップあるか」がわからないため、ユーザーが「どこまで続くのか」と不安になるリスクがある。
組み合わせ型は、ステップ番号と「ステップ2/5」のようなテキストを組み合わせる方法だ。情報量が多い登録フローで、ユーザーに「あとどれくらいか」を正確に伝えたい場合に有効だ。
実際に使ってみた結論として、ステップ数が4〜5の場合はステップインジケーター型が最も離脱率が低かった。「残り○ステップ」という見通しがユーザーの継続意欲を保つ効果があるためだと感じている。
プログレスバーは「戻れる」ことを示す必要があるか
「前のステップに戻れるか」をプログレスバーで示す設計も重要だ。完了済みのステップをクリックして戻れる場合、そのステップのインジケーターをクリッカブルに見えるデザインにする必要がある。「戻れると思ったら戻れなかった」というユーザー体験は、信頼を損なう。
Stitch でこの状態を設計するとき、「完了済みのステップ1はクリック可能な状態（テキストリンク風のスタイル）、現在のステップ2はアクティブ状態（太字・アクセントカラー）、未完了のステップ3・4はグレーアウト」というプロンプトを書くと意図に近いデザインが生成できた。
詰まった点その3：前のステップのデータをどう見せるか
確認画面で「入力した内容の要約」を見せる設計
最終確認ステップで、ユーザーが前のステップで入力した内容を一覧表示する設計は、入力ミスの防止に効果的だ。
Stitch でこの確認画面を生成するとき、「前のステップで入力した情報（名前・メール・プラン・支払い方法）を要約表示する確認画面。各項目の横に『編集』リンクがある」というプロンプトを書いた。生成結果は概ね良好だったが、「編集リンクを押したら該当ステップに戻る」というインタラクションは静止画で表現できないため、コメントで仕様を補足する必要があった。
ステップ間での入力データの「引き継ぎ表示」
たとえば「ステップ1で入力したメールアドレスを、ステップ2の画面上部に薄く表示する」という設計がある。「このアカウントで続けています」という文脈の安心感をユーザーに与える効果があるが、過剰にすると「常に監視されている感じ」になる。
この判断は Stitch では決めてくれない。前のステップの情報をどこまで次のステップで見せるかは、UXの方針として自分で決める必要がある。Stitch はその決定をビジュアル化するツールだ。
Stitch でのマルチステップフォーム生成の実践的なワークフロー
まず全ステップを「ストーリーボード」として並べる
Stitch の無限キャンバス機能（2026年3月追加）を使って、全ステップを横に並べて生成するアプローチが最も効率的だった。
プロンプトを「5ステップの会員登録ウィザードフォームを横並びに生成。ステップ1：アカウント作成、ステップ2：プロフィール、ステップ3：プラン選択、ステップ4：支払い情報、ステップ5：確認画面」と書くと、全ステップが1つのキャンバスに並んだ状態で生成され、フロー全体の一貫性を確認しやすかった。
Play ボタンでフロー全体をクリッカブルにする
全ステップが揃ったら、Stitch の Play ボタンで画面間を繋ぎ、「次へ」ボタンを押すと次のステップへ進むクリッカブルプロトタイプを作る。アニメーションなしの画面切り替えだが、フローの論理的な順序を確認するには十分だ。
FAQ
Q1. マルチステップフォームは何ステップが最適ですか？
一般的には3〜5ステップが使いやすいとされています。ステップが少なすぎると1画面の情報量が増えすぎ、多すぎると「いつ終わるのか」という疲労感をユーザーに与えます。目安として、1ステップあたりの入力項目は3〜5個以内、フォーム全体で15項目以内に収めると離脱率を抑えやすいという知見があります（各サービスの状況による）。
Q2. Google Stitch でマルチステップフォームの「戻る」ボタンも設計できますか？
はい、静的なデザインとして生成できます。「左下に『戻る』テキストリンク、右下に『次へ』プライマリボタン」というプロンプトが有効です。「戻る」と「次へ」のボタンの視覚的重みを変える（戻るを控えめに、次へを強調する）ことで、ユーザーを前進方向に誘導する設計ができます。
Q3. 入力途中でページを離れてしまったユーザーへの対処は設計段階で考えますか？
設計段階で検討しておくことをお勧めします。「入力中断後に再訪したとき、途中から再開できるか」「ブラウザバックで戻ったときデータが消えないか」という問いへの答えをUIに組み込むと、離脱率が下がります。Stitch では「入力途中のデータを保存中のインジケーター」「再開案内のバナー」などのデザインを生成できます。
Q4. 各ステップのバリデーション（入力チェック）はどのタイミングで行うべきですか？
「次へ」ボタンを押したときにそのステップの入力をまとめて検証するのが基本です。ただしメールアドレスの重複チェックなど、サーバー通信が必要なバリデーションはリアルタイムで行う設計も有効です（入力フィールドからフォーカスが外れたタイミングで確認）。Stitch でエラー状態のデザインも「メールアドレス欄の下にエラーメッセージが表示された状態」として生成できます。
Q5. Google Stitch で生成したフォームデザインをそのまま実装に使えますか？
Stitch はHTMLとCSSを書き出せますが、フォームの実際の送信機能・バリデーションロジック・ステップ間のデータ保持はJavaScriptやバックエンドで別途実装が必要です。Stitch の出力はフロントエンドの見た目の土台として使い、機能実装は開発者と分担する形が現実的です。
Q6. マルチステップフォームに適したシチュエーションと、シングルページフォームが良いシチュエーションの違いは何ですか？
入力項目が8個以上・複数カテゴリにまたがる・意思決定に段階がある場合はマルチステップが適しています。一方、お問い合わせフォームのように入力項目が5個以下でカテゴリが1つの場合は、ページを分ける必要はなく1ページフォームの方がユーザーにとってシンプルです。「余計なステップを作らない」という意識も、良いフォームUXのために重要です。
注意点・失敗しやすいポイント
1. 「最初のステップ」が重すぎると全体の離脱率が上がる
最初のステップで多くの情報を求めると、そこで離脱するユーザーが急増する。最初のステップは最もシンプルに保ち、「始める敷居を下げる」設計にすることが重要だ。メールアドレスだけで始められる、名前だけで次へ進める、といった最低限のファーストステップが効果的だ。
2. 「前に戻れない」フォームはユーザーに不信感を与える
入力途中で「あ、前の項目を直したい」と思ったとき、戻れないフォームはユーザーに強いストレスを与える。原則としてすべてのステップに「戻る」機能を実装するべきだ。Stitch での設計段階でも「戻るボタンのある状態」を必ず1パターン作って確認することをお勧めする。
3. Stitch で生成した各ステップの視覚的一貫性を確認する
各ステップを別々のプロンプトで生成すると、フォントサイズ・ボタンサイズ・色などに微妙なズレが生じることがある。全ステップを一度に生成するか、生成後に横並びで比較して統一性を確認する工程を入れることをお勧めする。
まとめ
マルチステップフォームを Google Stitch で設計してわかったのは、「ステップを分割する判断」がフォームの成否を決めるということだ。UIの見た目ではなく、ユーザーの「入力の旅」の設計がすべての起点になる。
Stitch は各ステップのデザインを高速に生成してくれる。でもどこで切るか、どんな順番で聞くか、は自分で決める必要がある。その判断の質が、最終的なフォームの完成度を左右する。
「情報量で切る」から「意思決定の単位で切る」という考え方の転換が、私の設計の一番の収穫だった。これからマルチステップフォームを設計する人の、何かのヒントになれば嬉しい。
