The UI Stack を振り返る

こんにちは、UIデザイナーの水澤です。

前回の記事で、UIデザイン案件のクロージングに向けて行うことを書きました。今回はその中で触れた The UI Stack について、Scott Hurff さんの記事「How to fix a bad user interface」と現在のアプリを参考に、自分なりにおさらいをしてみます。

由来

The UI Stack は、プロダクトデザイナーの Scott Hurff さんが提唱した考え方です。
すべての画面に最大 5つの状態を考慮することで “Awkward UI” を回避し、ユーザーがサービスを利用したときに「今どんな状態なのか」「何のアクションをすればいいか」「何ができるか」など、迷わず理解しやすい UI を作るのに役立ちます。

Creating interfaces that are easily understood by humans puts us product designers right up against the sad fact that computers are lazy. They don’t care about helping people understand what’s new, what to do next, or how to react when something goes wrong.

人間が理解しやすいインターフェイスを作ることは、私たちデザイナーにとって、コンピュータが怠惰であるという悲しい事実と向き合うことになります。コンピュータは、何が新しいのか、次に何をすればいいのか、何か問題が起きたときにどう対処すればいいのか、といった人間の理解を助けることには無関心なのです。

Scott Hurff さんの記事「How to fix a bad user interface」より引用
※日本語訳はDeepLによる自動翻訳

5つの状態とは

すべての画面で考慮すべき状態は、下記の 5つが挙げられています。

• Ideal State（理想的な状態）
• Blank State / Empty State（空の状態）
• Error State（エラー状態）
• Partial State（部分的な状態）
• Loading State（ロード中の状態）

Ideal State（理想的な状態）

ユーザーが最も目にする画面であり、サービス価値を最大化して提供されやすい状態のため、まずは Ideal State の検討から始めます。

UI設計の序盤では設計方針やトンマナの方向性が定まっていないため、最初に理想的な状態の画面設計を通してそれらを合意形成し、その後に Ideal State を基盤として他の状態を設計する流れが多いと思います（もちろん必要に応じて Ideal State 以外の状態を先に作ることもありえます）。

画面の例：

5つはあくまで最大数である

由来の章で「最大 5つの状態を考慮する」と話しました。最大とする理由は、画面によっては 5つすべての状態は必要ではない場合があるためです。

例えば上記のNetflix：ホーム画面やTwitter：検索画面は、ユーザーの何らかのアクションを必要とせず、自動的に Recommend される要素のみで構成されています。そのため後述の Blank State / Empty State の画面は不要と判断できますが、Googleフォト：検索画面ではユーザーが保存した画像データをもとにカテゴリ分けがされているため、画像データが 0件の場合（ Blank State / Empty State ）を考慮した画面が必要そうです。

Blank State / Empty State（空の状態）

空の状態というと何もないイメージを想像しますが、それを示すだけでなく、ユーザーに次のアクションを促す重要な役割があります。また、初めてそのサービスを利用するユーザーが最初に目にする状態でもあります。

The UI Stack では Blank State / Empty State について、大きく分けて下記 3つのバージョンがあるとしています。

1. ユーザーが初めてサービスを使うときに見られる状態
2. ユーザーが自発的にデータを削除した状態
3. 検索結果が 0件の状態

1. ユーザーが初めてサービスを使うときに見られる状態

画面の例：

1つ目の状態では、サービスを初めて利用するユーザーに向けて「どんな情報・機能があるか」「どんなアクションができるか」などのオンボーディングが必要です。サービス価値を理解してもらうために、ユーザーにアクションを促します。ユーザーが序盤につまずいてしまわないよう、良い印象を与えたいところです。

上記のNetflix：ダウンロード画面では、作品のダウンロード機能を単に説明するよりも、オススメの作品がダウンロードできることを強調し、ユーザーが深く考えずにアクションできる工夫がされています。

2. ユーザーが自発的にデータを削除した状態

画面の例：

2つ目の状態、ユーザーが自発的にデータを削除したということは、そのユーザーはサービスを利用しているということです。これは、さらにサービスを利用してもらうためにユーザーへ報酬を与えたり、その次のアクションを促す良いタイミングです。

