問い合わせフォーム改善｜
項目を減らすだけで、相談は増える？

「その前に、どこで困っているのかを分けて見よう。フォームにたどり着けないのか、入力できないのか、それとも送った後に届かないのかで、直す場所が変わるよ」

「まず担当者自身が、実際の入口から操作してみよう。四つに分けると確認しやすいよ」

「実在する顧客の情報は使わず、管理できるテスト用の連絡先を使おう。関係者にも知らせて、通常の問い合わせと混ざらないようにする。受付できない不具合が見つかったら、ボタンの見た目を比べるより先に直したいね」

「すべてのフォームに共通する最適な項目数はないよ。必要な情報まで消すと、初回返信で聞き直すことになる。まず、各項目を誰が何の判断に使っているか確かめよう」

「そう。『初回に必要』『後から聞ける』『今は使っていない』に分けてみよう。たとえば、次は架空の制作相談フォームの整理例だよ」

「連絡方法と業務次第だね。迷う項目は任意にする、相談種別に応じて表示する、初回返信で聞く、といった方法がある。条件で表示を切り替えるなら、不要になった欄の必須チェックが残らないかも確認しよう」

「それだけだと、入力した後に何の欄だったか分からなくなることがあるよ。項目名は入力後も見えるようにして、入力欄との対応を明確にしよう」

「色や記号だけに頼らず、『必須』『任意』を文字でも伝えたいね。形式に指定があるなら、入力を始める前に分かる場所へ例を置くんだ」

「読み上げ機能にも、どの入力欄の名前か伝わる実装が必要だよ。制作担当には、見た目と仕組みの両方で対応しているか確認してもらおう」。W3C WAI：Labeling Controls

「見るだけでなく、実際に入力しよう。キーボードが開くと欄が隠れたり、選択肢が押しにくかったりすることもあるからね」

「入力欄に合う設定になっているか確認したい。自動入力を使った後も、値を読み直して修正できるか試そう。名前や住所の表記を厳しく限定しすぎて、実際の表記が入らない設計にも注意だよ」

「キーボードで操作する人もいるからだよ。入力欄へ自然な順序で移動できるか、今の位置が見えるか、選択・エラー修正・戻る・送信まで進めるかを確かめよう」。W3C：キーボード操作の解説

「うん。普通に利用する人が進めるか、操作に困る場合の代替手段やエラー後の復帰も含めて確認する。この点検だけでアクセシビリティ全体への適合を証明できるわけではないけれど、具体的な問題を見つける入口になるよ」

「その案内だけで、どこを直すか分かるかな？」

「エラーは『場所・理由・直し方』をセットにしよう。該当する欄の近くに示して、複数あるなら全体の一覧から移動できると探しやすいよ」

「形式だけを調べているなら、存在までは分からないよね。案内は実際の検証内容と揃えよう。ファイル形式の例も、受け付ける種類を別に分かるように表示する必要があるよ」

「そう。実際に一つ間違えて入力し、修正後に送信できるかまで試そう」

「もう一度書き直すのは負担だね。同じ入力フローで修正するときは、入力済みの内容を保持して、必要な欄だけ直せるか確かめよう」

「もちろん。本文だけでなく、選択肢やチェック状態、添付ファイルがどうなるかも見る。相談種別を変更したときに、前の選択の内容が残るのか消えるのかも、利用者に分かる必要があるね」

「エラー修正のための保持と、ブラウザへの長期間の保存は別の設計だよ。共有端末で次の人に相談内容が見えてしまわないよう、何を、どこへ、いつまで残すかを決めよう」

「仕組みによってはある。その場合は、再選択が必要だと案内しよう。表示上は添付済みに見えるのに実際には送られていない、といった食い違いを避けたいね」

「通信やサーバー側の問題なら、利用者が入力を直しても解決しないね。入力エラー、処理中、受付失敗、受付結果が分からない状態を区別しよう」

「送信途中で通信が切れても、受信側では受付済みという場合がある。画面が失敗に見えたからといって、何度も再送を促すだけでは重複するかもしれない」

「利用者に処理中と知らせるボタン制御は一つの方法。ただ、再読み込みなどもあるから、受信処理側で重複をどう扱うかも相談しよう。実装に合った受付確認や再試行の方法を決める必要があるね」

「内容と操作の流れで考えよう。付けるなら修正箇所へ戻りやすく、値が保持されること。付けないなら送信前に見直せること。確認画面があるだけで誤送信を防げるわけではないよ」

「社内で担当者が受け付けられたかも確認しよう。完了画面、自動返信、担当部署の受信は、それぞれ別に照合する必要があるんだ」

「メールだけで受け付けるのか、管理画面に保存してから通知するのかでも、調べる場所が変わる。どの処理が成功したら完了画面を出す設計か、実装担当へ確認しておこう」

「実際に守れる運用と揃えよう。自動返信には、受け付けたことと次の案内を伝える。相談本文をすべて転載する必要があるかも、扱う情報に応じて検討したいね」

「メールアドレスを間違えていたら、第三者へ相談内容を送る可能性もある。受付確認に必要な範囲へ絞る方法も含め、管理担当と決めよう。迷惑メール振り分けや通知先変更の影響も、公開前に確認しておきたい」

「正常な操作に加えて、間違えた場合や戻った場合も試そう。完成画面を見るだけでは、修正して送信できるか分からないからね」

「『環境・操作・期待結果・実際の結果・修正担当・再確認日』を記録しよう。直ったら同じ手順を再実施して、別の欄や受信処理に影響が出ていないかも見るんだ」

「設定で直る範囲と、独自開発やツール変更が必要な範囲を分けてもらおう。制約を隠さず、利用者への案内や運用で補う必要があるかも判断できるね」

「それだけでは分からないね。広告の流入が増えたのか、アクセスした人の端末が変わったのか、別の影響も考えよう」

「フォームへの到達、入力開始、受付成功など、同じ定義の段階で比べたい。たとえば『送信ボタンを押した回数』と『社内に届いた件数』を同じ数として扱わないことだね」

「その場合は、短期間の改善率を断定しない。エラーが再現しなくなったか、入力を修正して送れるか、社内受信が成立しているかという操作の確認と合わせて判断しよう」

「それは避けよう。状態を調べるのに、氏名やメールアドレス、相談本文は必要ない。入力値ではなく、どの段階に進んだかを確認する設計にするんだ」

「それだけだと、見た目の変更で終わるかもしれない。対象のフォームと困っている操作、どこまで確認したら完成かを、一枚にまとめよう」

「具体的でよいね。さらに社内で受付を確認するところまで書こう。画面改修だけの見積もりと、通知や受信処理まで含む見積もりは、同じ条件ではないからね」

「既存の仕組みと問題によるよ。まずフォーム単体で直せる範囲を調べ、全体の刷新が必要かはその後に判断しよう。調査、改修、テスト、公開後確認をどこまで頼むかも合わせておきたい」

「必要な内容を書けて、間違いを直せて、担当者へ届く。その流れを揃えることから始めよう」

「この順番なら、問題と依頼内容をつなげやすいよ」

「うん。公開後も、通知先や外部ツールの設定を変更したら、影響するところを再確認しよう。フォームの完成は、見た目だけでなく、相談を受け取って対応できるところまで。 その条件を共有することが大切だよ」