業務アプリケーションのWebフォームはどこまで説明・補助をするべきか

これは SmartHR Advent Calendar 2020 の17日目の記事です。
@kgsiです。SmartHRという会社でプロダクトなデザイナーをしております。
今回の記事は、業務アプリケーションの闇に向き合って憤死している一人のデザイナーが、首を180度にねじっても答えが出ない、Webフォームにどれだけの説明と補助が必要かに悩んだ内容を結論無く語る記事です。

フォームのベストプラクティスは先人たちが世にゴロゴロ出しております。Form Design Patterns の和訳が出版されて久しいですが、あれはいい本ですね、何度も読み返してます。
この本の中では「インクルーシブデザインの原則」というものが紹介されています。

- 同等の体験を提供する
- 状況を考慮する
- 一貫性を保つ
- 利用者に制御させる
- 選択肢を提供する
- コンテンツの優先順位を付ける
- 価値を付加する

インクルーシブデザインの原則（和訳）
https://inclusivedesignprinciples.org/ja/

この原則と、フォームのベストプラクティスに従えば適切なフォームと説明設計ができる...のですが、複雑なコンテキストを背景とした説明や補助をどこまでするか、は教科書通りにはいきません。
エラーの強弱の違い、必須項目と任意項目の表示バランス、ヒントの有無の判断基準...などを機能や画面単位で決め、且つ全体ルールに則った設定が必要になります。

扱うWebフォームを特性ごとに分類してみる

一口にWebフォームといっても形態は様々あり、例えば弊社SmartHRが取り扱っているフォームは、大別するとこれだけのフォームが存在します。

- 取り消し・変更可能
  - 申請
  - 権限
  - 役職
  - 部署
  - 雇用形態
  - メールフォーマット
  - etc..
- 取り消しが困難
  - 変更通知
  - お支払い
  - お問い合わせ
  - 決済

利用ユーザー、日常的に使う機能とそうでない機能、再設定が可能・不可能...など、扱うフォームの目的と機能によって、必要な説明や補助の強度が大きく異なります。
対象のフォームがどのような特性を持つかを理解した上での説明と補助の設計が不可欠です。

説明・補助・バリデーション

過剰な説明、必要以上のバリデーション...特性などを考えて設計しないと、必然情報は大盛りになりがちです。説明や補助は過剰にも過小にもならないよう、各項目ごとに紐解いて設定していきましょう。

1.説明を設計する

フォームに対して説明を付与することは大切ですが、説明が過剰であればあるだけ、ユーザーの認知負荷が上がります。
究極は説明無しに迷わず入力できるフォームが理想です。しかしお問い合わせフォームのような汎用的な機能を除き、その世界線を実現するのは困難でしょう。
実例ですが、今携わっている人事労務アプリケーションにおいては、ひと目でわからない専門的な入力や、相関条件により変化する入力が多数存在します。機能や画面が多いほど、ルールも無限に増えていきます。

・特殊な情報なのか、一般的なのか
・条件分岐はあるのか、ないのか
・利用頻度は高いのか低いのか
・制約があるのか、制約が大きいのか
・再変更可能か
etc...

氏名や電話番号に対して補足説明を過剰に行う必要はないと思われます。一方で承認経路や従業員一括登録・更新時の保護...など、サービス独自項目については、一読して概要がわかる程度の説明が必要になるはずです。

2.入力補助を設計する

ここで述べる入力補助は、サジェスト・住所検索など、予測した結果を補助的にユーザーへ提示する機能が該当します。
機能側で予測が難しい情報については、無理やりサジェストして補助しようとすると、単に邪魔な存在になってしまいます。邪魔にならないおもてなしを意識しましょう。

・補助によりユーザーの達成したいことを妨げないか
・補助を必要とするほどの入力の不便さがあるか

3.バリデーションを設計する

バリデーションについても一律に付ければ良い...という訳にはいきません。
そもそもバリデーションの目的は大きく分けると以下のとおりです。

・ユーザーが正しい書式で入力できる
・ユーザーのデータを保護する
・アプリケーションを守る

手法として最もよく使われるのは、クライアント側のリアルタイムバリデーション、アクション実行後のバリデーションの２つでしょうか。

リアルタイムバリデーションがリッチで、至上のバリデーションとされるような傾向がありますが、入力の縛りが強いフォームや、扱う情報によっては必ずしも適切なものではありません。また、項目数が多かったり、相関バリデーションの必要がある場合は実装工数が跳ね上がり、かけるコストに対してユーザーへのリターンが少ない可能性もあります。
状況に応じて必要・不要を判断し適切に設計しましょう。

参考：
・https://developer.mozilla.org/ja/docs/Learn/Forms/Form_validation
・https://uxmilk.jp/73608
・https://u-site.jp/alertbox/errors-forms-design-guidelines

おわりに

唐突に終わる感がありますが、書くのがダルくなったわけではありません、最初に書いた通りこの話に結論はありません！

フォーム設計とそれに伴うどこまで説明と補助をするべきかの問題は、プロダクトが巨大になればなるだけ複雑性を増す闇の問題で、開発者の頭を悩ます終わりのない課題です。

さらに言えば対話型インターフェースつまりWebフォームの最適化は、ユーザーとアプリケーションとの対話方法を探る行為とも言えます。対話をシームレスに行うためにはどう会話し、補助をしていくのか、常に考えて設計していくことが大切だと思いました（おわり）

----------------  ✁  ----------------

そして最後に求人情報をば。
SmartHRでは一緒にWebフォームの闇と戦ってくれる方を絶賛募集中です！