フォームデザインのベストプラクティス: ウェブとモバイルのための10のルール

悪いフォームのコスト

悪いフォームは、誰かをページに呼び込むために使ったすべての費用への戦略税だ。摩擦がある場合、サインアップ・チェックアウト・オンボーディングフォームの完了率は平均約12%。摩擦を取り除けば、その数字は50%を超える。

そのギャップはほぼコピーやブランディングの問題ではない。10のルールを一貫して適用するかどうかだ。

notion.so でライブを見る

Salesforce スタイルの30フィールドのリードフォームが存在するのは、データベーススキーマをページにマッピングしてフォームと呼んだ誰かがいたからだ。ユーザーはそのためにサインアップしたわけではない。製品を求めてやってきたのに、あなたの資格確認ロジックがリードを失わせている。

ルール 1: 1カラム、画面ごとに1タスク

常に1カラム。マルチカラムレイアウトは Figma グリッドでは効率的に見えるが、画面上の完了率を下げる。

目は左から右に読み、連続性を期待する。フィールドが2列に分かれると、ユーザーはどちらの経路を進むかを決めなければならず、1文字も入力する前にそのマイクロデシジョンが摩擦を加える。

Notion のサインアップフローは、モバイルで一度に1つのフィールドが表示される中央の1カラムだ。フォームが速く感じられるのは、一度に1つのことを尋ねるからだ。それがルールだ。

ルール 2: ラベルの位置はラベルのスタイルよりも重要

ラベルはフィールドの上に置く。中でも横でもない。常に上、常に見える状態で。

プレースホルダーテキストをラベルとして使うと、ユーザーが入力を開始した瞬間に消えてしまう。その時点で、何を入力しているかを確認するためにフィールドをクリアしなければならない。Mercury のオンボーディングフローは、すべての入力ステップを通じてフィールド上部に永続的なラベルを使用しているため、入力中にコンテキストが失われることはない。

mercury.com でライブを見る

フォーカス時にプレースホルダー位置から上にアニメーションするフローティングラベルは許容できる中間点だが、アクセシブルにするには適切なコントラストと慎重なタイミングが必要だ。迷ったら、ラベルを上に置いてそのままにする。

ラベル配置の背景にある UX リサーチは、UX リサーチメソッドのガイドで詳しく説明している。

ルール 3: フィールドの順序はデータベーススキーマではなくユーザーの現実に従う

フィールドのシーケンスは、エンジニアがデータモデルを構造化した方法ではなく、人がタスクについて考える方法に合わせる必要がある。

カートの確認前に配送先住所を尋ねるチェックアウトフォームは、コンテキストの負担をユーザーに押し付けている。ホステッドチェックアウトフォーム UX の標準的な参照である Stripe Checkout は、フォームを3つのステップで構成している:

1. メール（あなたは誰か）
2. 支払い（どうやって支払うか）
3. 住所（どこに送るか）

これは合理的な人間が対面で使うシーケンスだ。データベースがフィールドの順序を決めると、国の前に郵便番号を、会社名の前に役職を尋ねるフォームになる。

ルール 4: バリデーションはサブミット時ではなくインラインで行う

ユーザーがフィールドを離れた瞬間にバリデーションを行う。送信ボタンを押した時ではない。

サブミット時のバリデーションは、ユーザーが10フィールドのフォームを記入してボタンを押すと赤いエラーの壁が現れることを意味する。各エラーは修正タスクであり、各修正タスクはユーザーを完全に失うリスクがある。ブラー時にトリガーされるインラインバリデーションは、ユーザーが次に進む前にエラーを表示する。

Apple ID のサインインは、ブラー時にメール形式を検証し、送信ボタンがアクティブになる前にアカウントの可用性を確認する。そのシーケンスにより、2つのカテゴリのエラーを一度に防ぐ。この背景にあるインタラクションパターンは、マイクロインタラクションデザインガイドで説明している。

ルール 5: モバイルファーストはモバイルキーボードを意味する

