縁の下のUIデザインという本を読んでみた感想
はじめに
この記事は縁の下のUIデザインを読んだ感想や、この本で得た学びを綴る記事です。
本書は、WEB+DBPRESSに連載された5年分のUIデザインについてのノウハウが書籍化された本です。合計35章あり7つに分類された構成となっています。
WEB+DBPRESSに連載されたコラムをまるっと載せているわけではなく、大幅に加筆修正が加えられていたり、新たに追加されたコラムもあります。もともとWEB+DBPRESSを読んでいた方でも新たに得られる情報があるのではないかと思うような一冊です。
ここで唐突ですが、はじめに表紙だけ紹介させてください。
私の推しポイントの1つが表紙です。個人的にとても好みです。
「絶対この本面白いじゃん？」と思わせるワードが散りばめられており、そのワードそれぞれが持つ疑問の答えがすごく知りたくなる表紙デザインになっています。
表紙に載っている疑問以外にも「え？この疑問に対するベストプラクティスって存在するんですか？！」と思う内容がたくさん載っており、とても楽しく読み進めさせていただきました。
全ての章に対して感想と学びを書きたいところですが、それを書くと記事自体とても長くなってしまいそうなので今回は前半で気に入った3つの章をピックアップしてご紹介させていただきます。
第1章
動きによる楽しさの演出 〜コンテンツの変化や操作へのフィードバック〜
私的に一番ハッとさせられた章で、とても印象に残っています。
お客さん・PM・デザイナー・エンジニアまで一貫して「これは大切だよね！」と重きをおいているのはユーザの使い勝手を向上する面かと思われます。
「ユーザに触ってもらうと使い方に戸惑っていた。もっと手順を簡易的にしよう」
「実装は複雑になるからやりたくないけど、これなら迷わずに操作してくれそうだよね」
「文字が小さいし色も見にくい。全体的に見やすくできませんか？」
など、これまで私が携わってきたプロジェクトでも「使い勝手」の面に対して様々なフィードバックが寄せられていたように感じます。
なので私も「各UIのクオリティを上げることで結果的にユーザの使い勝手がよくなるだろう」と考えていました。「UIが良い = 使い勝手が良い ＝ 良い印象与える = 良いサービス」と思っていたのです。
ですがこの章を読んでみると、使い勝手の面以外にも様々なところを見てユーザはサービスの評価をしてくれているのだと気付かされました。
人気のサービスには、ユーザが良い印象を1つだけ感じられるのではなく複数感じられるサービスなのだと思います。
サービスを利用している中で、ユーザ感じた印象の中の一つに「使い勝手が良い」という印象が含まれているだけで、その印象だけでサービスを評価することはないのだろうと思います。利用した中で感じたすべての印象をユーザの頭の中で無意識にトータルした結果、大きく分けて「また使いたい」のか「もう使わないでおこう」の2つに分かれるのかなと感じました。
確かにそんな単純に良いサービスか否かなんて決まらないよな〜と思い、今まで少し短絡的に考えていたと反省しました。
この章では、「サービスの使い勝手が良い」点以外で「サービスの良い印象をアップさせるには」という点について触れています。
いろいろなアプローチが考えられると思いますが、ここではデザインの中に「楽しさ」を加えると良いかもという提案がされており、その具体案がいくつか提示されています。この記事では本に書かれていた具体例を少しだけご紹介させていただきます。
サービスを使う中で感じる「楽しさ」は以下のような表現で加えることが可能です。
- 動的に変化があるコンテンツを足してみる
- リアルタイムな情報を追加してみる
- ボタンをタップした後キラッとしたアニメーションを加えてみる（TikTokやXのイメージ）
いろいろな遊び心を加えることで「なんか楽しい」という感覚をユーザに届けることができます。
確かに思い返すと、日頃よく使うサービスでは、ワクワクする要素や楽しいなと感じることが多いサービスを良く利用しているなと思います。利用しているときは楽しい！と明確に理解した上で使っている訳ではなく、似たようなアプリがあってもなぜかこれを使っちゃうな〜といった感覚です。
「楽しいデザインにしていこう！」というとデザイン自体のテイストが変わりそうなのでアレですが、「楽しさやワクワクが感じられる要素やコンテンツを入れていこう！」という方針であればデザインする側もイメージしやすくなるし、実際に取り入れやすいなと感じました。
携わるプロジェクトによっては、スケジュールの都合上叶わなかったり、フェーズ的にミニマムな機能でリリースしたいという状況に置かれる事も多くあると思います。
そんな中でもどこかに「楽しい」と感じられるような要素をデザインする時に加えていけたらよいなと思いながら読み進めた章でした。
第2章
未読と既読のデザイン
未読と既読のデザインは難しいなと思うデザインの一つだと感じます。
とりあえず未読のバッジをつけていればOKだよね！というわけにもいきませんし、未読のバッジ内に表示される数が増えすぎると段々とストレスを感じてきます。でも数を出さないとどれくらいあるのか分かりにくいから付けたいという要望もあったりするかと思います。
未読から既読にするタイミングに関しても一体いつがベストなのでしょうか。
通知欄を開いた瞬間なのか、通知をクリックして詳細ページに遷移した瞬間なのか。なにかしらのボタンを押した後なのかなど。
未読から既読に変更するタイミングはいろんなパターンが存在するように思います。
未読と既読はお知らせの一種なので、ユーザの目には必ず止まるようなデザインになっていることが多いです。ですがパーツの持つ面積は割と小さめですし、デザイン的に派手派手！というわけでもないので、目に止まる割には割と地味めなパーツであるかもしれません。
以上のことから、未読と既読のデザインはどのようにしたとしてもデザイナー以外には意図が理解されにくいかもな〜と思うそんなデザインの一つだと思っています。
私自身も、そこまで未読と既読のデザインについて深く考えたことはなかったので、この章はとても勉強になりました。この章では以下について言及されています。
① 無駄な未読表現は控えること
② 数字が意味している情報を明確にすること
③ 未読数を出すもの出さないものを分けること
④ 未読と既読のタイミングについて
この記事では①と④についてまとめていこうと思います。
①について、バッジの中に未読数が表示されているデザインは目に留まりやすいですが、全てにつけると情報のレベル感が同一になり意味を成さないバッジになってしまいます。
なるべく優先度が高い情報にだけ未読数が付いたバッジはつけるようにしたほうが良いです。
④について、未読と既読のタイミングは、サービスの性質やお知らせ機能でユーザをどのように管理したいかの方針によって決めるとよさそうです。
未読から既読にするタイミングは大きく分けて以下の3パターンが考えられます。
- 未読マークのついたアイコンをタップし、通知欄を開いた後に全て既読となる
- 未読マークのついたアイコンをタップし、通知欄を開いた後に通知の一つをクリックするとその一つが既読となる
- 未読マークのついたアイコンをタップし、通知欄を開いた後に通知の一つの中にある「既読」のボタンを押すと既読となる。もしくは「すべて既読」のボタンなどを押した場合に既読となる。または、「既読状態」を「未読状態」に戻すことができる。
1が適するパターンは、未読数が膨大に膨れ上がる可能性がある場合に適しているかもしれません。サービスにもよるとは思いますが、通知内容の一つ一つが全て重要ではなく、「通知が来ていること」と「通知の総数がどれくらい来ているのか」をユーザにお知らせしたい場合に向いてるかと思います。
例：1記事に対して、または1アカウントに対してのいいね数やお気に入り数など
2が適するパターンは、1のパターンとは逆で一つ一つの情報が重要な場合に適していると思います。まさにメッセージやメールがぴったり当てはまる印象です。
「誰からどのような内容が来たのか具体的に知りたい」と判断された時に利用するとよいかもしれません。
3が適するパターンは、1と2では物足りない場合に検討すると良いのかなと感じました。既読のタイミングを完全にユーザに任せたほうが良いと判断した時に取り入れられるパターンなのかなと思います。
例えばSlackなどはビジネスに用いられるため、利便性がとても重要視されるサービスの一つだと思います。未読数が付いたバッジがあちらこちらに表示されますが、すべては需要なメッセージなのでどれもSlack的には情報の優先度は同じぐらいです。
数多くの通知の中でユーザが情報の優劣をつけることになりますが、「とりあえずメッセージの内容は確認しておいて一旦未読にしておこう」というパターンや「あまりにもメッセージが多く届いてしまったのですべて既読にしておきたい」といった様々な行動パターンに対応できるようSlackは柔軟な既読・未読アクションが取れる設計になったのかなと感じました。
もしSlackが1だけのパターンや2だけのパターンの場合、かなり不便になるのではないでしょうか。
どのパターンでもそれぞれ長所短所があるので、サービスの性質・お知らせ機能の用途によって、適切に未読既読のタイミングを使い分けていきたいなと思います。
第４章
受動的な体験のデザイン 〜「なんとなく眺める」を快適にするには〜
アプリケーションのデザインをするにあたり「ユーザの潜在的なニーズを知る事」はとても大切なの事だなと改めて思わされた章です。
今から作るサービス、あるいは今作っているサービスはユーザが「能動的」になるサービスでしょうか？「受動的」になるサービスでしょうか？
例えば、InstagramやTikTok等はまさにユーザが受動的になるサービスではないかと思います。スマホを片手にぼーっとしながらスワイプしていく光景がイメージできます。
逆に欲しい情報があり、検索して情報を探しに行く場合は「能動的」になると思います。例に挙げたアプリケーションはユーザの目的次第で「能動的」にも「受動的」にもなる性質を持つのかなと感じます。
ユーザの達成したいことが決まっている場合は能動的になれるので、多少操作が難しくても頑張ってゴールに辿り着こうと努力する傾向があるそうです。なのでデザインに関しても少々踏む手順が多くなってしまう構造だったり、画面自体が少し複雑になっても許容されるかなと思います。
ですが、特にゴールが決まってない場合はアプリケーションを複雑な構造にすればするほど、説明が煩雑になるほどユーザが離れてしまう原因になるのかなと思います。いかに心地よくユーザにぼーっとしてもらえるかを考えながらデザインすることが大切なようです。
カードUIにするかリストUIにするのか、キーコンテンツを全体に刺さるコンテンツにするか一部に刺さるコンテンツにするか、サービスの性質やユーザの求める内容によって選択肢が変わります。
「デザインのセオリー的にこうしたほうがいいんじゃないかな〜」という面ももちろんあると思いますが、ユーザの行動パターンや潜在的なニーズが叶えられることを前提に考るべきなのかなとこの章を読みながら感じました。
これは「能動的なコンテンツ」なのか、「受動的なコンテンツ」なのか、を頭の隅っこで考えながら、様々なサービスをリサーチしていくのも面白そうです。
まとめ
UIデザインとは？といった全員に向けた内容ではなく、UIデザインをしている中でよく感じる小さな疑問に対しての回答がたくさん載っておりすごく最高な本です。
「これー！！知りたかったやつ！！！」と言いながら読んでましたし、章を読み切っては表紙を見て、「あ、この疑問解けた☺️」とかやったりしつつのんびり読み進めています。
後半編もいつの日かかけたらなあと思います。
とても良い本なのでぜひ気になった方は読んでみてください！
Discussion