「UIデザイン みんなで考え、カイゼンする。」を読んで

なぜ読もうと思ったのか

「メディアの改善（＝回遊率向上）」を目的としたチームにアサインされたが、「UIって何？どうつくればいいの？どう提案すればいいの？やったことないわからんヤバイ」と思い、勉強の必要があると感じたため。

読後、何を感じたか

「チームでものづくりをする」場合の、サービス改善のヒントがたくさんある本だと思った。
デザイナーに限らず、PM、エンジニア、企画、マーケティング、みんながわかっていたほうがいいことや進め方や手法がまとまっていて、みんなに読んで欲しいなと思った。

デザイナーの立場からどんな役割を担うべきか、どう業務の幅を広げていけば良いか、考えるきっかけになった。

実務のどのタイミングでどの章を参照したか、今の状況を当てはめながら段階を分けてかいつまんでメモ。（まだ提案が済んだばかりなので、実装して検証して…を繰り返して結果が見えてくる。はず。）
デザイナーの業務に関わるところをピックアップしているが、もっと上流の役割の手法についても詳しく記載がある。

＜前提を学ぶ＞

-CHAPTER1-

Webサービスの”カイゼン”と運用

02) デザインでは改善できないこと

今回の場合の、サービスを構成する3つの領域は、以下になる。
•デザイン（＝デザイナー［グラフィック面］）
•テクノロジー（＝エンジニア［開発面］）
•ビジネス（＝編集部［企画・運用面］）

05) 改善プロセスの考え方を見直す

「サービスを成長させる」目的の場合に有効な、「相手の観察」から始まるOODAループが適切。

08) デザインプロセスを「目に見える」ものにする

まず目的や課題があって、それを達成に導いたり、解決するためにどうあるべきか考え、作り上げていったりする過程がデザインです。（p27）

上記について、デザイナー以外の役割の人が理解していることは、なかなかないように思う。
見た目を整えて欲しいとか、かっこよくして欲しいとかの要望だけで、形をつくって見せることはできない。
意味や目的を理解したり設計したりしなくては、腑に落ちる形に落とすことができない。制作に入る前に、目的や課題の共有が必要。

-CHAPTER2-

UIデザイナーは何をどうデザインする？

03) UIデザインって何をするの？

ここがわかりやすく説明されていてよかった。

「何を作るのか、なぜ作るのか」といった要件定義のコミュニケーション能力はミーティングで必要とされ、「どう作るか、見せるか」といった具現化するスキルは実際のデザイン作業時に必要とされると思う。

＜実際の制作時＞

05) プロトタイプを作ってコミュニケーションを活発にしよう

「UIデザインを説明するときに大事なポイント」の部分

07) UIデザイナーの組織内でのコミュニケーションと役割

「事業会社での立ち位置」を理解。

•ビジネスサイドから見て→見た目をきれいに整える人、サイトやアプリの画面を作る人
•開発サイドから見て→画面仕様を設計する人、アイディアをプロダクトに具現化する人

ここの章を読んで、制作会社だと立ち位置が違うことを知った。
私は事業会社にしかいたことがないが、営業からは「（画面デザインしてコーディングしてアニメーションつけて納品データを作るところまでを含んで）作っている人」だと思われていることも多い。
PMやディレクターからざっくりした要望をもらって、意図を汲み、形の方向性を確認して、エンジニアにも伝わるように設計書を作り込んで渡して、思った通りに形作れているか進行確認しながらフィニッシュまで持っていく役割を担っていることは、会社に入るまではわからなかった。（上はWeb制作の大体の工程だが、毎案件明確にここからここまでが役割、と決まって一人でそれをやっているのではない…！）

-CHAPTER3-

「ビジネス視点」でサービスを成長させる

02) データにもとづくデザイン改善

★デザインに必要なデータ分析

自分がデザインするものを数値で把握することで、より納得感を持って対応を進めることができます。（p54）

参照データは、アクセスログ分析やSNS投稿分析、流出入にもとづく競合との比較分析、ユーザビリティ評価など。主にビジネス視点の立場主導で集めたデータを共有してもらうことが必要になる。デザイン提案する側もされる側も、双方納得感を持つために大事。
★改善プロセスの順序と検証

•課題：データから発見された課題
•仮説：原因とされる仮説
•改善施策：仮説に対する施策

提案するデザインに納得してもらうためには、ここを考えるのが重要だと思った。
課題をみんなで出し合い、形（施策）に落とし込む際に、ユーザーがどう思うか「仮説」をひとつひとつ立てていくことでスムーズに制作を進めることができたと思う。
→実装後、ユーザーテストなど行い、結果を参照して仮説の検証を定性的にしていくことが今後必要

＜今後に生かす＞

-CHAPTER4-

「ユーザーリサーチ」でサービスを改善する

12) ユーザーテストの結果を分析する

-CHAPTER5-

「デザインシステム」を作り育てよう

02) デザインパターンについて

04) 分業問題と領域ごとの知識の断絶

さらに知りたくなったこと、わかるようになりたいと思ったこと

デザインシステムの作り方

案件の規模・関わる人数にもよるが、デザイナー以外にも理解できる形で、コミュニケーションの共通言語をつくるとやりやすそう。今回の案件で必要かどうかは微妙。
アプリなどのプロダクトを運用する場合には作成されることが多い。（これは未経験）

参考：
Google, Apple, Audi ── デザインシステムのメニューを見比べれば、企業とデザインの関係がわかる | A.C.O. Journal | A.C.O. Inc.

Our little design system | 僕たちの小さなデザインシステム - eureka design

Pairsのデザインシステムを運用してみて。デザイナー視点のツール編🛠 - eureka design

プロトタイピングツールについて

UIデザインに限ったことではなく、ちょっとリッチなLP作成やサイト作成の際の、デザイン→実装時のデザイナー・エンジニア双方のストレスとコストを削減したい。ここ最近のストレスこれが多くを占めている。
現状、実装面に明るくなく、実装の難易度がわからずデザインを作成やアニメーション指示をしてしまい、実装の段階で手間取ることが多々あるため。
実装フェーズの、実装確認用のプロトタイプ作成にはどのツールが適するか？→検討
Adobe XD, Figma, Prott, InVision, Origami Studio, …

参考：
https://webdesign-trends.net/entry/2771

気づき

•「ユーザーを考える」プロセスは、UIデザインに限らず、誰かに届くものをつくる上で超大事

•チームで仕事をすると、違う視点を知ることができて面白い

•「もっと良くしたい」という思いを持った人と一緒に仕事するとやりやすい、進めやすい、ストレスない、愛is大事