「デザインシステムの育て方」を読み終えた
デザインシステムの育て方を本屋で買って来て読み終えたので、個人的に気になったところを掘り下げてnoteに書きます。
本書は、Chapter 1 〜 10まで構成されています。
デザインシステムが必要なわけ
デザインシステムの基礎
デザインシステムを構成する部品
お墨付きにまつわる誤解
パイロットプロジェクト - デザインシステムの着手と維持に最適の方法
ガバナンスと貢献
役割と職責
デザインシステムのプロセスとワークフロー
デザインシステムの成功の指標
伝道に終わりはない
コンポーネント設計や実装手法をどのように工夫すれば、長く使っていけるデザインシステムにしていけるのかを考えていた中で、この本の存在を知り楽しみしてた。
本書は、具体的な設計・実装手法といった具体的ではなく、継続的にデザインシステムをどのように進化・改善を繰り返していくのか。実践的な部分も踏まえた内容になっています。
個人的に響いた部分やここはポイントだった部分をまとめてみました。
デザインシステムの一般的な利点
効率が増す
一貫性が生まれる
イノベーションを起こしやすい
安心感をもたらす
デザインシステムの利点の中で、効率化や一貫性といった部分は多くの書籍やブログ記事で取り上げられる話題であるが、イノベーションを起こしやすい・安心感をもたらすという点で学べた。
再利用可能になれば、自由に使える時間が生まれ未知の課題や解決策を練る時間に当てられるということだ。
時間は有限であり、無限ではない。有限である以上、デザインを一から考えたりバリエーションを考える時間を削減できれば本来当てたいプロダクトの目的に注力出来る点が大きいのではないだろうか。
たしかにWebサイトといった、会社ごとに色味や用件は異なる場合それぞれデザインしなければならない。
しかし、Webで掲載する以上ルールやパターンは用意できる。
例えば、余白のルールやレイアウトの種類・コンポーネントのパーツ等細かく切り出せば、それはデザインをする上での指標になる。
安心感をもたらす。最後にこの言葉が良かった。4つ目に加えた利点だが自分はこの安心感は大切だと思った。
このデザインや要件を考えて実装するにあたって、一からトンマナを図ったり時間がかかるなーと感じる部分がでたときに「裏ワザ」があれば安心できる。
最悪の場合、それを使えばできるかな？という考えがあれば精神的な余裕が生まれ、心理的安全性という部分に繋がるのではないだろうか。
デザインシステムのイニシアチブを成功されせるには、文化改革や組織改革が必要で、組織内政治に足を引っ張られてプロジェクトが失敗することも多い。
デザインシステムの実践を長く浸透させなければ、4つのメリットは享受するのは難しい
メリットはあるものの、このケースでうまくいかないことはたくさんあるなと感じた。
なにをもってデザインシステムなのか。どこが落とし所なのかの定義が重要だなと思った。
ホットポテトプロセス
ホットポテトプロセスという言葉を初めて知った。
よくエンジニア同士でのペアプロやモブプロに近いものを感じるが、このホットポテトプロセスはエンジニアとデザイナーが一緒に開発やデザインしていく手法のようだ。
アプリやWeb開発になるとデザインとエンジニアリングは別々の工程として扱わられますが、このホットポテトプロセスはエンジニアがコードを打ちながらレイアウトや装飾をデザイナーが指示しつつ作っていく流れになる。
このようにペアでやるという点で、ペアプロやモブプロといった相談しながら実際に動かしながら進めるところが似ていた。
デザイナーが先にカンプやワイヤーやデザインを決定してエンジニアに渡すというプロセスでは、デザインを見た時に意図や動きは分からないことが出てくる。
また、実際にコードを書くと想定した動きができないことも出てくる。
そのときの手戻りや確認のプロセスを排除できるのがホットポテトプロセスになります。
一緒に考え作り上げていくスタイルが、アジャイルっぽさを感じた。
デザインとシステムの由来
デザインシステムの定義は難しい。
一連のつながったパターンと、共有された実践。デジタルプロダクトが用途を果たすために、一貫性を持って組織されたもの
デザインシステムとは、ビジュアルスタイルやコンポーネントなど、個人やチーム、コミュニティがコードやデザインとしてドキュメント化・リリースしたもののライブラリで、プロダクトをいっそう効率的で一貫性のあるものにするために必要なものだ
デザインシステムとは、組織のデザインのあり方、デジタルインターフェースの釣り方に関する公式のストーリーだ
デザインシステムは組織全体で統治する意思決定である
コンポーネントが木なら、デザインシステムは森だ
それぞれの解釈としては正解だが、人によって解釈や見方は違うという点だ。
それはコードなのかドキュメントのなのか。広く一般的な定義なのか。
「デザイン」と「システム」の言葉の意味が広いということが挙げれる。
2つの言葉の原点について書かれていた。
デザインは名詞であり、動詞でもあるからだ
14世紀終盤から、「目印をつける」という意味で「designare」というラテン語が由来
16世紀終盤になって「目的をもって計画を立てる」という意味で「desseign」がフランス語として生まれた
システムは、ラテン語で「用意」・ギリシャ語で「部分から成る組織的な総体」という意味で「systema」という単語で生まれた
2つの言葉を組み合わせることで以下のような意味になる。
特定の目的のために組織的に組み合わせたもの
2つの言葉を組みわせるとしっくりきた。特定の目的と組織を組み合わせたものがデザインシステムなんだと学べた。
7種類のデザインシステム
その中で、7種類のデザインシステムがあると書いてあった。
ブランドのアイデンティティと視覚言語としてのデザインシステム
プロジェクトとしてのデザインシステム
ツールとテンプレートとしてのデザインシステム
デジタルプロダクトとしてのデザインシステム
プロセスとしてのデザインシステム
サービスとしてのデザインシステム
実践としてのデザインシステム
自分の所属や仕事的には、納期に追われるような仕事が主に多いのでプロジェクトとしてのデザインシステムが属していそうでした。
いわいる横展開できるかどうかが、以下の納品のスピードをあげていくかだなと思う。
納品することが目的ではないが、早く考えた企画やプロダクトを世の中にだしていくかが目的になるので、デザインシステムは重要な部分になる。
世界初の大量生産された車
世界初の大量生産された車の話しが良かった。
フォードが1908年に発売されたモデルTが、今の車の基礎になっている。エンジン・ギア・サスペンション・タイヤ・車体の簡素な作られていた。
今の車は先進的な機能が備わっているものの、運転そのものに必要なものは100年以上前から変わっていない。
進化はしているものの基本的な作りは変わってないことから現代人でも運転することは難しくない。
デザインシステムでも同じことが言える。組織にはそれぞれの特徴（ドメイン領域）がある。しかし、車と一緒で基本的な作り（パーツ）は標準装備として持てる。
車のもってる標準装備は変わらずに進化を繰り返している。
これをデザインシステムで置き換えると、標準（広く使われるパーツ）があって、ドメインレベル（業務ロジック）でカスマイズを加えたり拡張させていく部分が進化に当たるのだろうと個人的に感じたことだった。
デザインシステムとは"つながり"である
相互のつながりや機能を持たない、何かの寄せ集めは（システムではありません）。要素の分解をやめて、「つながり」、つまり、要素をつなげている関係性を探し始めるのがよいでしょう
参考文献の中で、やはり「世界はシステムで動く」が書かれていたのでここは通るよなと思った。
自分は読み終えてないので、並行して読むとさらに本書の理解がしやすくなる。
デザインシステムでは、ここのコンポーネントよりも関係性のほうが重要。共通項やコンポーネント同士のつながりに目を向ける。
真のデザインシステムはこれまで説明した部品の集合体である。デザインとエンジニアリングは、プロダクトにつながっていなければならない
コンポーネントライブラリとデザインシステムの違い
本書では、bootstrapを題材にコンポーネントライブラリとデザインシステムの違いについて書かれていた。
ただ本書にあるbootstrapは、バージョン3系とかだと思う。今はダウンロードボタンはなく パッケージをインストールする形になっている。（補足）
よくコンポーネントライブラリとデザインシステムは同じものの意味に言われることが多い。自分の所属するプロジェクトでも同じ意味合いとして捉えているところはあった。ただ先に書かれた デザインシステムは "つながっている" という部分においてコンポーネントライブラリとデザインシステムとの違いを知ることができた。
ここで伝えたいことは、bootstrapとMaterial uiとの比較でコンポーネントライブリとデザインシステムについて伝えているが、ここで伝えたいことはダウンロードかパッケージをインストールするかの話しをしている。
ダウンロード：ソフトウェアを配布するため、公式との繋がりがなくなる
パッケージインストール：パッケージにバージョンが記載されるため、常に公式と繋がりがある
ダウンロードの場合、コアのファイルを自分の環境で自由に変更を加えることができるため、独自の拡張をプロジェクトごとに書き換えすることができる。しかし、独自カスマイズを加えることで公式のアップデートに準拠できなくなり、デザインシステムの "つながり" がなくなってしまう。
Node のパッケージとしてインストールしたコンポーネントライブリは、公式との繋がりはpackage.jsonで繋がります。
インストールすることで、node_modulesにbootstrapやmaterial uiのコアファイルがインストールされて利用することが可能になる。
独自の拡張は、node_modulesのコアのファイルをいじることで可能ではある。しかし、各自の端末でpackage.jsonに書かれたバージョンでインストールされることからいじったnode_modulesのファイルは上書きされる。ゆえに独自の拡張はできないためデザインシステムとしての繋がりは維持される。そこがダウンロードとインストール違いなんだろうと感じた。
デザインシステムを作るうえで、パッケージにすることは必須であることが言える。Nodeというエコシステムがデザインシステムをつなげてくれている。
抽象的なシステムはつくりにくい
長くこの業界にいると、さぁデザインシステムを作ろうと思いどこからやる？というところで行き詰まる。
抽象的なシステムが一番難しい。カラーパレットすらも難しい。そもそも変わりそうな部分こそプロジェクトやドメインに依存するだろう。
自分が意識的にしていることは、小さく作ることにフォーカスしたいと思っている。
本書でも書いている「いつか誰かが必要としそうな要素は全部盛り込もう」という方向性がシステムを肥大させて、現実には利用者を想定できていない形になる。
だから、いま必要されるものを小さく作り必要なモノだけにフォーカスしてつくるべきだと感じた。
パイロットプロジェクト：デザインシステムに勢いをつける方法
何かの承認を得るために、何もない状態では承認はおりない。人は見えているものがあって承認フローのスタート地点に立つというのが根底にある。
デザインシステムも同様に作るから費用やスケジュールを確保したいだけでは始まらない。
パイロットプロジェクトは、新しい技術や事業を本格導入する前の試験的に実施するプロジェクトのことを指す。
デザインシステムも同様で、いままでデザインシステムやドキュメントが存在しない組織に「さぁ作りましょう」ではまず動かない。
作る上で、映画の試作のような続き・パート2が見たくなるような価値を提供するところから始めることが必要です。
また、上層部やステークホルダーと呼ばれる方々にデザインシステムに取り組み（デザインシステムという言葉は不要）について伝えるときは、取り組みについての結果を伝えることが大切です。
この作業を行えば予定より6週間早めれます
QAの手戻りが減り、バグが激減します etc
静止した物体は、その後も静止し続ける
この言葉はその通りだと思うし、ゼロから何かを考える動くという動機よりも動きやすいだろう。
慣性の法則とは逆で、動いている物体は常に動き続ける。
そこで今まさに稼働しているプロダクト・プロジェクトのプロセスに組み込むことが一番勢いをつけることに効果的なようだ。
デザインシステムに勢いをつける方法は、実際に進行中のプロダクトと直接連携すること。
実際に稼働してるプロダクトで作り上げるほうが必要なパーツやパターンの解像度は高く、利用者が必要としているものがつかみやすいということだ。
必要なコンポーネントの洗い出すのも、想定されるケースが掴みづらい。やはり実際のプロダクトで作り上げていくほうが繋がりも強くなると感じた。
参考文献
本書で紹介されている書籍が載っていたので、いつか読みたいと思っている。
CMS開発においても必要な部分であるし、プロダクト開発でも情報設計は必要になってくる。
個人的に情報設計はドメイン知識も必要だと思っている。
本書はデザインシステムではあるが、情報設計において一番見せたいものは何か？顧客やユーザが必要な要素とは何か？を理解して落とし込まなければならない。かっこいいとかキレイといった見た目だけがデザインではないとい。必要な情報を的確に落とし込める能力が求めれれる。
なんとか思考という本はたくさんありますが、デザイン思考という考え方は学んでおきたい。欲しいものリストには入ってるがいつかは読みたいと思ってる。
監訳された 長谷川恭久さんのブログ記事も合わせて読むと入りやすいかったです。
まとめ
ざっと読んだところでの感想としては、何度も読み返したい部分は多かった。
とくに実践してみたいと思ったホットポテトプロセスは、デザイナーとエンジニアがタックを組んでやる会社では効果は得られるのではないだろうか。
デザイナーから手離れしたデザインをエンジニアが組むワークフローではなく、ドライバー（コードを書く）とエンジニアが進めながら、ときにナビゲート（デザイン的な指示）をデザイナーがしつつデザインシステムを作り上げるようなワークフローは有効的ではないかと思う。
最後に、監訳された 長谷川恭久さん が xで本書についての解説されたスペースが配信されていました。
録音されているため、合わせて聞いておくとさらに本書の理解が深まると思います。次回も配信があったら自分も聞きたいと思っています。
— ヤスヒサ 🗑 (@yhassy) September 6, 2024
この記事が気に入ったらサポートをしてみませんか？