みなさんこんにちは。シナップ大川です。
本日は画面設計時、デザイン時の考慮漏れのお話です。

画面のデザインを終え、「やったーできたー！」と自信満々でフロントエンドエンジニアにデザインを渡した時、「これってこういう場合はどのような表示になるのですか？ここは？ここも？」と質問が返ってきたという経験を持っているディレクターやデザイナーの方は多いのではないでしょうか。

特に最近のWebサイトは表示要素（データ）が可変であったり、ユーザーの入力によってインタラクティブに画面が更新されるものも多く、以前に比べても様々なケースに合わせて画面の表示や振る舞いを考えなければいけない、裏を返すと、考慮漏れしやすい項目が増えました。

例えば表示エリアにデータがない場合、逆にデータが想定を超えている場合、ユーザーが入力などの操作を途中でやめてしまった場合など、想定上はあまり起きないけれど、起きる可能性があるシチュエーションです。

これらは想定外であるがゆえに、ユーザー体験にも大きく影響してくるポイントとなってきます。
なぜならばトラブルが起きた時こそ、ユーザーがそのサービスに対してネガティブな気持ちになりやすいからです。
そのため、本来はしっかり考慮したいところですが、主だった表示や動作ではないだけに、後回しにされてその場しのぎな対応になったり、見落としてしまうこともしばしば。

そこで今回はこうした制作上見落としやすい反面、ユーザーの体験上、意外と重要な項目をピックアップしてみました。自身が取り組む前のチェックリスト的に見てもらえたらと思います。

データがない場合

まず代表的なものが前述のようにデータがない場合です。
「登録されている画像がない」「テキストがない」などなど。本来あるべきものがないことがありますよね!?
データの入力の際に[ない場合]はエラーが表示され、登録できないといった、データがないという状態があり得ない場合は考慮しなくてもいいかもしれませんが、任意に登録できる項目がある場合などは気をつけるべきでしょう。
その場合はエリアごと見えなくしてしまうのか、[No Image]のような代替画像が表示されるのかなど、検討しましょう。

テキストや画像などのデータが極端に少ない、または多い

データはあるけれど、想定よりも極端に少ない場合、または極端に多い場合があります。 こちらも入力時に制限を設けたり、運用ルールとして定めることもできますが、不特定多数のユーザーが利用するサービスなどではどのようなものが入ってくるかわかりません。
どのような量になっても閲覧上損傷のないようにデザインしておく必要があるでしょう。

入力の際に「何文字以上入力してください」などパスワード以外で下限を設定することはあまりありませんが、上限はある程度設けておいた方が破綻のない画面になるでしょう。

その上で平均的なボリュームで一番見えやすく、極端な例の場合でも担保できるようにレイアウトを考慮することがデザイナーには求められます。

極端に少ない時、かつその対応に別表示を用意するなどは費用対効果が見出せない場合などは、多少余白が大きくなってしまっても、数的には少ないので例外として容認するなどのすり合わせをするべきかもしれません。
無限に入力できるものは、ある程度のボリュームを超えたら「もっと見る」「続きを読む」などで別ページや項目ごとに折りたたむなどをする対応が考えられるかもしれません。

画像の画角が合わない

「ここにアップロードした画像が入ります」。デザイン上では綺麗に収まっている画像も、ユーザーが想定通りの画角の画像をアップロードするとは限りません。こちらも特に不特定多数のユーザーが利用するサービスなどでは往々にして起こる問題です。
短い辺を100%として表示エリア中央を中心にトリミングして収める、縦、横どちらかに合わせて、余ったエリアは背景色で塗りつぶす、横に100%で合わせて縦は成り行き、など、どのような画角の画像がきても収まるように考慮しましょう。

エラーページ

エラーページも考慮漏れしがちですが、ユーザーに取ってエラーが表示されるということはそれ自体が体験上思わしくありません。ページが存在しない404エラーを始め、通信エラーなど、想定されるエラーについてはどのような種類があって、どのような表示にすべきかを考えておきましょう。
最近は可愛らしいイラストを出してユーザーの気持ちを和らげようとするものも多く見られるようになりました。

フォームのエラー

フォームの入力チェック系のエラーは言わずもがなですが、例えばユーザーが入力中に何らかの理由で離脱した際、それまで入力していたものをどうするか、操作の離脱があった場合はどうでしょうか。
特に長文を入力するものや、何項目も入力するものでは重要です。
離脱前に「入力内容が失われます。よろしいですか？」とアラートを出す場合や、最近では入力内容を随時保存していて、再度入力しようとした時に一からやり直さなくてもいいものなどもあります。
技術的にできる、できないもあるので、エンジニアと確認しながら進められるといいと思います。

いかがだったでしょうか。 これ以外でも考慮漏れしやすいものはあると思います。複雑なサービスでは最初からすべてを考慮し尽くすというのもなかなか難しいものです。こうしたものはある程度実装する段階でよりよく調整していくという態度やスケジューリングも重要だと思います。

とはいえ上にあげたような項目は比較的起こる課題ですので、デザインに入る際、一度考慮し、必要があればエンジニアも交えて検討するのがオススメです。