第 IV 部　Web デザイナーは、どう見るか

ここまで、画面のまとまり、注意、記憶、予想、操作後の返事について見てきました。では、制作中の画面に「なんか変だ」と感じたとき、Web デザイナーは何をすればよいのでしょう。

たとえば、申し込みボタンを押しても画面が変わらないとします。

ボタンの色が悪いのでしょうか。押したことを示す表示がないのでしょうか。プログラムが動いていないのでしょうか。通信に時間がかかっているだけでしょうか。

見た瞬間に原因を一つへ決めることはできません。しかし、「なんか変」を、確かめられる小さな問いへ分けることはできます。

画面を見ると分かること

画面を比べると、ボタンの位置、文字、色、押す前と押したあとの変化が分かります。

「押したあとも、ボタンの文字と色が同じだった」「処理中を示す文章がなかった」と書けば、ほかの人も同じ画面を見て確かめられます。

一方、「分かりにくいボタンだった」だけでは、何を見てそう考えたのかが伝わりません。大きさなのか、言葉なのか、位置なのか、押したあとの変化なのかを分けると、直す場所が見えてきます。

ブラウザに表示された画面は、HTML、CSS、JavaScript、画像、通信で届いたデータなどから作られています。

HTML を調べると、処理中やエラーを表示する場所が用意されているかが分かります。CSS を調べると、余白や幅がどの指定から来たのかが分かります。JavaScript の動きを調べると、クリックを受け取ったのか、通信を始めたのかが分かります。

画面に変化がないからといって、必ずしもボタンが動いていないとは限りません。通信は始まっているのに、そのことを画面へ表示していない場合もあります。

画面とコードを調べても、利用者が表示の意味を理解できるかまでは分かりません。

「送信中」と表示したとき、その人は待てばよいと分かるでしょうか。エラーが出たとき、入力内容を直して戻れるでしょうか。キーボードや画面読み上げでも、変化が伝わるでしょうか。

人が使うところを見るときは、技術的に壊れていると分かっている画面を、そのまま試してもらう必要はありません。先にコードで確かめられる問題を直し、そのあとで、人にしか確かめられない理解や行動を見ます。

第19章では、「なんか変」を画面上の具体的な違いへ変えます。第20章では、考えられる原因を一つに決めつけず、確かめ方を考えます。第21章では、二つの案を比べるときの見せ方を扱います。

第22章では、画面幅、拡大、長い文章、通信状態を変えたときの崩れを見ます。第23章では、ブラウザの開発者向け機能で HTML や CSS を調べます。第24章では、人が実際に使う場面から何を読み取れるかを考えます。第25章では、作った画面から新しく分かったことを、次の制作へ戻します。

Web デザインは、一度で正解を当てる作業ではありません。見えたことを言葉にし、原因を確かめ、直した画面をもう一度見る。その往復によって、最初は言葉にできなかった違和感を、具体的な設計へ変えていきます。