← エピソード一覧に戻る
Episode 183

入力させるほど、導入は遠のく ― SaaSデザインのフォーム入力UX

12分 5チャプター 日本語
0:00 / 0:00

スクリプト

Chapter 1

オープニング ― 入力欄は増えるほど親切とは限らない

タカシ

今日は SaaS デザインのフォーム入力UXです。実は Typeform の二〇二五年レポートでは、メールアドレスを最初に聞いたフォームの完了率が十八パーセント高かったんです。聞く順番ひとつで、最後まで進む人の数が変わるわけですね。

ミカ

へえ、それは意外です。連絡先って最後に聞いたほうが嫌がられにくいのかなと思っていましたけど、むしろ先に出したほうが最後まで行くんですね。

タカシ

そうなんです。SaaS のフォームは、登録、初期設定、請求、チーム招待、ワークフロー作成など、事業の重要場面に何度も出てきます。だから一個一個の入力摩擦が、導入率や設定完了率や商談化率にそのまま響くんです。

ミカ

なるほど。フォームって地味な UI に見えるけど、実際は売上にもサポート工数にも効くわけですね。今日は、どこで人が詰まるのかを経営目線で整理したいです。

Chapter 2

原則 ― ステップ数より一画面の負荷を減らす

タカシ

まず大原則です。Baymard Institute は、チェックアウト体験ではステップ数より、一画面で何個の入力判断を迫るかのほうが効くと整理しています。二〇二四年時点で平均は十一・三フィールドですが、多くのサイトは八フィールドで済むとも述べています。

ミカ

それって SaaS の設定画面にも当てはまりそうですね。項目が多いと、書くのが大変というより、『なんで今これ全部いるの』と考え始めて止まってしまいそうです。

タカシ

まさにそこです。経営側は情報を多く取りたい。でも利用者は、入力より判断に疲れます。会社名、役職、従業員数、利用用途、課題、電話番号まで初回で全部聞くと、丁寧さではなく重さとして受け取られやすいんですね。

ミカ

ありますね。項目を増やした側は『営業に必要だから』と思っていても、入力する側は面接みたいに感じる。フォームって、欲しい情報量と今聞いていい情報量を分けないといけないんですね。

Chapter 3

設計 ― 短く始めて、後から賢く聞く

タカシ

そこで効くのが、短く始めて後から育てる設計です。HubSpot の progressive profiling は、すでに分かっている情報を別の質問へ置き換えられます。初回は名前とメール、次回は役職、その次は課題、という具合に、同じフォームでも聞く内容を変えられるんです。

ミカ

それは良いですね。同じ人に毎回会社名と部署名を打たせるの、かなり冷めますもんね。知っていることは再利用して、新しいことだけ少しずつ聞くほうが自然です。

タカシ

Typeform の分析でも近い結果が出ています。hidden fields を使ったフォームは完了率が四・八パーセント上がり、入力済み情報を後半で呼び出す recall は十パーセント改善しました。良いフォームは、毎回ゼロから書かせないんです。

ミカ

なるほど。フォーム UX の本質って、見た目を整えることより、利用者の記憶と手間を節約することなんですね。書く量だけじゃなく、同じことを考え直させないのが大事だと分かります。

Chapter 4

実務 ― エラー設計と補完が完走率を左右する

タカシ

次は入力中の迷いです。Atlassian は長いフォームでは multi-step と progress tracker を使い、画面ごとに論理的なまとまりだけ見せるべきだとしています。さらに Carbon は、入力検証はフォーカスアウト時に行い、エラー文は『何が違うか』『どう直すか』まで具体的に書けと勧めています。

ミカ

ありますよね、保存を押したら画面の上に赤い帯だけ出て、『どこが悪いの』となるやつ。あれ、入力ミスに見えて実は設計ミスなんですね。

タカシ

その通りです。加えて住所や決済のようにミスコストが高い欄は、補完を前提にしたほうがいい。Stripe の Payment Element は入力検証とエラー表示を持ち、Address Element は対応国で autocomplete を有効化できます。Google も sign-up ガイドで、入力エラーや打鍵数を減らせると整理しています。

ミカ

ただ、補完が入っても最後は直せたほうが安心ですよね。住所って部屋番号とか請求先表記の揺れもあるし、自動入力が完璧じゃないからこそ、修正の逃げ道が必要そうです。

Chapter 5

まとめ ― 入力を減らすより、完走しやすくする

ミカ

今日の失敗パターンをまとめると、初回で全部聞く、エラーを遅く曖昧に返す、補完に頼り切って直せなくする、そして長いフォームなのに送信ボタンをずっと押せなくしてしまう、この四つですね。

タカシ

ええ。まずは主要フォームを見直して、『初回に絶対必要な三から五項目は何か』を決めることです。残りは progressive profiling や後続フローへ回す。さらに、エラー文を field 直下で返し、長いフォームは multi-step と進捗表示に切り替えるだけでも完走率は変わります。

ミカ

つまり、フォーム改善は『入力欄を減らす施策』というより、『顧客が途中で心を折られない施策』なんですね。営業、CS、プロダクト、デザインが一緒に見る価値がありそうです。

タカシ

その通りです。SaaS のフォームは、情報収集の窓口ではなく、価値提供への通路です。皆さんの製品でも、最重要フォームを一つ選び、『今ここで本当に必要な入力だけか』『間違えた時にすぐ直せるか』を、ぜひ今日見直してみてください。