こんにちは。
夏みたく暑くなったり、涼しくなったり、令和の皐月君は不安定ですね。

却説、会社で本を買ってもらえる制度があって定期的に欲しい本を帰るのですが、今回読んだ本はこちら

ラッキーなことにパラパラめくってたタイミングで著者の方交えた読書会にも行けました。
読書会の形式は読む章（今回は4章と5章）でチーム分けをして、さらにチームの中でも項目を分担して読んでまずはチーム内にシェア、最終的には章のまとめを作ってもう一方のチームにシェアするという形でした。
普段だらだらとしか読んでいなかったので、短時間の中で他の人にもいかに伝わりやすくまとめるか結構難しかったです。。

この内容だけでも記事書けたんでは…って思いましたが、せっかく全部読みきったので、今回はこちらの本全体の感想をつらつらと挙げてみます。

ユーザーのこと考えるのがめっちゃ大事

"UIデザイン"と書かれているものの、随所にユーザーのこと考えるのがめっちゃ大事（意訳）ということが書かれており、UIデザインのカイゼンはただただ見た目を綺麗にするだけではなく、「そもそもユーザーが求めているものはなんだっけ…？」というところから考えていかねばなと。

施策ありきになっていない？そもそも誰のためのデザインなんだっけ？をきちんと考えることが大事。

やっぱりUIってUXと切っても切り離せないんだろうなと。

改善プロセスにはOODAループ

改善＝PDCAサイクルなイメージだけど、PDCAサイクルだと評価の段階で現場のフィードバックが得られるので、計画の段階で現場の状況と乖離している場合計画自体の転換が必要になってきてしまい、そもそもの工程が明確になっていないものに対してはあまり効果的ではない。

一方OODAループ（下図参照）は「相手の観察」から始まる意思決定のためのフレームワーク。不明確で常に変化していく状況の中で、現状にあるものから最善の判断を下し、即座に行動を起こすことを目的としていて、一度実行したら終わりではなく、実行後にすぐに観察〜実行を素早く繰り返していくという特徴がある。

PDCAサイクルは業務改善などでHowを考えるのに効果的で、OODAループは事業開発などでWhatを考えるのに効果的なフレームワークなので状況に応じて使い分けると良い。

「デザイン」をデザイナーだけのものにしない

そもそもサービスを改善する場合UIデザインのみということはまれで、問題が1つだけじゃなく尚且つ複数の領域にまたがっていることが多いので、ユーザーにとって価値ある解決策を出すために各領域の担当者間での協力や専門技術の活用などしていくことが大事。
また、デザインプロセス（情報、思考、対話）を可視化することで、認識のずれを減らすことができ、あるべき方向性がより明確になる。

定性データも定量データもどっちも大事

課題発見のためにはデータ分析が欠かせない。でも、データ分析することが目的ではなく、あくまでも改善策を考えるために必要な課題の発見に使うもの。
データ収集は量と質の両側面を行き来するもので、「どんな目的でユーザーの何を理解するか」によってそのバランスを変える。

サービスを成長させるためにはビジネス視点も大事

自社サービスの価値ってなんだっけ？ユーザーが価値と感じていることとのギャップはないか？ちゃんと仮説検証が必要。

プロトタイピングがチームを作る

チームメンバー間で同様の理解と視点で対話するための「共通言語」を作る過程がプロトタイピング。
デザイナー以外も巻き込むことで、デザインの意図を理解したり、技術的な実現可能性を議論をしたりとみんなで考えることができる。
アウトプット内容の粒度はフェーズによって変えた方が良い。

ユーザーリサーチって結構いろんなやり方がある

ユーザーリサーチと一口に言ってもやり方は様々。インタビューだけがユーザーリサーチではないので、フェーズや知りたい内容などに合わせて最適なものを選んで行く必要がある。

あまりユーザーリサーチの手法の紹介で見かけないなぁと思ったのは、ゲリラインタビュー。
名前の通り街行く人に声かけてインタビューする手法で、潜在的なユーザーに出会えるメリットがあるそうなのですが、高度なトークスキルやネームバリューとかないときつそうだなぁと。。

この章書かれた方は実際にこの手法試したことがあるそうなのですが、いかにナンパに思われないかが大事だよと。

デザインシステムは作って育てるもの

デザインシステムはデザイナーだけでなく開発に携わるメンバー間の共通言語となり、チーム内のコミュニケーションの質や業務効率化・最適化できる。
また、デザインの一貫性があることでサービスの「らしさ」を演出できる。プロダクトの認知度や理解浸透であったり、同じ文脈には同じものが出てくることで、ユーザーは見慣れたものが多くある状態になるので、学習コストを減らし、わかりやすいサービス体験を提供できる。

デザインシステムは1つのプロジェクトやサービスを作り終えたら終わりではなく、UIのエコシステムとして継続的に機能させていく（育てていく）もの。
ただしデザイナーだけが得するものを作るのは意味がない。UIが統一されていないが故の管理コストを抑える、トンマナが統一されていないためにユーザーへのメッセージが伝わらないことを避けるなど、デザイナー以外にもメリットを感じてもらえることが大切。

いきなり壮大なものを作ろうとするよりも小さく始める決断をすることも必要。
理想的な状態にできるだけのリソースがあるってそんなにないから、一旦の課題を解決できる最小限って何だろうをと考えてみよう。

チームで協業を

チームでの協業については最終章のChapterタイトルにもなってがっつり書かれていますが、それ以外の章でもより価値の高いユーザー体験を提供するためには、 デザイナーだけでなく、エンジニアやディレクター、ビジネスサイドの人々も含めた"みんなで考える"ことが大事と繰り返し出てきます。
全体的に図も多く丁寧な説明が多いので、デザイナー以外の方にも是非読んで欲しいし、本当にデザイナーだけではカイゼンするのは難しいよなと。

ちょいちょいおかしなイラストなんなんだろう

かっちり作られたキレイな図だなと思ってページをめくるとゆるゆるな猫やタコが出てきたりとちょっと面白かったです。

最後に

著者の方々がnote書かれているのですが、一番驚いたのはfigmaって本もかけるんですね。

この本読んでやっぱりデザインシステムについて興味が深まったので、次は読みかけで止まっているDesign Systems読み進めます…。。