この記事の概要
2024年12月14日に開催されるStack Nagoya Fes Vol.3での発表内容です。
当日にこの記事を見ながら聞いてもらえるように＆イベントに参加していない人にも見てもらえるようにQiitaに投稿しています。
LTの原稿をそのまま載せているので、表現が口語的です。ご了承ください。
概要
UI Stackという言葉も普及してきて、インターフェースの様々な状態を考慮しながら制作するデザイナーも増えてきたと思います。
ただ「状態を考える」のが、まだまだ「見た目上のバリエーションを作る」に留まっている場合もよく見ます。
データの流れや変化を察知するわけではなく「どうやらエラーのときのデザインが必要らしい」と赤線で囲われたバージョンを作る、みたいなイメージです。
しかし、アプリケーションの意義や役割を考えれば、情報を適切に表示・編集させるなど、データベースとユーザーを上手に接続させるのが重要です。
見た目の話だけではなく、インターフェースが上手く機能するためのお話をしたいと思います。
UI Stackの説明
「UI Stackが普及してきた」と言っても、耳馴染みのない方もいらっしゃると思いますので簡単に説明します。
UI Stackは、UIで考慮すべき5つの状態を整理・分類したものです。
- Blank State: データがない状態
- Loading State: 読み込み中の状態
- Partial State: 部分的にデータがある状態
- Error State: エラーが発生した状態
- Ideal State: 理想的な状態
身近なものとしてSNSで説明します。
- Blank State: タイムラインに投稿が無い、フォローしている人がいない
- Loading State: タイムラインを更新して投稿を取得中
- Partial State: 1人だけフォローしていて十分なコンテンツがない
- Error State: 投稿取得中にサーバーエラーが発生した場合
- Ideal State: 十分な数の投稿がタイムラインに表示されている
これらを予め認識した上でインターフェースを作ると漏れがなく、実装上の手戻りも少ない、といった具合で普及してきました。
デザイナーが作りがちなパターンと改善案
ただし、実際のデータはどういう作りになっているのか、どうやってデータをやり取りするのか、といった観点が持てている人は多くありません。
よくあるパターンとその問題点、改善点をいくつか紹介します。
新規ユーザーへの「あなたへのおすすめ」
新規登録直後のユーザーはBlank Stateに遭遇しやすいです。
なんせ新しく登録したばかりですから、あれもこれも空っぽでしょう。
Blank Stateに対するセオリーは「単にBlankであると伝えるだけでなく、次にどうしたら良いかを示す」です。
このセオリーを上手く捉えられず、見た目だけを考えてしまっている例を話します。
登録直後のユーザーに対し、パーソナライズされたレコメンドを表示するインターフェースを提案したとします。
しかし、登録直後なのですからユーザーが登録している情報は少なく、行動履歴もありません。
一般論としてパーソナライズされたレコメンドは利用率アップに有効ですが、何も情報が無い中で何をどうパーソナライズするのでしょう。
改善例は、例えば次のようなものがあります。
- 世間一般での人気コンテンツを出す
- オンボーディング時に最低限の趣味嗜好を確認して、それをもとにする
パーソナライズされたレコメンドでも、世間一般の人気コンテンツでも、それを表すラベルは「あなたへのおすすめ」で共通かもしれません。
ただし、裏側でのデータとしてこの2つは全然違います。
見た目ファーストの思考でデザインファイルを作ると、これらを区別して扱うのが難しいのはお分かりでしょうか。
ローディング進捗のパーセンテージ表示
ローディング画面で、具体的なパーセンテージを表示しようとするデザイナーは多いです。
見た目的に「間が持つ」のもありますし、現在何%かが目に見える方が親切なのは間違いありません。
ただ現実的には、フェッチして結果をすべて取得するまでに、進捗割合を正確に把握するのは難しいです。
1つのローディングあたり3つのAPIを叩いて、1つ終わるたびに33%ずつ表示を増やす、とかならまだできそうですが、期待されているアニメーションとは違った見た目になるでしょう。
かと言って嘘の進捗アニメーションをつけても「100%の表示になったのに次に進まない」といった問題が起きそうです。
改善例は、例えば次のようなものがあります。
- シンプルなスピナーにする
- 長時間かかることが予想される場合は、その旨をテキストで表示する
いずれにしても、処理が大変で時間もかかるような場面で、変に格好つけないのが大事です。
曖昧なエラーメッセージ
「ここにエラーメッセージを出す」というデザインデータ自体は大抵の人が用意していると思います。
ただ、そのエラーメッセージが「不正な値です」とか「リクエストに失敗しました」とか、曖昧だと良くありません。
エラーなことが分かったとして、解消の手立てや再試行の手順が表示されなければ、ユーザーからしたら「で、私はどうすれば良いの？」です。
このとき、ユーザーの入力間違いなら解消や再試行もしやすいです。
なぜならユーザーの自分自身の行動だからです。
一方でネットワークエラーなどの場合、ユーザーはほとんどどうしようもありません。
何度も再試行してもらうのも悪いので、謝罪して「時間をおいて試してください」といったやり取りが限界かもしれません。
改善例は、例えば次のようなものがあります。
- 発生し得るエラーを理解しておく
- エラーの大きさや解消しやすさにあわせて、次に取るべき行動を示唆する
- （問題に対し、やや反則気味の回答ながら）フェイルセーフに設計しておく
「エラー状態を表す」という見た目を紋切り型に考えるのではなく、実際にどんなエラーが起きるのかを意識するのが大事です。
概念的に提案する無限スクロール
最後に、色々な状態の問題をあわせた例として、無限スクロールについて話します。
無限スクロール自体は悪いUIではありません。
ちゃんと使えば良い体験を提供できます。
しかし、見た目ファーストでの無限スクロールは、これくらいの見た目を作って終わりになりがちです。
実際はどうかというと、このようにうっかり問題が起きやすいインターフェースではあります。
- スクロールの度にフェッチしてパフォーマンスが悪い
- 遷移してから戻ってきた際、スクロール位置が保持されておらず最初からスクロールし直し
- 途中で進めなくなった場合、表示できる分がなくなったのかエラーなのか、などの判断がしづらい
優秀な技術者の方であれば「こんなの全部考慮して当然」と思われるのかもしれませんが、世の中にはそこまで気が回っていなさそうなものも多いです。
改善例は、例えば次のようなものがあります。
- パフォーマンス関連について実装者と議論
- 読み込み中やエラー発生時などに、状態を表すテキストを都度表示する
- そもそも無限スクロールをやめて通常のページネーションを採用する
これらをすべて考えるのが現実的に難しい場面もあると思います。
その場合は素朴なページネーションにしておいた方がよっぽど使い勝手が良いです。
見た目のスッキリさは若干失われるとも言えますが、何が大事かとか、自分達に何ができるのかを冷静に判断するのは重要です。
まとめ
インターフェースとは「境界面」といった意味です。
言葉の意味通り、データベースとユーザーの境界面として、双方のやり取りが円滑になるようにする必要があります。
それを実現するためには見た目上だけの分岐・バリエーション作成では不十分です。
今日お話したような内容を踏まえ、より良いインターフェースを、より良い境界面を作っていきましょう。
デザイナーとして見た目だけでなく、データや技術と向き合うことで、ユーザーにとって本当に使いやすいインターフェースを作ることができます。
ぜひ次のプロジェクトで意識してみてください。