ユーザーが待っている間のUIデザイン

あなたは待つという行為は好きですか。私達の生活では1日の中に何度も待たなければいけない時間が発生します。
朝の出勤のために電車が来るのを待ったり、会社のエレベーターが降りてくるのを待つなど、既に慣れてしまってあまり意識していないかもしれませんが、実際には多くの待ち時間があるはずです。

アプリケーションでの待機

上記の現実での待つことと同じくらいの数を、私達はアプリケーションで体験しています。例えばTwitterで新しいツイートを見るためにリロードしたり、Safariで画面が切り替わるまでを待つなど、現実世界と比べるとミクロな時間かもしれませんが、回数的には同じくらい待つことを行なっています。
たしかに短い時間かもしれませんが、現実世界と違いアプリケーションを利用中のユーザーは他の何かをして待つことが困難という問題があります。現実の待ち時間ではiPhoneをすぐに取り出してTwitterやニュースアプリを見ることで退屈な時間を解消できますが、アプリケーションではなかなか現実世界のように何か他のことをして待っていてもらうわけにはいきません。
そのためにUIができることとしては、アプリケーション上で待機に対するフィードバックとして待ち時間の目安や、なぜ待つ必要があるのかを伝えることで、体感時間を軽減させたり、アプリケーションを閉じずに待ってもらうことができるかもしれません。
今回はそんな待ち時間に表示させるフィードバックとしてローディングのUIについて紹介します。

待つという状況

そもそも「待つ」というのは、何かの発生を期待してそれまでの時間を過ごすことです。何もせず待っているという状況は発生しません。必ず対象とそれに対する反応が存在しており、何らかの変化が未来に起こることを予測して人は待つことになります。
ではアプリケーションの場合にはどのような待機が発生するのでしょうか。処理やアクションを行なう対象で考えると、以下のように分類することができます。

• 通信的待機
• システム的待機
• 対人的待機

通信的待機

サーバーとの通信等によって生まれる待ち時間です。ローカルのみで使用できるアプリケーションを除き、どこかのサーバーとの通信が必要なアプリケーションでは少なからず待ち時間が発生します。
この待機は通信環境によって変化するため、開発者はオフィスのWi-Fiのある最速の環境ではなく、実際のユーザーの利用する通信環境を考慮する必要があります。

システム的待機

端末にインストールして利用するアプリケーションである以上、デバイス自体の処理速度によって待たされることがあります。近年のメモリの性能向上や、そもそもモバイルアプリケーションではユーザーが行なうことのできるタスクを制限しているため、あまり意識することは少ないかもしれませんが、過去の端末などでは予想以上に処理に時間がかかることがあります。

対人的待機

SNSなどのコミュニケーションが発生するアプリケーションでは、通信やシステム状態とは別に人によって待たされることがあります。例えばFacebookでメッセージを送った後など、相手も同時に入力をしていない限り、最短でも数秒の待機時間が発生することになります。
上記2つのケースと比べると、アプリケーションを閉じることができるため、ユーザーは待ち時間に対する許容量は比較的長いと考えられます。

ローディングの種類

上記のような状況では、いずれもユーザーが終了までの時間を正確には予測できないため、それぞれの状況に合わせてフィードバックをユーザーに返す必要があります。例えば現実世界では電車がホームに来ていなければ待つ必要があることがわかります。しかし、アプリケーションではただの空白の画面が存在しているだけでは、ユーザーは読み込みに失敗したのか、まだ読み込みの途中なのかの判断すらできません。そのためにローディングというフィードバックが必要になります。
処理は進行中ということで基本的にアニメーションが使われることになりますが、大きく分けて循環型と非循環型に分類することができます。それぞれ使用できる状況やメリットデメリットがあるため、必要に応じて使い分ける必要があります。

循環型ローディング

処理が完了するまで、一定のアニメーションを何度も繰り返し表示するフィードバックです。iOSではアクティビティインジケーターと呼ばれています。
待ち時間の発生する状況で言うと通信や対人によって発生する待機の時に使われることが多いパターンですが、同じ通信時でも量的にすぐに完了しないような場合や、完了までの時間がわかる場合には次に紹介する非循環型を検討する必要があります。
対人による待機に対するフィードバックは、Facebook Messengerのように相手が入力中ということを示すことで、少しの間ならアプリケーションに滞在してもらうという効果があります。しかし、このブログの著者のように長文を入力している相手でこのフィードバックを表示してしまうと、ユーザーをいつまでも待たせてしまい現実でのタスクに集中できなくなるので、使用に関しては注意が必要です。
また、全体的なデメリットとしては不測の自体には処理がいつ完了するのかが不明確という点があります。例えば10秒以上このアニメーションが続いていたらどうでしょうか。ユーザーは何かがおかしいと不安に思ったり、なかなか次に進めないことでストレスを感じることになります。

ユーザーが頻繁に更新をするようなFacebookのアプリケーションでは、上記のように通信ができていない時にはループを終了し、現在通信ができないことを伝えています。まだ実際には見たことはありませんが、微弱なWi-Fiを拾ってなかなかローディングが完了しない時などには、一応処理は進行させつつも「通信環境が安定していません」などのメッセージを表示させることでユーザーに安心感を与えられるかもしれません。

非循環型ローディング

処理が現在どれくらいまで進行しており、あとどれくらいで完了するかを視覚的に表示させるフィードバックです。iOSではプログレスビュー（バー）と呼ばれています。
通信やシステムによる比較的長い待機が発生した時であり、かつ完了するまでにどれくらいの時間がかかるか判断できる時に使われるパターンです。循環型に比べ、ローディングが完了するまでの時間がわかりやすく、より正確なものでは完了するまでの時間を表示させることで、ユーザーはこのまま待つのか、少しだけ目を離して他のタスクを行うかの判断がしやすくなります。時間がかかる場合にはプログレスのみではなく、現在何%完了しているかなどの情報をラベルとして表示させるのも有効な方法です。
デメリットとしてはあまりに長い時間の待機が必要な時には進行がわかりにくく、処理によってはアプリケーションを起動したままにしなくてはいけないため、ユーザーの大切な時間を拘束してしまいます。私が以前制作したアプリケーションでは一時的解決ではありますが、動画生成に対する処理時間を軽減するために非循環型のインジケーターと同時に、10数秒程のストーリー性のある循環型アニメーションを作成し、両方を使用することで少しでもユーザーの待ち時間を軽減する取り組みをしたこともあります。

待ち時間という、ユーザーが操作をしない時のデザインとしてローディングのUIを紹介しました。意外とプロトタイピングの時には考慮されず、実装が完了した段階などで気づくことの多い部分ですが、最低限必要なものでもあります。無理にロゴなどを使ったアニメーションを作る必要ないかもしれませんが、循環型と非循環型のローディング位はデザイナーが気を配るべきでしょう。
しかし、そもそも待ち時間を発生させない努力はチーム全体で必要になります。通信やシステム的な要因であれば、異なるタスクの実行中にバックグラウンドで進行させておくこともできるかもしれません。
また、待ち時間に関する例では敢えて部分的なUIとしては良くないとされる手法により、利用中の体験が改善されたということもあります。海外の空港の例ですが、敢えて荷物の受け取り場所までの距離を伸ばすことで待ち時間を無くし、手荷物の受け取り完了までにかかる時間は全く同じまま苦情をほぼ0にしたというものです。
UIの改悪がUXを改善させる場合