複数フォームの条件を整理し、運用できる申込基盤へ

利用者、問い合わせ希望者、取引を検討する事業者では、必要な情報と送信先が異なります。一つの共通フォームへ項目を増やすだけでは、不要な入力が増え、社内でも内容を適切な担当へ渡しにくくなります。用途ごとに条件分岐、確認画面、通知先、自動返信の内容を分ける必要がありました。

また、フォームだけを実装しても、利用者がサービス内容を理解し、自分に合う窓口を選べなければ運用できません。お知らせ、コラム、FAQなど公開後に更新する情報と、問い合わせ導線を同じ情報構造の中で整え、運用担当が変更できる範囲と制作側が管理する処理を分けることが課題でした。

最初に申込、一般問い合わせ、取引希望の三つを別の業務として分解し、対象者、入力項目、必須条件、分岐、確認内容、通知先、自動返信を一覧化しました。見た目が似ているという理由で処理を共通化し過ぎず、用途ごとに必要な条件を確定してから、再利用できる入力・確認部品だけを共通化しています。

サイト内では、サービスごとの情報を読み進めた位置から該当窓口へ到達できるよう、カード、タブ、ボタンの役割を揃えました。お知らせ、コラム、FAQはWordPressから更新できる構成とし、問い合わせ前に必要な情報を補えるようにしています。

この方法は、目的と社内の処理先を区別できる場合に有効です。通知先や分岐条件が運用中に変わる場合は、公開後の変更責任と確認手順を別途定める必要があります。

利用者が最初から窓口名を理解している前提にせず、どの情報を読み、どの時点で行動するかを整理しました。サービスごとの違いを保ちながら、見出し、カード、タブ、誘導ボタンの役割を揃え、同じ種類の操作は同じ見た目で判断できるようにしています。

フォームでは、入力、確認、完了の各段階で現在地と次の操作が分かる構成を重視しました。分岐によって項目が増減する場合も、突然別の画面に見えないよう、関連する説明と入力欄をまとめています。

エラーは色だけへ頼らず、該当項目の近くへ理由を示すことを前提にしました。サイトの情報導線とフォームを別々にデザインせず、理解から送信までを一つの利用体験として揃えています。

三つのフォームについて、用途ごとの入力条件、分岐、確認画面、通知先、自動返信を先に表へまとめ、実装と検証の単位を揃えました。入力部品は再利用しながら、業務ごとに異なる処理を無理に一つへ統合しない構成にしています。

検証では、通常の入力だけでなく、必須不足、分岐の切り替え、確認画面からの戻り、通知内容、自動返信を用途別に確認しました。操作要素はキーボードでも移動・選択できることを確認対象にしています。

公開後の運用では、フォーム処理と、WordPressで更新するお知らせ・コラム・FAQを分けました。窓口の変更がコンテンツ更新だけで済むのか、通知処理の変更を伴うのかを判断できる境界を残すことが重要です。