
フォーム項目は、問い合わせ後の対応に必要な情報だけへ絞る必要があります。
取得目的が曖昧な項目を増やすほど入力負荷が高まり、フォーム到達後の離脱につながりやすくなります。
なお、TimeValue株式会社では、広告運用・クリエイティブ制作・LP改善・データ分析・AI導入までを一括で引き受けるWebマーケティング支援「KAIZEN」を提供しています。
現在、オンラインの無料マーケティング診断を毎月10社限定で実施中です。LPと計測のどちらに原因があるのか、実際の数字で切り分けます。
今月の無料診断は残り4社です
広告からLPまで、まとめて見ます。オンラインで30分から対応しています。
目次
目次
- フォーム項目は必要な情報だけに絞れているか
- 各項目の取得目的を説明できるか確認する
- フォーム入力時点と商談時点を分ける
- 必須項目と任意項目の設定は適切か
- 必須にする基準を決める
- 任意項目にも回答するメリットを持たせる
- 必須表示が視覚的にわかるか確認する
- 入力形式はユーザーが迷わない設計になっているか
- 選択肢が決まっている項目を自由記述にしていないか
- ラジオボタンとチェックボックスを使い分ける
- プルダウンを使いすぎていないか確認する
- 項目名と入力例だけで回答内容が理解できるか
- 抽象的な項目名を使っていないか確認する
- 入力例が回答のヒントになっているか確認する
- 業界用語や社内用語が含まれていないか確認する
- 入力エラーが起きてもすぐに修正できるか
- エラー内容が具体的に表示されるか確認する
- エラー箇所まで戻りやすいか確認する
- 入力した内容がエラー後に消えないか確認する
- 厳しすぎる入力制限がないか確認する
- スマートフォンでもフォームを入力しやすいか
- 入力欄の幅と高さを確認する
- 入力内容に合ったキーボードが表示されるか確認する
- 自動入力が正常に利用できるか確認する
- 固定要素がフォームを隠していないか確認する
- フォーム送信前の不安を減らせているか
- 送信後の流れが想像できるか確認する
- 電話番号を入力する理由が伝わるか確認する
- 個人情報の取り扱いを確認できるか
- フォームの計測と送信後の動作まで確認できているか
- テスト送信を実際に行う
- 自動返信と社内通知を確認する
- CRMやスプレッドシートへの保存内容を確認する
- 広告とアクセス解析のコンバージョン計測を確認する
- フォーム改善後は数値の変化を確認する
- よくある質問
- まとめ
フォーム項目は、問い合わせ後の対応に必要な情報だけへ絞る必要があります。
取得目的が曖昧な項目を増やすほど入力負荷が高まり、フォーム到達後の離脱につながりやすくなります。
フォーム項目は必要な情報だけに絞れているか
フォーム項目は、問い合わせ後の対応に必要な情報だけへ絞る必要があります。
取得目的が曖昧な項目を増やすほど入力負荷が高まり、フォーム到達後の離脱につながりやすくなります。
フォーム項目をチェックするときは、最初に「この情報は本当にフォーム入力時点で必要なのか」を確認します。
営業担当者やマーケティング担当者が知りたい情報をすべて入力させようとすると、フォームは簡単に長くなります。
問い合わせフォームの役割は、社内で使える情報を最大限集めることではありません。
ユーザーが問い合わせ、資料請求、申し込みなどの行動を完了できる状態を作ることです。
各項目の取得目的を説明できるか確認する
会社名、氏名、メールアドレス、電話番号、部署名、役職、従業員数、予算、導入時期、相談内容など、BtoBのフォームでは多くの候補があります。
しかし、それぞれについて取得理由を説明できなければ、フォーム項目から外せないか検討する余地があります。
たとえば資料請求後にメールで資料を送るのであれば、メールアドレスは必要です。
営業担当者から電話で日程調整する運用なら、電話番号にも取得理由があります。
一方で、資料をダウンロードするだけのフォームで、問い合わせ後すぐには営業接触をしないにもかかわらず、住所や電話番号まで必須にしている場合は再検討できます。
フォーム改善では「どの項目を足すか」より、「どの項目ならなくせるか」から確認すると整理しやすくなります。
フォーム入力時点と商談時点を分ける
フォームで取得したい情報の中には、問い合わせ後のヒアリングで確認できるものもあります。
たとえば現在の課題、利用中のサービス、詳しい予算、決裁フロー、導入希望時期などです。
これらは営業にとって有用ですが、すべてを初回フォームで聞く必要があるとは限りません。
ユーザーから見ると、まだサービスについて詳しく知っていない段階で細かな質問に答えることになります。
入力する情報量に対して、受け取れる価値が小さいと感じれば離脱する可能性があります。
フォームでは最初の接点に必要な情報を取得し、その後のメール、電話、商談で情報を追加していく考え方が有効です。
フォーム項目を残すか判断するときの確認例
| 項目 | 確認する内容 | 見直しの考え方 |
|---|---|---|
| 氏名 | 問い合わせ後の連絡に必要か | 通常は連絡時に必要です |
| メールアドレス | 資料送付や返信に必要か | メール対応する場合は必要です |
| 電話番号 | 問い合わせ直後に電話するか | 電話対応しない場合は任意化も検討します |
| 会社名 | 法人判定や営業対応に使うか | BtoBでは必要性が高い項目です |
| 部署名 | 問い合わせ直後の対応が変わるか | 変わらなければ後から取得できます |
| 役職 | 営業優先度の判断に使うか | 取得目的がなければ削減候補です |
| 住所 | 郵送や地域判定が必要か | 不要ならフォーム段階では外せます |
| 予算 | 問い合わせ前に回答できる内容か | 回答が難しい場合は選択式や後日確認を検討します |
フォーム項目をチェックするときは、項目数だけを見て短くすればよいわけではありません。
問い合わせ後の業務まで含め、必要性と入力負荷のバランスを見る必要があります。
必須項目と任意項目の設定は適切か
フォームでは、問い合わせを成立させるために不可欠な情報だけを必須にします。
あると便利という理由だけで必須設定を増やすと、回答できないユーザーをフォーム上で失う可能性があります。
フォーム項目をチェックするときは、項目の内容だけでなく、必須と任意の設定も確認します。
実務では、項目そのものを削除しなくても、必須から任意へ変更するだけで入力負荷を下げられる場合があります。
必須にする基準を決める
必須項目は「回答がなければ問い合わせ後の対応そのものができない情報」に限定するのが基本です。
たとえば返信をメールで行う場合、メールアドレスがなければ連絡できません。
そのため必須にする合理性があります。
一方、従業員数や予算、役職などは、わからなくても問い合わせ自体は成立します。
営業側では把握したい情報でも、ユーザー側では回答しにくい場合があります。
特に予算や導入時期は、サービス内容や価格を確認してから決めたいユーザーもいます。
それにもかかわらず回答を必須にすると、まだ検討初期のユーザーに不必要な判断を求めることになります。
任意項目にも回答するメリットを持たせる
任意にしたからといって、何でも残してよいわけではありません。
任意項目が大量に並んでいれば、ユーザーから見たフォームの長さは変わらないためです。
残す場合は、回答によってユーザー側にもメリットがある項目を優先します。
たとえば相談内容を自由記述できれば、問い合わせ後の回答が具体的になりやすくなります。
希望する連絡方法を選択できれば、ユーザーが電話かメールかを指定できます。
フォーム項目のチェックでは、企業側が取得したい情報だけでなく、入力するユーザーにとって回答する意味があるかも確認します。
必須表示が視覚的にわかるか確認する
必須と任意の区別がわかりにくいフォームも入力ストレスを生みます。
入力後に送信ボタンを押した段階で初めて未入力項目を指摘されると、ユーザーは入力箇所まで戻らなければなりません。
「必須」「任意」の表示を各項目の近くに配置し、入力前から判断できる状態にします。
アスタリスクだけで必須を示す場合は、その意味がユーザーに伝わるかも確認が必要です。
フォームを日常的に使う担当者にとって当然の表現でも、すべてのユーザーが同じように理解するとは限りません。
入力形式はユーザーが迷わない設計になっているか
フォーム項目は、入力内容に適した形式を選び、ユーザーが入力方法を考えなくても回答できる状態にします。
自由記述を減らし、選択式や入力例を適切に使うことで入力途中の迷いを減らせます。
フォーム項目のチェックでは、「何を聞くか」と同じ程度に「どう入力してもらうか」が大切です。
同じ質問でも、テキスト入力、ラジオボタン、チェックボックス、プルダウンなど、入力形式によって使いやすさは変わります。
選択肢が決まっている項目を自由記述にしていないか
回答パターンがある程度決まっている質問は、選択式にしたほうが入力しやすくなります。
たとえば従業員数を聞く場合に、自由記述で人数を書いてもらう必要がなければ、「1〜10名」「11〜50名」「51〜100名」のように範囲から選択できる形にできます。
ここで示した人数区分は説明のための仮の値です。
実際には営業管理や顧客分析で利用する区分に合わせて設計します。
選択式にするとユーザーが回答方法に迷いにくくなるだけでなく、取得したデータの表記も統一できます。
「100人」「100名」「約100名」のように異なる形式で保存されることを防ぎ、集計やCRMへの連携もしやすくなります。
ラジオボタンとチェックボックスを使い分ける
選択式フォームでは、一つだけ回答してほしいのか、複数回答してよいのかが明確でなければなりません。
一つだけ選択する質問にはラジオボタンが向いています。
複数回答できる質問にはチェックボックスを使います。
たとえば「希望する相談内容」を複数選択できるのにラジオボタンになっていれば、ユーザーは一つしか選べません。
逆に、一つだけ選んでほしい質問をチェックボックスにすると、複数選択されたときに営業データとして扱いにくくなります。
プルダウンを使いすぎていないか確認する
プルダウンは画面を短くできますが、選択肢が見えないという弱点があります。
二つや三つ程度しか選択肢がない質問までプルダウンにすると、ユーザーは一度クリックして中身を確認する必要があります。
選択肢が少ない場合は、最初から内容を一覧で見せたほうが選びやすいことがあります。
一方、都道府県のように選択肢が多い場合は、プルダウンや検索可能な選択UIを使うことで画面を整理できます。
質問内容に合わせた入力形式の確認
| 質問の特徴 | 使いやすい形式 | 確認すること |
|---|---|---|
| 短い文字情報 | テキスト入力 | 入力例が必要か確認します |
| 回答が一つ | ラジオボタン | 選択肢を一覧表示できるか確認します |
| 回答が複数 | チェックボックス | 複数選択可能と伝わるか確認します |
| 選択肢が多い | プルダウン | 目的の選択肢を探しやすいか確認します |
| 詳しい相談内容 | テキストエリア | 記入量の目安を示せるか確認します |
| 日付 | 日付入力 | 書式をユーザーに入力させすぎていないか確認します |
| 電話番号 | 電話番号入力 | ハイフンの有無でエラーにならないか確認します |
入力形式のチェックは、見た目だけの問題ではありません。
フォームから取得した情報をどのように営業管理や分析へ利用するかにも影響します。
項目名と入力例だけで回答内容が理解できるか
フォーム項目は、ユーザーが項目名を見ただけで何を入力すべきか判断できる表現にします。
意味が広い言葉や社内用語を避け、必要に応じて入力例や補足文を添えることが必要です。
フォームを作成した担当者は各項目の意味を理解しているため、説明不足に気づきにくいことがあります。
しかし、初めてフォームを見るユーザーは、表示されている文言だけを頼りに回答します。
抽象的な項目名を使っていないか確認する
「種別」「区分」「カテゴリー」「ご希望内容」など、意味の広い項目名だけでは何を答えればよいのかわからない場合があります。
たとえば「ご希望内容」という項目に「資料請求」「料金について相談」「導入相談」といった選択肢があれば理解できます。
しかし自由記述欄だけが置かれていれば、どこまで詳しく書くべきか迷います。
項目名は社内管理上の名称ではなく、ユーザーが理解できる言葉にします。
CRM上では「リード種別」と管理していたとしても、その名称をフォームにそのまま表示する必要はありません。
入力例が回答のヒントになっているか確認する
自由記述欄では、入力例を表示するとユーザーが回答しやすくなります。
たとえば相談内容であれば、「広告運用の費用について相談したい」など、入力してほしい粒度が伝わる例を示せます。
入力例をフォーム内のプレースホルダーだけに表示する場合は注意が必要です。
入力を開始すると文字が消えるため、入力中に確認できなくなるからです。
回答ルールとして必要な内容は、入力欄の上や下にテキストとして残したほうがわかりやすくなります。
業界用語や社内用語が含まれていないか確認する
サービス提供側では日常的に使っている言葉でも、問い合わせユーザーには通じないことがあります。
マーケティングサービスであれば、CPA、CVR、MA、CRMなどの略語を知っているユーザーもいますが、すべての問い合わせ者が理解しているとは限りません。
専門用語を入力項目に使う場合は、必要に応じて補足説明を加えます。
フォームは知識を確認するテストではありません。
ユーザーが自分の状況を迷わず伝えられることを優先します。
入力エラーが起きてもすぐに修正できるか
フォームのエラー表示は、エラーが発生した項目の近くで原因と直し方がわかる状態にします。
送信後に一括でエラーを出すだけではなく、ユーザーが修正箇所をすぐ特定できる設計が必要です。
フォームの使いやすさを確認するときは、正常に入力できる場合だけをテストしてはいけません。
誤ったメールアドレスを入力した場合、必須項目を空欄にした場合、文字数を超えた場合など、エラーが起きた状態も確認します。
エラー内容が具体的に表示されるか確認する
「入力内容に誤りがあります」という表示だけでは、何を直せばよいのかわかりません。
メールアドレスの形式が問題なら、「メールアドレスの形式を確認してください」など、修正対象がわかる表示が必要です。
電話番号で利用できない文字が入力されている場合も、入力規則を示します。
ユーザーに原因を推測させるエラー表示は避けます。
エラー箇所まで戻りやすいか確認する
項目数が多いフォームでは、ページ上部にエラーがあるにもかかわらず画面下部だけにメッセージが表示されると、ユーザーは該当箇所を探すことになります。
エラーが発生した入力欄の近くにメッセージを出すことで、修正箇所を見つけやすくできます。
フォーム上部にエラー一覧を表示する場合でも、それぞれのエラーから対象項目を把握できる状態にします。
スマートフォンでは表示領域が狭いため、エラー表示によって画面が崩れないかも確認します。
入力した内容がエラー後に消えないか確認する
フォーム送信時に一つでもエラーがあると、それまで入力していた内容がすべて消えてしまうフォームがあります。
氏名や会社名だけであれば再入力できるかもしれませんが、長い相談内容を書いていた場合、もう一度入力する負担は大きくなります。
エラー発生後にも正常な入力内容が保持されるかをチェックします。
ブラウザを戻った場合や確認画面から修正画面へ戻った場合も、入力情報が残るか確認すると安全です。
厳しすぎる入力制限がないか確認する
入力チェックを厳密にしすぎることで、本来送信できるユーザーまでエラーになることがあります。
電話番号のハイフン、会社名の記号、氏名のスペースなど、入力の揺れをどこまで許容するか確認します。
システム上で統一形式が必要なら、ユーザーに直させるのではなく、保存時にデータを整形できないか検討する方法もあります。
フォーム側の都合をユーザー側の作業へ転嫁していないかを見ることが必要です。
スマートフォンでもフォームを入力しやすいか
フォーム項目は、スマートフォンで文字入力、選択、修正、送信まで無理なく完了できるか確認します。
PC表示だけで判断せず、実際の端末で入力操作を行い、画面幅やキーボード表示まで確認します。
フォームをPCで作成していると、スマートフォンでの入力性を見落としやすくなります。
広告やSNS、検索結果からスマートフォンでページを閲覧するユーザーがいる場合、フォームもスマートフォンで完結できなければなりません。
入力欄の幅と高さを確認する
入力欄が小さすぎると、タップしにくくなります。
チェックボックスやラジオボタンが小さい場合も、意図しない項目を選択する可能性があります。
入力欄だけでなく、項目名、補足文、エラー文も含めて画面内に収まっているか確認します。
横スクロールが発生したり、項目名が不自然な位置で折り返されたりする場合は修正が必要です。
入力内容に合ったキーボードが表示されるか確認する
メールアドレス、電話番号、数字など、項目ごとに入力内容が異なります。
スマートフォンでは入力タイプを適切に指定することで、項目に応じたキーボードを表示できます。
たとえば電話番号入力で数字入力に適したキーボードが表示されれば、文字入力キーボードから切り替える手間を減らせます。
小さな違いに見えますが、複数項目を入力するフォームでは操作回数の積み重ねが負担になります。
自動入力が正常に利用できるか確認する
氏名、メールアドレス、電話番号、住所などは、ブラウザや端末の自動入力を利用するユーザーがいます。
フォーム側の設定が不適切だと、自動入力した情報が別の項目に入る場合があります。
入力作業を完全に手動で行う前提にせず、一般的な自動入力機能でも問題なく操作できるかを確認します。
固定要素がフォームを隠していないか確認する
スマートフォンページでは、画面下部に固定CTAやチャットボタンを設置するケースがあります。
フォーム入力時にキーボードが表示されると、もともと狭い画面がさらに狭くなります。
そこへ固定ボタンが重なると、入力欄や送信ボタンが見えなくなる場合があります。
フォーム周辺では、固定要素との重なりまで実機で確認します。
フォーム送信前の不安を減らせているか
フォームでは、入力内容だけでなく、送信後に何が起きるのかを事前に伝える必要があります。
連絡方法や個人情報の扱いが不明なままだと、入力完了直前でも送信をためらう原因になります。
フォーム項目のチェックでは、入力欄だけを確認しがちですが、フォーム周辺の情報も送信率に影響します。
ユーザーは情報を入力するとき、「この後どうなるのか」「営業電話が来るのか」「情報を何に使われるのか」といった点を気にすることがあります。
送信後の流れが想像できるか確認する
問い合わせフォームなら、送信後に担当者から連絡するのか、自動返信メールが届くのかを示します。
資料請求フォームなら、その場で資料をダウンロードできるのか、メールでURLが送られるのかを説明します。
商談予約フォームなら、フォーム送信だけで予約が確定するのか、担当者との調整が必要なのかを明確にします。
ユーザーはフォームを送った後の行動まで含めて判断しています。
フォーム項目を減らしても、送信後の流れが不透明であれば心理的な負担は残ります。
電話番号を入力する理由が伝わるか確認する
電話番号は、ユーザーが入力をためらいやすい項目の一つです。
電話番号を必須にするのであれば、どのような目的で利用するのかをフォーム周辺で伝えられないか検討します。
たとえば問い合わせ内容の確認に利用するのか、日程調整のために利用するのかによって、ユーザーの受け取り方は変わります。
単に「電話番号」と表示するだけでは、送信後すぐに営業電話が来るのではないかと考えるユーザーもいます。
個人情報の取り扱いを確認できるか
氏名、メールアドレス、電話番号などを取得する場合は、プライバシーポリシーへの導線や同意方法を確認します。
法務上必要な要件は、取得する情報や事業内容、運用方法によって異なるため、自社の管理ルールに沿って確認する必要があります。
フォーム改善を理由に同意文言を不用意に削除するのではなく、必要な情報を読みやすく配置できるかを検討します。
フォーム送信前に確認したい情報
| 確認対象 | ユーザーが感じやすい疑問 | フォーム周辺で確認する内容 |
|---|---|---|
| 送信後の流れ | この後どうなるのか | 自動返信や担当者連絡の有無を伝えます |
| 連絡方法 | 電話が来るのか | 電話やメールなど予定する方法を示します |
| 返信時期 | いつ返事が来るのか | 案内可能な場合は目安を示します |
| 個人情報 | 何に利用されるのか | 取り扱い方針への導線を確認します |
| 送信内容 | 本当に送信できたか | 完了画面や完了メールを確認します |
フォームでは入力操作だけでなく、情報を渡すことへの不安も障壁になります。
項目数だけを改善指標にせず、送信前後の体験まで確認する必要があります。
フォームの計測と送信後の動作まで確認できているか
フォームのチェックは、送信できることだけで終わらせず、完了画面、通知、データ保存、広告計測まで確認します。
フォーム上は正常でも計測や連携に不具合があれば、マーケティング判断を誤る原因になります。
フォーム改善では、画面上の項目やデザインに目が向きますが、実務では送信後の処理も同じくらい確認が必要です。
ユーザー側では問題なく送信できていても、社内通知が届いていなければ問い合わせ対応が遅れます。
広告のコンバージョン計測が発火していなければ、広告管理画面では成果が発生していないように見えます。
テスト送信を実際に行う
フォーム公開前には、すべての項目を実際に入力し、送信までテストします。
正常なパターンだけでなく、必須項目の未入力、誤った形式、長い文章、スマートフォンからの送信なども確認します。
問い合わせの種類によってフォーム内の表示や通知先が変わる場合は、それぞれのパターンを試します。
テストでは「送信ボタンが押せた」ことだけで完了とせず、完了画面まで遷移したかを確認します。
自動返信と社内通知を確認する
フォーム送信後に自動返信メールを設定している場合は、実際にメールが届くか確認します。
件名、送信元名、本文、URL、問い合わせ内容なども確認します。
同時に、社内担当者への通知メールやチャット通知が正常に届くかをテストします。
フォームから問い合わせが取れていても、担当者が気づかなければ対応速度が落ちます。
問い合わせ後の初動まで含めてフォーム運用と考える必要があります。
CRMやスプレッドシートへの保存内容を確認する
フォーム情報をCRMや顧客管理システム、スプレッドシートなどへ連携している場合は、項目の対応関係を確認します。
フォーム側で新しい項目を追加したのに、連携先に値が保存されていないケースがあります。
逆に、フォーム側で項目を削除した後も古い項目を前提とした処理が残っている場合があります。
画面上のフォームだけを更新せず、その後につながっているシステムまで確認します。
広告とアクセス解析のコンバージョン計測を確認する
広告を利用している場合、フォーム完了をコンバージョンとして正しく取得できているか確認します。
完了ページへの到達を計測しているのか、フォーム送信イベントを計測しているのかによって確認方法は変わります。
送信ボタンのクリックだけを成果としている場合、入力エラーで送信できなかったユーザーまでコンバージョンとして計測する可能性があります。
フォーム上の実際の問い合わせ件数と、広告管理画面やアクセス解析上のコンバージョン件数を定期的に照合すると、計測異常を見つけやすくなります。
フォーム改善後は数値の変化を確認する
フォーム項目を変更した後は、フォーム到達数、入力開始数、送信完了数などを確認します。
たとえば説明のための仮の値として、フォーム到達が1,000件、送信完了が100件なら、到達から送信までの完了率は10%です。
項目を削減した後に同じ条件で送信完了が130件になれば、フォーム周辺の改善が影響した可能性を検討できます。
ただし、流入元、広告訴求、ページ内容、期間などが同時に変わっていれば、フォーム変更だけが原因とは断定できません。
フォーム項目をチェックするときは、「短くできたか」だけではなく、問い合わせの量と質、その後の営業対応まで確認します。
フォームから取得する情報を減らした結果、問い合わせ件数は増えても営業が対応できない状態になることもあります。
逆に、問い合わせ後に聞けばよい情報までフォームで必須にしていれば、商談候補となるユーザーを送信前に失っている可能性があります。
フォーム項目の設計は、CVRだけではなく、マーケティングから営業までの運用をつなぐ設計として確認する必要があります。
よくある質問
フォーム項目は何項目くらいが適切ですか
一律に適切な項目数はありません。問い合わせ後の対応に必要な情報と、ユーザーが入力する負担のバランスで決めます。単純に項目数を減らすのではなく、各項目の取得目的を説明できるか確認します。
電話番号は必須にしたほうがいいですか
電話での連絡が問い合わせ対応に不可欠なら必須にする理由があります。メールだけで対応できる場合や、資料送付だけが目的の場合は、任意化や削除が可能か検討します。
自由記述欄はなくしたほうがいいですか
なくす必要はありません。相談内容など、選択肢だけでは把握できない情報には自由記述が有効です。ただし、何を書けばよいかわかる入力例や説明を添えると回答しやすくなります。
フォーム改善では最初にどこを確認すればいいですか
まず必須項目を確認します。その情報がなければ問い合わせ後の対応ができないのかを一項目ずつ確認し、不要な必須項目を減らせないか検討します。
フォームを変更した後は何を確認すればいいですか
実際の送信件数だけでなく、フォーム到達数、完了率、問い合わせ内容、商談化状況まで確認します。自動返信、社内通知、CRM連携、広告のコンバージョン計測が正常に動いているかもテストします。
まとめ
- フォーム項目は、問い合わせ後の対応に必要な情報だけへ絞る必要があります。取得目的が曖昧な項目を増やすほど入力負荷が高まり、フォーム到達後の離脱につながりやすくなります
- フォームでは、問い合わせを成立させるために不可欠な情報だけを必須にします。あると便利という理由だけで必須設定を増やすと、回答できないユーザーをフォーム上で失う可能性があります
- フォーム項目は、入力内容に適した形式を選び、ユーザーが入力方法を考えなくても回答できる状態にします。自由記述を減らし、選択式や入力例を適切に使うことで入力途中の迷いを減らせます
- フォーム項目は、ユーザーが項目名を見ただけで何を入力すべきか判断できる表現にします。意味が広い言葉や社内用語を避け、必要に応じて入力例や補足文を添えることが必要です
- フォームのエラー表示は、エラーが発生した項目の近くで原因と直し方がわかる状態にします。送信後に一括でエラーを出すだけではなく、ユーザーが修正箇所をすぐ特定できる設計が必要です
- フォーム項目は、スマートフォンで文字入力、選択、修正、送信まで無理なく完了できるか確認します。PC表示だけで判断せず、実際の端末で入力操作を行い、画面幅やキーボード表示まで確認します
- フォームでは、入力内容だけでなく、送信後に何が起きるのかを事前に伝える必要があります。連絡方法や個人情報の扱いが不明なままだと、入力完了直前でも送信をためらう原因になります
- フォームのチェックは、送信できることだけで終わらせず、完了画面、通知、データ保存、広告計測まで確認します。フォーム上は正常でも計測や連携に不具合があれば、マーケティング判断を誤る原因になります