
アプリやWebサイトのデザインにはたくさんの画面や想定しなくてはいけない動作があって、いつも「何か忘れていないかな?」と不安な気持ちになります。継続的にチームに参加してプロダクトデザインを行う場合は開発チームとのやり取りの中で足りないデザインを追加していくようなことも多いでしょう。しかし、プロジェクトによっては、一旦全画面作って納品しなくてはいけないような場合もありますよね。このような時に、どうしても制作の優先度が低く、デザインするのを忘れられがちな画面や挙動があります。そして、そのような細かな部分にかぎってユーザー体験にとってはとても重要であったりします。今回は、そのような時に役立つように、デザインするのを忘れられがちな画面やステート、コンポーネントのデザインをまとめながら、これらの良い実装例としてAirbnbのWebサイトのデザインを紹介していきます。
エラー画面:「404以外にも500エラーもあると安心」
Webサイトにおけるエラー画面は多くの場合、構築されたWebサイト自体からではなく使用しているWebサーバーからHTMLが返されることが多いため、デザインを準備しないとデフォルトの味気ないものになってしまいます。エラー画面の中でも有名なものには、URLに該当するページがない場合に表示される404エラー画面がありますね。一時期404エラー画面に凝ったデザインを準備することが流行したため、404画面はデザインされることも多いかもしれません。
https://www.airbnb.jp/500
404エラー以外にも、発生頻度は低いものの重要度が高いものとして、サーバー側で何かしらの問題があって正常にページが表示できない場合に返される500エラーがあります。404エラーでは「ホーム画面に戻る」ボタンなどで、ユーザーを別ページに誘導すれば良いですが、500エラーではユーザー側での解決が難しい場合が多いため、ユーザーに対してより強い不安感を与えることになります。このページでは、問題の解決に向けて取り組んでいることを伝えたり、緊急の連絡が必要なユーザーのために連絡先を表示するといったことができると良いですね。Airbnbのエラーページでは、かわいいアニメーションを表示してブランド体験を損なわないようにしています。
サーバーからデータを取得して動作するアプリの場合も、画面単位で404や500エラーを表示することはないものの、何かしらの理由で存在しないリソースを取得しようとした場合や、サーバーの問題でアプリが使用できない場合のデザインを準備しておくと、いざという時にブランド体験が損なわれず安心です。
データ読み込み中の表示: 「スケルトン、スピナー、プログレスバーの使い分け」
「読み込み中」の表示はユーザー体験にとって重要でありながら、デザインを作る際の優先度はどうしても低くなってしまいがちですよね。データ読み込み中の表示としては、 スケルトンやスピナー、プレグレスバーの使用が考えられます。中でも、「コンテンツ」の読み込み時にはスケルトンを使うことが一般的となってきています。
https://www.airbnb.jp/
スケルトンの表示に関するデザイン上のベストプラクティスとしては、
ページ全体を覆うような読み込み画面(スプラッシュ画面)の使用は極力避けて、実際にコンテンツが表示される領域にスケルトンを表示
といったものがあります。スケルトン以外にもデータ読み込み中のUIとしてよく見かけるものとして、くるくる回る「スピナー」や読み込みの進捗を表示する「プログレスバー」がありますね。それぞれの使いわけとしては、
スケルトン = ユーザーが見る「コンテンツ」の表示待ち
スピナー = フォームの送信後など、ユーザーのアクションに対するサービスの反応待ち
プログレスバー = ファイルのダウンロードなど、サイズの大きいデータの読み込み待ち
を一つの基準とするとわかりやすいかもしれません。
データがない状態: 「エンプティステートは意外といろいろ必要」
注文一覧や予約一覧などのデータをリストアップするような画面をデザインする場合、多くの場合はまず数件の情報が表示されている状態のデザインに取り組みますよね。しかし、実際のサービス内ではそれらの情報が一つも表示されないような場合も少なくないです。このような時に、真っ白な画面を表示してしまわないように「エンプティステート」をデザインして、ユーザーに次のアクションを促すようにすると良いです。
https://www.airbnb.jp/trips/
また、デフォルトの状態ではデータがあるようなサービスの場合にもエンプティステートのデザインが必要なことがあります。なぜなら、ユーザーがそれらのデータを消してしまう可能性があるからです。エンプティステートが必要となる画面やコンポーネントの例としては以下のようなものがあります。
データリスト
購入商品一覧
予約一覧
お気に入りリスト
通知一覧
メッセージ一覧
検索結果
ユーザーアバターの設定がない場合
外部からのデータ取得に失敗した場合(OGP画像など)
こうしてみると、一つのサービス内でもエンプティステートが必要な部分は意外と多そうですね。サービス内で統一感のあるデザインにするためにも、どのようにエンプティステートをデザインするかについてはプロジェクトの早めの段階で検討しても良いかもしれません。
フォームの状態別表示: 「フォーカス やバリデーションを忘れずに」
お問い合わせから、プロフィール情報の編集までWebサイトやアプリケーションのさまざまな場面でフォームデザインは登場します。そして、そのほとんどの場合サーバーにデータを送るための何かしらのバリデーションや送信時のステートが存在します。
https://www.airbnb.jp/account-settings/personal-info
フォームデザインの際にデフォルトの状態以外にデザインが必要なステートとしては、以下のようなものがあります。
インプットフォーム
非活性時
フォーカス時
エラー発生時
送信ボタン
非活性時
送信中
送信完了後
特に送信ボタンを押した後にサーバーからの反応が返ってくるまでに時間がかかる場合は、上記のAirbnbの例のようにローダーを表示するなどして、サービスが処理を進めていることがユーザーに伝わるようにする必要があります。
ボタンの状態別表示: 「ホバーはさりげない変化で表現」
ボタンの状態別デザインも、必要であることはわかっていても良く忘れられがちなデザインの一つです。少なくとも、以下の2つのステートを準備するだけで操作性が上がります。以下のAirbnbの例ではホバー時にカーソルが当たっている部分の明度を少しだけ上げていることがわかります。ホバー時のボタンデザインは、デザインファイル上で2つのステートのデザインを並べてもほとんどわからないくらい「さりげない変化」にしておくのが良さそうです。
カーソルを合わせた「ホバー」時
クリック中
https://www.airbnb.jp/rooms/5153819
フラッシュメッセージ: 「UI上ではわかりにくい動きをユーザーに伝える」
UIデザイン内のボタンはそれらを押した時に何か「わかりやすい変化」が起こることが多いですよね。たとえば、画面の遷移や項目の追加などは「動作が完了しましたよ!」と言われなくても画面を見ればわかることが多いです。しかし、中にはUI上の変化がわかりにくいような動作をトリガーするボタンもあります。
以下のAirbnbの例では、「URLを取得する」ボタンを押した時にコピーが行われたことがわかるように、フラッシュメッセージでフィードバックをしています。このような場合に使えるポップアップをデザインシステム上に準備しておくといざという時に使えて安心ですね。
https://www.airbnb.jp/rooms/38078595
同様に、何かの処理が失敗した時にもフラッシュメッセージを使うことができます。たとえば、ネットワークエラーでデータの保存が失敗した場合などは、予想外の動作となるため、UI上の表示を見ただけではユーザーは何が起こったのかわかりません。このような場合には、問題が起こったことと、その問題の内容についてフラッシュメッセージでユーザーに通知すると良いでしょう。
まとめ
こうして見ると、Airbnbのサイトではユーザーエクスペリエンスに関するさまざまなベストプラクティスを発見することができますね。一時期は、デザインの依頼時にみんなが口を揃えて「Airbnbみたいなデザインにしてください!」なんて言うような時期もあって、「Airbnbみたいなデザインってなんだ」とデザイナーを悩ませたこともあったのではないでしょうか?しかし、こうして細かなUXに関する実装を見てみると、単なる見た目だけではないAirbnbのデザインの魅力が見えてきたように思います。