システムとユーザビリティ

サーバサイドでユーザビリティの向上を

　今回も引き続き、「使い方」の観点からユーザビリティを考えます。前回（http://www.thinkit.co.jp/article/131/3/）はフォームの主にフロントエンドについての解説でした。今回もフォームの操作に関連する内容になりますが、よりシステム寄りなアプローチを中心に据えます。

　システム開発においてユーザビリティを考える上で重要なことは、次の2点に集約されると筆者は考えています。

・システムの都合をユーザーに押し付けない
・自動化できる処理は機械にやらせる

　そもそもユーザビリティとは「ユーザーがどれだけ効率的に目的を達成できるか」の指標ですから、システムの都合ではなくユーザー本意の設計がされていてしかるべきです。

　また、可能な部分についてはシステムによる自動化を進め、「ユーザーから奪う時間を最小にする」ことが利便性を高めることにつながります。ユーザビリティという言葉こそあまり使われませんが、この思想はエンジニアの間では一定の認知と支持を得ています。

　普段そういった分野の情報を得ていないと「ユーザビリティ」という言葉は特別なように聞こえるかも知れませんが、何も特別なものではありません。エンジニアが普段システムを構築する上で「この方が使う側は便利」と考えていることは、ユーザビリティの世界でもわりとそのまま通用するのです。

　では、この2つを基本的な考え方として、具体的にどのようなアプローチが考えられるのかを見てみましょう。

入力エラーをどう扱うか

　まず、避けるべきは「エラー通知の画面で再入力できない」という設計です。「入力 → エラー → 戻る → 再入力」というフローはユーザーにとって非常にロスが大きく、不親切です（図1-1）。「入力画面に戻る」という行為のコストもさることながら、再入力時にエラー内容が表示されていないことによって「何が悪かったのか分からない」ことがユーザビリティを大きく損ねます。

　最近ではこうしたシステムはずいぶん少なくなったようにも思いますが、簡易的な問い合わせフォームなどでは今も散見されます。エラー表示は専用のページで表示するのではなく、入力画面にエラーメッセージを挿入する形で実装しましょう。

　エラーメッセージの表示ですが、筆者は「2段階のエラー表示」が有効だと考えています。1つは「エラーがあったことを知らせる」ための表示で、もう1つは「どの項目がなぜエラーになったのか」の表示です（図1-2）。

　まず、画面上部で「入力エラーのため操作が完了できなかった」ことを伝えます。これにより、「操作を完了するには内容を修正して再送信する必要がある」ということをユーザーに理解してもらいます。

　次に「どの項目がなぜエラーになったのか」を示すメッセージを、実際にエラーとなった項目の脇に表示します。

　前者が欠けた場合は、そもそもエラーが発生したことにユーザーが気付かない可能性があります。エラーとなった項目が画面の下部、特にスクロールしないと表示されない領域にあった場合、ユーザーは「どうして先に進まないのか」といら立ちを覚える恐れがあります。

　画面上部にすべてのエラーメッセージをまとめて表示するシステムも見られますが、エラーの発生個所と理由が入力欄の近くに表示されないと、エラーの理由や「どう修正すればいいのか」という情報が入力時に目に入りにくく、不親切です。こちらも、エラーメッセージと該当項目が同一画面に表示されない場合に、特にユーザビリティの低下が顕著です。

　エラーになった項目の脇にはエラーメッセージを表示すると同時に、項目自体もCSSで視覚的に目立つようにして、ユーザーが修正しやすい体制を整えましょう（詳細は前回（http://www.thinkit.co.jp/article/131/3/）を参照）。

　また、エラーメッセージには「どうすればエラーを解消できるのか」や「ありがちなエラーの例」を具体的に提示するとユーザーの目的達成の助けになります。例えば、メールアドレスの末尾が「,com」などになっていた場合、「.（ドット）」と「,（カンマ）」を打ち間違えている可能性が高いので、そのことを示唆するメッセージがあれば助けになるかも知れません。