こんにちは。willstyle.Uでディレクターをしている藤田です。

立場上、お客様とアプリケーションの仕様を設計することが多いのですが、どうしてもお客様の要望やユーザーの目線のみで仕様を考えてしまいます。もちろんそれはそれで正しいのですが、実際にその仕様をカタチにするための技術的な実現可能性についても考慮しなくてはなりません。そのため、willstyle.Uではエンジニアにも仕様設計の早い段階で打ち合わせに入ってもらうようにしています。

ただ、ディレクター・デザイナーもある程度技術的な内容について理解しておくと、仕様検討後の手戻りが少なく、また、エンジニアとのコミュニケーションを円滑にすることができます。このシリーズではUIデザイナー/ディレクターが知っておくべき最低限の知識と、それを要件定義・UI設計に応用する方法についてご紹介できればと思います。

第1弾は、Web通信の1丁目1番地、リクエストとレスポンスについてです。それでは見てみましょう！

リクエストとレスポンスって何？

サイトであれアプリケーションであれ、Webを使ったサービスでは、ユーザーから見えるクライアント（ブラウザやアプリ）と見えないサーバーとの間でデータのやり取りが行われています。このやり取りでユーザーが要求することをリクエスト、要求された結果を返すことをレスポンスといいます。このキャッチボールでWebが機能しています。

例えるなら、クライアントサイドはお客さん、サーバーは厨房のシェフです。お客さんがメニューを見て料理を注文する行為がリクエストであり、シェフが作ったハンバーグを届ける行為がレスポンスということになります。

UI設計への応用

では、リクエストとレスポンスを理解した上で、UI設計にどのように活かせるか考えてみましょう。

通信には時間がかかる

レストランで料理を注文してから出てくるときと同じように、インターネット通信にも必ずタイムラグが発生します。人間はボタンを押してからしばらく反応がないと、フリーズしたのか？とストレスを感じ始めます。見えないサーバー側でどれだけ一生懸命に処理が行われていたとしても、通信中の画面を設計するのはUIデザイナーの仕事です。

UIへの応用：読み込み中であることを示そう

よく用いられるアイデアとして、スケルトンスクリーンがあります。データが届く前に、これから表示されるであろうコンテンツの枠組み（スケルトン）を表示する手法です。ユーザーに「きちんと読み込んでいるよ」と伝えることで、ストレスを緩和することができます。このUIについては、詳しくは以前の記事で詳しく記載しております。

また、スピナーやプログレスバーも効果的です。ファイルのアップロードや決済処理などに時間がかかるときに、処理中であることを明示することができます。このとき、何度もボタンを連打できないように、ボタンをdisableにすることもセットで考える必要があります。

通信は「時々失敗する」

皆さんも経験があるかと思いますが、インターネットは常にいつも通り繋がるとは限りません。ユーザーの入力したURLに誤りがあったり、クライアント側の回線が混雑したり、サーバーがダウンしたりと、キャッチボールが失敗することがよくあります。（私の使用しているスマホの5G通信はJR新大阪駅-大阪駅間で必ず通信速度が低下します。）

UIへの応用：ユーザーにエラーの状態を伝えよう

通信が失敗した際に、画面が真っ白になってしまったり、何も反応しなくなったりすれば最悪です。ユーザーの行った処理が失敗したのか、成功したのかすらわからず、ユーザーはストレスを感じます。

以前ご紹介したJacob Nielsenの10のユーザビリティヒューリスティックスでも、「システム状態の視認性」が1つ目に位置づけられています。

何かしらのエラーが発生した際には、システムが返すエラーの理由（専門的には「HTTPステータスコード」と呼びます）に応じて、ユーザーへの「伝え方」をデザインする必要があります。

画面全体のエラー

探しているページが存在しないとき（404 Not Found）や、サーバーが壊れてしまっているとき（500 Internal Server Error）のためにも、それぞれの状況に応じたエラー画面を想定しておきましょう。

このとき、「Error: Code 5003 System Timeout」のようなシステム上のエラーコードをそのまま表記してしまうと、ユーザーはストレスを感じてしまいます。ユーザーが次に何をすべきかわかるマイクロコピーを用意してあげることで、システムからの離脱を防ぐことができます。

starbucks.comの404画面では、エラーの状態を伝え、次のアクションを提示しているほか、企業のブランディングに即した遊び心あるコンテンツを提供しています。

トースト通知・インラインエラー

作業を中断する必要があるほどの大きなエラーでない場合は、トーストやインラインエラーで知らせてあげることも有効です。お気に入り登録に失敗したり、フォームの入力内容に誤りがあるときなどを想定して、都度適切なエラー画面を設計する必要があります。

エラーを伝える際にどのUIを選択するべきかについては、こちらの記事が詳しいです。

最後に

いかがでしたでしょうか。今回は第1弾として、Web通信の基本的な仕組みと、知識をUI設計に活かす方法についてご紹介しました。次回はAPIと非同期通信についてご紹介予定です。お楽しみに！