概要
| 項目 | 内容 |
|---|---|
| プロダクト | レジャー・アクティビティのオンライン予約サービス（BtoC） |
| 対象 | 予約手続きの「お客様情報」入力フォーム |
| 役割 | プロダクトデザイナー兼ソフトウェアエンジニア（ユーザー調査、UIデザイン、フロントエンド・バックエンド実装） |
| 期間 | 2週間 |
| チーム構成 | デザイナー2名（うちデザイナー兼エンジニア1名）・エンジニア4名 |
| ユーザーテスト人数 | 7人 |
| 成果 | 繁忙期のフォーム関連の問い合わせ：週200件超 → 週4件 |
繁忙期の最中に、入力フォームに起因する問い合わせが急増していた。改修リスクを抑えるため入力項目や画面フローは大きく変えず、情報設計・必須表示・エラー表示の3点に絞って改善し、問い合わせ件数を大幅に削減した。
秘密保持のため、個人や組織を特定できる情報は掲載していない。デザイン画像も抽象化・簡略化している。
背景
商品のコンバージョン率向上施策の一環として、注文（予約）フォームの課題を洗い出し、改善するプロジェクトを立ち上げた。
当時、このフォームには次の問題があった。
- フォームページでの離脱率が高い
- フォーム入力に関する問い合わせが多く、繁忙期には週200件を超えることもあった
そのため本プロジェクトでは、ユーザーの入力時の迷いや誤りを減らし、問い合わせ件数を減らすことを主な目標とした。
課題の把握
問い合わせ分析と簡易ユーザーテスト
まず、CSチームに実際の問い合わせ内容の一部を共有してもらい、ユーザーがどの項目・どの場面でつまずいているかを確認した。あわせて簡易的なユーザーテストを実施し、入力の様子を観察した。ユーザーからは次のような声があった。
文字が多くて、読むのに時間がかかる。（ユーザーA）
フォームが送信できないとき、どの項目に不備があるのかわからなくて困る。（ユーザーB）
必須項目かどうかがわからなくて困る。（ユーザーC）
課題の整理
- 情報量が多く、整理されていない：入力に直接関係しない説明文やキャンセルポリシーが常に展開されているため、フォームが長く、読み解くのに時間がかかる。
- 必須表示に一貫性がない：「＊」が付いている必須項目と付いていない必須項目が混在しており、どこまで入力すべきか判断しづらい。
- エラーの場所と直し方がわからない：送信できないとき、どの項目をどう直せばよいかが伝わらない。
- 注意書きがエラーに見える：入力ルールを示す赤字の注意書きが常に表示されており、エラーメッセージと見分けにくい。
制約と方針
制約
- 繁忙期中の改修となるため、スピードと低リスクを最優先する
- 実装上の影響範囲を抑えるため、入力項目や画面フローは大きく変えず、コード差分の小さい改善に絞る
方針
- 情報設計（Information Architecture）から個々のUIへと、トップダウンで改善する
- 関連する項目をグループ化する
- 入力に必要な情報を優先し、補足情報は必要なときだけ見られるようにする
- 各項目が必須か任意か、どの書式で入力すべきかがひと目でわかるようにする
- エラー時は「どこで・何が起きていて・どう直せばよいか」を明確に示す
ベンチマーク調査
入力フォームは多くのWebサービスに共通するUIであり、他社の設計から学べることが多い。そこで、航空会社やホテルなどの予約フォームを中心にベンチマーク調査を行い、アンチパターンとベストプラクティスの両方を整理して、デザイン判断の根拠とした。以下はその一部である。
調査から得られた示唆は次の3点である。
- 多くのフォームでは、項目がグループ単位で整理され、必須／任意や入力書式も明示されている
- 極端に長いフォームは見当たらなかった。フォームの長さそのものがユーザーの負担になりうる
- 入力に不備がある場合は、該当する入力欄のそばにわかりやすいエラーメッセージが表示される
改善内容
これらの示唆をもとにデザイン案を作成し、ユーザーテストでの検証と修正を重ねて、最終的に下記のデザインとなった。
1. 情報設計：グループ化と段階的開示
- 入力項目を「代表者情報」と商品ごとの「利用情報」に分け、カード単位でまとめた（④）。複数人分の入力欄は横に並べ、縦の長さを抑えた。
- 商品説明やキャンセルポリシーなど、入力に直接関係しない情報は「詳細確認」に折りたたみ、レベルの説明はヘルプアイコンに格納した（①）。必要なときにだけ情報を開く段階的開示（Progressive Disclosure）の考え方である。
- その結果、入力項目を減らすことなく、フォーム全体を短く、見通しのよいものにできた。
2. 必須表示：グループ見出しに一括表示
ベンチマークでは項目ごとに「必須」ラベルを付けるデザインが多かった。しかしこのフォームはほぼすべての項目が必須で、項目数も多い。そのまま適用すると画面がラベルであふれ、かえって読みにくくなる。
そこで、グループ見出しに「必須」を一括で表示し（②）、例外である任意項目にだけ「任意」を付けた（③）。参考デザインをそのまま取り入れるのではなく、このフォームの条件に合わせて調整した判断である。
3. エラー表示：必要なときだけ、具体的に
- 常に表示されていた赤字の注意書きをやめ、入力書式はラベル（例：「半角ローマ字」）とプレースホルダー（例：TARO、YYYY）で示すようにした。
- エラーがない間は注意をそらすUIを出さず、ユーザーが入力に集中できるようにした。
- エラーは入力欄からフォーカスが外れた時点で、該当する欄の直下に表示する。枠線・背景色・アイコン・メッセージを組み合わせ、色だけに頼らずに伝えるようにした。
結果
UIの改善に加え、新しいデザインに合わせた実装仕様の調整やバグ修正もあわせて行った結果、繁忙期に週200件を超えていたフォーム関連の問い合わせは、週4件まで減少した。
振り返り
- 制約を設計条件として扱う：繁忙期・低リスクという制約があったため、入力項目やフローには大きく手を入れず、情報の見せ方と表示ロジックに絞った。この割り切りが、短期間での成果につながった。
- ベンチマークは答えではなく材料：必須表示のように、他社のベストプラクティスも自社のフォームの条件に照らして調整することで、より適した解決策になった。
- デザインから実装まで一貫して担当する：調査・デザイン・実装を一貫して担当したことで、仕様の調整やバグ修正まで含めて改善をやり切ることができた。