すべてのフィールドタイプは正しいキーボードを呼び出す必要がある。それがモバイルフォームデザインの80%だ。

電話番号を尋ねるフィールドにデフォルトのテキストキーボードが表示されると、ユーザーが何も入力する前にフォームは壊れている。数値フィールドには inputmode="numeric" を使用し、@ キーを表示するには type="email" を、価格には inputmode="decimal" を使用する。iOS と Android はどちらも入力モードの全範囲をサポートしている。

キーボードはモバイルの主要な入力デバイスだ。間違ったキーボードを指定すると、正しくデザインされた視覚的なフォームが使いにくいものになる。

これらのパターンが含まれる広範なモバイルファーストの基盤については、レスポンシブウェブデザインの基礎を参照。

ルール 6: プログレス、マイクロコピー、そして長いフォームの問題

フォームに5つ以上のフィールドが必要な場合、ユーザーにフロー内での位置を示す。

Airbnb の複数ステップの予約フローは、全体を通して名前付きステップのプログレスインジケーターを表示する。60%完了していることが見えるユーザーは、基準点を持たないユーザーよりも明確に完了する可能性が高い。

tally.so でライブを見る

Tally は埋め込みフォームに異なるアプローチを取る: 上部に永続的なプログレスバーがある一問一答形式で、ドキュメント化されたユーザーテストでシングルページの長いフォームを一貫してアウトパフォームしている。

マイクロコピーも同じ役割を果たす。「ステップ 2 / 4」は素のプログレスバーよりも正直だ。「本人確認のために必要です」はラベルのない機密フィールドよりも有用だ。

ルール 7: エラーメッセージは指示であり、非難ではない

エラーメッセージは非難ではなく命令形で書く。

「このフィールドは必須です」は非難だ。「続けるためにメールアドレスを入力してください」は指示だ。ユーザーはすでに何かが間違っていることを知っている。必要なのは修正方法だ。

最善のエラーコピーは正確な条件と正確なアクションを示す: 「パスワードは8文字以上で、1つの数字を含む必要があります」。Stripe Checkout はこれを正確に行う。メッセージはブラー時に表示され、問題を示し、条件が解決された瞬間に消える。

長引く赤い状態はない。ただ機能する。

ルール 8: オートフィルは後付けではなく機能だ

autocomplete 属性はブラウザに正確に何を入力するかを伝える。すべてのフィールドで使用する。

正しい autocomplete 属性を持つチェックアウトフォームは、保存されたデータがある電話で約12秒で完了する。それなしでは、ユーザーがすべてを手動で入力するため、同じフォームに2分かかる。その108秒のギャップがモバイルチェックアウト放棄のほとんどが発生する場所であり、解消するためのコストはゼロだ。UI コンポーネントライブラリガイドでは、これらの属性をデザインシステムのフォームコンポーネントに組み込んで欠落しないようにする方法を説明している。

ルール 9: 送信ボタンがすべてを決める

送信ボタンは契約だ。そのラベル、状態、位置は、次に何が起こるかをユーザーが信頼できるかどうかを示す。

説明なしにグレーアウトされたボタンは、フォームが壊れていることをユーザーに伝えるが、理由は伝えない。行き止まりだ。「Submit」というラベルのボタンは、ユーザーが何に同意しているかを何も伝えない。

「アカウントを作成する」「無料トライアルを始める」「構築を開始する」はすべてより正直だ。UI でその理由を説明できる場合にのみボタンを無効にする。Tally はフォームビルダーのすべてのステップでアクション固有のボタンコピーを使用しており、それが埋め込み B2B フローで平均以上の完了率に直接貢献している。

ルール 10: 実際の親指、実際のデータ、実際のレイテンシでテストする

高速 WiFi 環境のデスクトップブラウザでフォームをテストしても、機能するかどうかについて意味のある情報は得られない。

4G 接続のミドルレンジ Android デバイスで、すべてのフィールドに実際の長さのデータを使ってテストする:

• アクセント文字を含む名前
• 2行目にアパート番号がある住所
• 22文字のメールアドレス
• 1文字の名前

現実世界のエッジケースは Figma できれいに見えるフォームを壊す。実際のレイテンシは、バリデーション呼び出しが入力をブロックしているか非同期で実行されているかを明らかにする。その違いはブラウザシミュレーターでは見えず、2本のシグナルバーがある電話では致命的になる。

サインアップ、チェックアウト、またはオンボーディングフローのフォーム監査が必要な場合は、Brainy が実際の画面、実際のデータ、実際のコンバージョン数での10ルール完全監査を実施しています。

デザイナーがまだ最悪のフォームを出荷している場所

現在本番環境にある最悪のフォームには、3つのパターンが共通している:

• エンタープライズ営業リードフォーム: Salesforce スタイルの30フィールドの資格確認画面で、必須の「年間収益」セレクターがあり、インラインバリデーションがない
• 進捗を保存しないマルチステップオンボーディングフロー: 9ステップ中7ステップでの電話はユーザーをステップ1に戻す
• モバイルが主流になる前に構築され、再構築されていないチェックアウトフロー: すべての数値フィールドがまだ type="text" を使用しているのは「デスクトップでは問題なく機能する」から

3つのケースのエラー状態の選択もコントラスト要件を満たしていない傾向がある。アクセシブルカラーコントラストパターンはその特定の失敗ポイントを修正する。

3つすべてに共通するスレッド: フォームは入力する人のためではなく、システムのためにデザインされた。修正方法は同じだ。

10のルールを実行する。モバイルから始める。データベースには自分のスキーマを解決させる。

---

FAQ

フォームにはフィールドをいくつ設けるべきか?

結果が必要とする最小限の数だ。正しい数は、もう一つ削除するとプロダクトが壊れる数。フィールドを追加するたびに完了率が下がる。ゼロから始め、必須のものだけ追加する。

マルチステップとシングルページフォームのどちらを使うべきか?

5フィールド以上の場合、マルチステップはほぼ常にシングルページをアウトパフォームする。要件は可視的な進捗だ。それなしでは、ユーザーがその旅がどのくらい長いかわからないため、マルチステップフォームはシングルページより悪いパフォーマンスになる。ステップを示し、シーケンス内の位置を表示する。

必須フィールドをマークする最善の方法は何か?

必須フィールドではなく、オプションフィールドをマークする。上のルールが指摘するように、ほとんどのフィールドが必須である場合、すべてのフィールドに赤いアスタリスクをつけることは視覚的なノイズになる。

例外をマークする。フィールドの横の「任意」は意味のある情報だ。すべてのフィールドのアスタリスクはそうではない。

ユーザーを罰せずにパスワード要件を処理するにはどうすればよいか?

要件は入力開始前に表示し、失敗後ではなく。各条件が満たされるにつれてアクティブになる小さなチェックリストは、サブミット後のエラーウォールよりも優れたパフォーマンスを発揮する。Apple ID と現在のほとんどの認証フローはこのパターンを使用している。フィードバックはライブで、ポジティブで、決して懲罰的ではない。

フィールド幅は何かを伝えるか?

はい、ユーザーはそれを読む。フィールド幅は期待される入力長を示す。短いフィールドは短い回答を示す。フルワイドのフィールドは長い回答を示す。

レイアウトが許す限り、フィールド幅を期待される入力長に合わせる。フルワイドの郵便番号フィールドは間違いに見える。番地用のテキストエリアはやりすぎに見える。コンテナを期待されるコンテンツに合わせる。

モバイルフォームの離脱の最大の原因は何か?

間違いキーボードタイプが第1位。オートフィルが機能しないことが第2位。どちらも無言の失敗だ: フォームは正しく見えるが、ユーザーは効率的に完了できない。

フィールドごとに2つの属性で両方を修正する。投資は15分。リターンは同じスプリント内のチェックアウトコンバージョンで測定可能だ。