上記のGmail：受信箱画面は、溜まったメールをアーカイブや削除で分別するアクションが完了した状態です。スッキリした画面に小さな達成を感じられるイラストとテキストが表示され、ユーザーはタスク完了の満足感を得られます。

3. 検索結果が 0件の状態

画面の例：

3つ目の状態は、ユーザーの探しているものが見つからなかったタイミングです。このとき必要なのはユーザーが何を探しているのか推測し、最適な提案を行うことです。

上記のNetflix：検索結果画面は、キーワード「たぬき」に該当する作品が見つからなかった状態ですが、キーワードからユーザーの求めている作品を推測しています。また、その作品が観られない代わりにユーザーが見たいものをさらに推測し、オススメ作品を提案してユーザーを手助けしています。

Error State（エラー状態）

なんらかの理由によってエラーが発生しているとき、ユーザーに「どこで、どのような原因でエラーが発生しているのか」「エラーの解消方法」を伝える必要があります。そのためデザイナーは、サービス利用中にどんなエラーが発生するか考慮した上で設計していきます。

また、エラー状態であっても「ユーザー操作が快適であるか」は念頭に置いておきます。例えばフォームの入力途中でユーザーが誤って前のページに戻ってしまったとき、入力していたデータを一時保存しておけば、ユーザーは最初から入力し直すことなく、すぐに続きを再開できます。

画面の例：

例えば上記のHOT PEPPER Beauty：予約画面では、必須入力の項目が空欄であることがエラーの原因なので、その近くに説明を示しています。

Twitter：プロフィール画面は、ネットに接続していない状態でアプリを起動した場合の画面です。複数の原因に対応するため共通のエラー表示をしていると予想しますが、理想では解消方法を具体的に示すのが良いと考えます。説明は簡潔なだけでなく明確なほどユーザーの助けになります。

メルカリ：パスコード画面は、セキュリティ保持のために入力回数が制限されています。もしこの画面にその旨の説明がなかったら、ユーザーは無自覚に入力回数を超過した後、理由もわからず入力ができなくなったことに混乱してしまいます。

Partial State（部分的な状態）

データが満たされている状態を Ideal State、全くない状態を Blank State / Empty State とすると、Partial State はデータが一部しかない状態です。

ユーザーは途中までサービスを利用した段階にあるため、サービス価値を最大化して提供されやすい Ideal State を目指してアクションを促す必要があります。次にとるアクションや目指すゴールがわかれば、ユーザーは迷わず進められます。

画面の例：

上記の例はどちらもプロフィールの完成度をパーセンテージで表し、完成までどのくらいかの目安を表示しています。特にLinkedin（PC版）：プロフィール画面では、完成度を高めるための次のアクションを提示し、ユーザーを導いています。

Loading State（ロード中の状態）

データを読み込んでいるときなど、もし Loading State で何も表示されなければ、直前に行ったアクションが本当に実行されたのかユーザーは不安になります。アクションに対する反応として今何が起こっているかを伝えるなど、ユーザーのメンタルモデルを形成していく必要があると思います。

画面の例：

表現として多かったのは、上記のDropbox：ログイン画面やTwitter：プロフィール画面のように余白にスピナーを表示する方法です。Apple Music：アルバム画面では、曲をダウンロードするために右上のアイコンをタップすると、そのアイコンがプログレスバーとしての役割も兼ねています。小さいプログレスバーですが、配色の工夫によって進捗状況を視認できます。

振り返ってみた感想

ここまで読んでいただきありがとうございました。

実在のアプリと照らし合わせて振り返ると、同じ状態であってもそのサービスの価値に合わせて柔軟に表現できることがよくわかります。Partial State の事例がマッチングアプリや人材系以外だとなかなか見つからなかったため、ほかに事例がないか今後も注視していきます。

Scott Hurff さんの記事には、彼自身が提唱する以前に「3つの状態を考慮すべき」とした Basecamp（当時は 37signals ）による “The Three State Solution.” の記事についても記載があります。インターネット時代の変化に合わせて 5つとしたそうですが、そうなると今後も増減していく可能性は十分にあるので、自分なりに考えてみるのも面白そうですね。