利用者が情報を読み、操作し、結果を確かめるためには、製品との接点が必要です。
ユーザーインターフェイス(User interface、UI)は、そのための画面、ボタン、音声、物理的な操作部などです。
MDNの説明も、人と機械のやり取りを成立させるものとして扱っています。
見た目の装飾だけでなく、操作と状態の伝達を設計します。

操作と結果を対応させる

たとえば、研修の申込画面を考えます。
利用者は日程を選び、参加者を入力し、料金を確認して送信します。
押したあとに何が起き、申し込めたかがわからなければ、二度送信するかもしれません。
入力の前提、実行する操作、処理中、完了、失敗を一連の流れとして設計します。

ボタン名は、押すと何が起きるかを示します。
「次へ」だけで料金が確定するなら、利用者の予想と結果がずれる可能性があります。
訂正や中断、戻る操作も含め、失敗から回復できるかを試します。
正常な手順の画面だけでは、実際の操作を評価できません。

情報の意味を伝える

入力欄には、何を入れるかがわかる名前と、必要な条件を置きます。
W3Cのフォームのガイドは、入力部品へ適切なラベルを関連づける方法を説明しています。
視覚的に近くへ置くだけでなく、支援技術からも目的がわかる構造を確認します。
画像や色だけに意味を任せず、利用する方法の違いを考慮します。

画面が狭い端末、キーボード、読み上げなどでも、重要な作業を完了できるかを確かめます。
一つの表示環境で見た目が整ったことと、異なる条件で使えることは別です。
対象者の経験と、必要な支援も含めて評価します。

UIと体験全体

申込画面が使いやすくても、参加案内が届かなければ、研修へ出席する目的は達成できません。
UIはユーザー体験の一部であり、提供内容、契約、問い合わせなどの条件とつながります。
画面内だけで解ける問題と、運用の変更が必要な問題を分けます。

試作品の評価では、好みだけを聞かず、対象者が自分で作業を終えられるかを観察します。
迷った箇所、誤操作、助けた内容を記録し、次の案で確かめます。
全体の範囲はユーザー体験、目的の整理はニーズステートメント、早期の確認はゲリラテストを参照してください。

参考資料