[2023.06.17] うちのデザインシステム

Slide 1

Slide 1 text

うちのデザインシステム  NewsPicks Web Engineer / イイダユカコ  2023.6.17@デザインシステムの話☕ 

Slide 2

Slide 2 text

01  自己紹介  ©NewsPicks Inc. All Rights Reserved.  イイダユカコ  NewsPicks Web エンジニア    経歴  2013年に株式会社サイバーエージェントに入社し、サーバサイドエンジニアを経て、2015年よりフロントエンドエンジニアとして従事。 2019年9月より株式会社ニューズピックスにて、 Web フロントエンドをメインに担当。現在はニューズピックスの Web プロダクトに関するリアーキテクチャプロジェクトとリニューアルプロジェクトに携わる。   推進する中で Observability や Accessibility などの普及を図っています。     気になってくれたら Twitter で @becyn で見てもらえるとうれしいです！   いつものやつ 

Slide 3

Slide 3 text

Slide 4

Slide 4 text

1. デザインシステムってなんっけ？  2. NewsPicks におけるデザインシステム  a. 期待値＆立ち位置  b. アウトプット＆管理方法  c. 具体的な開発フロー  3. で、デザインシステムやったほうがいいの？  00  本日お話すること 

Slide 5

Slide 5 text

Slide 6

Slide 6 text

01  デザインシステムってなんっけ？  一貫したデザインや操作性でウェブサイトやアプリを提供するための仕組み   デジタル庁  デジタル庁のデザインシステムは以下で確認できるよ！   ググってもすぐ出てくる、必読サイト 💪    https://www.digital.go.jp/policies/servicedesign/designsystem/  

Slide 7

Slide 7 text

● 昨今数多くの企業やサービスがデザインシステムづくりを行っている、大デザインシステム時代     ● 多くのデザインシステムが公開され、自社のブランディングとして扱われるケースもある 👀  ○ イケてる企業にみんな就職したいし、その分野に没頭できるという環境を暗に示せてるしね  01  デザインシステムってなんっけ？ 

Slide 8

Slide 8 text

● 昨今数多くの企業やサービスがデザインシステムづくりを行っている、大デザインシステム時代     ● 多くのデザインシステムが公開され、自社のブランディングとして扱われるケースもある 👀  ○ イケてる企業にみんな就職したいし、その分野に没頭できるという環境を暗に示せてるしね  01  デザインシステムってなんっけ？  おい、待て！！  かっこいいだけ  かよ！！！！！ 

Slide 9

Slide 9 text

Slide 10

Slide 10 text

● サービス内操作の一貫性向上   ○ 限られた component しか使用されなくなるため、自然と操作の種類が絞られる  ○ 結果「XX (サービス名) ぽい動き」「XX だとこう動く」を  ユーザーに理解してもらいやすいように、愛着がわく（わかれる）サービスに  01  デザインシステムに何を期待してるん？（サービスにとって）  よく勉強会とかで見る、 UXのハニカム構造をピラミッド図にしたやつ  

Slide 11

Slide 11 text

● サービス内の操作性の一貫性向上   ○ 限られた component しか使用されなくなるため、自然と操作の種類が絞られる  ○ 結果「XX (サービス名) ぽい動き」「XX だとこう動く」を  ユーザーに理解してもらいやすいように、愛着がわく（わかれる）サービスに    ● 「自分たちの色」を自分たちで認識する、意識する、プロダクトに還す   ○ 知見やこれまでの判断が積み重なることで、迷ったときの判断材料にもなる  ○ DNA を継承し続けることでどんどん「自分たちの色」を濃くすることに繋がる  01  デザインシステムに何を期待してるん？（サービスにとって） 

Slide 12

Slide 12 text

● デザインの作業効率の向上   ○ 使い回し前提でデザインするよう意識するのでデザイン量産を抑えられる（工数節約！）  ○ 自然と 1 component に対して汎用的に作ろうという意識が働き、  全体で扱う component 数が減る（メンテナンス軽減！）    ● 開発の作業効率の向上   ○ product 内で使用する component を絞ることで使い回しができるようになる    ● 「よくわかんないけど、これ使えば作れる」を仕組み化   ○ デザイナーにとってもエンジニアにとっても「わからんが OK」を実現  ○ 特にアクセシビリティ等一定理解がむずかしいものを扱う事例も目立つよね  01  デザインシステムに何を期待してるん？（現場にとって） 

Slide 13

Slide 13 text

Slide 14

Slide 14 text

● 会社やチームによって、デザインシステムに求めることは違っているし、アウトプットも違う   ○ 例えば、  ■ プロダクトのデザインの統一感を見せたい  ■ 自社のブランドを表現したい  ■ デザイン工数、開発工数を下げたい  ■ 全体のデザインに関する仕様を一覧して理解を深めたい  ■ 新しく入ったメンバーへのオンボーディング資料としたい    ● これらを解決するため「デザインシステム」になったり、ならなかったりする   ○ それは会社やチームの判断によるとしか言えないし、正解はないところ  01  デザインシステムに何を期待してるん？（多種多様編） 

Slide 15

Slide 15 text

書籍『ちいさくはじめるデザインシステム』     ● 日本でデザインシステムに力を入れている  名だたる Web 企業のアンケート調査がまとまってる  ○ SmartHR、CyberAgent、freee、デジタル庁、Ubie、など  ● 一回の飲み会代より安い値段 (¥2,860) でここまでまとまってて、  最後の章だけで、まじでペイする。飲み代浮いた。  ● 答えは一つじゃないと教えてくれる、  始める前に読みたい、まじで推薦できる指南書な一冊  01  デザインシステムに何を期待してるん？（多種多様編）  https://amzn.asia/d/ixLqzvW  

Slide 16

Slide 16 text

書籍『ちいさくはじめるデザインシステム』     ● ちなみにこの本で取り扱ってる「デザインシステム」は、  ロゴ、文章、印刷ガイドライン、イラストレーションなど  Web におけるデザインシステムから更に一歩踏み込んだ内容に  なっているので、そちらも気になる方には是非お手にとってみて！  01  デザインシステムに何を期待してるん？（多種多様編）  https://amzn.asia/d/ixLqzvW  

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

● 2013年9月  ○ NewsPicks（サービス）サービス提供を開始、翌年2014年6月より Web サービスの提供を開始  2019年9月私、入社。当時は、NewsPicks ではない新規プロジェクトに配属  ● 2021年7月  ○ NewsPicks のややレガシーな技術スタックを見た上で、技術刷新を提案し、  ついに Web Product を page 毎に技術刷新開始（リアーキテクチャ Project）🎉  ● 2022年  ○ 上記の流れにデザイナーチームが乗ってくれて、デザイン刷新も推進（リニューアル Project）が始動 🎉  ○ この流れで「デザインシステム project」が同時始動 🎉  02  NewsPicks におけるデザインシステム（誕生秘話） 

Slide 21

Slide 21 text

デザインシステムのきっかけになった「リニューアル Project」ってなに？  ● 既存の機能を据え置きに、全体デザインがガッツリ変わる（作り直しのイメージに近い）   ○ エンジニアもデザイナーも超ヘビーな作業。超覚悟必要。ものによっては 5年計画。  ● リニューアルを page 毎に進めていく中で、定義していく component も整理  ● すべてのページをリニューアルする前提だったので、全ページに適応すべく、   デザイントークンを見直し、デザインシステムまで昇華させ、育てていくことに！   >　2022年より、並行して page 毎のデザイン刷新も推進（リニューアル Project）  02  NewsPicks におけるデザインシステム（誕生秘話） 

Slide 22

Slide 22 text

Slide 23

Slide 23 text

02.a  ● デザイン工数の低減、開発工数の低減   ○ 全体工数を下げ、素早く技術刷新＆デザインリニューアルを完了させたい  ○ デザイン知識の継承をデザイナー、エンジニア、両方に残していきたい    ● Web におけるアクセシビリティを向上   ○ ある程度知識がないと難しいアクセシビリティの知識を包括したデザインシステム上の component を使うだけで開発に関わる全てのメンバーがアクセシブルな実装を可能にできる    ● Unit 外開発メンバーが Web 開発に参加する時の心理的ハードルを低減   ○ NewsPicks の開発組織の構造上、開発者は普段 Web フロントエンドを触ってる人に限らない  ■ いわゆるフルスタックエンジニア組織  ○ ドキュメントの充実、ある程度「これ使えば OK」っていうのを用意したかった  NewsPicks における期待値 

Slide 24

Slide 24 text

● 少なくとも、Web のリニューアル＆技術刷新が終わるまで＆   今の組織構造が変わる（ Web の開発が特定の Unit に限定する）まではデザインシステムを   育て続ける意義があると考えられる   ● そのため、開発を進めていく中で、通常の page 開発だけでなく、  ○ デザインシステムドキュメントの更新   ○ デザインシステムドキュメントに沿った component 実装の追加実装  などを行いながら、じっくり育てていく必要がある   02.a  NewsPicks における立ち位置  以上のことから、「デザインシステムを始めると、それ以降のデザイン /開発更新時の毎度、   デザインシステム側のメンテナンスが必要化かチェックする必要がある」といえる  

Slide 25

Slide 25 text

Slide 26

Slide 26 text

● 3つの資料に分けて管理   ○ 資料に応じて、メインの管理者（メンテナー）が違っている  ○ それぞれに対してお互いに声を掛け合ってメンテナンスを促している状態（持ちつ持たれつ）  02.b  NewsPicks における、アウトプット＆管理方法  Web アクセシビリティガイドライン  デザインシステムドキュメント  component 集  エンジニア管轄  （本当はもっと広めたい）   デザイナー管轄  エンジニア管轄  どういった概念かを定義   👈の概念をどう実装し使用できるかを提示   👈の中の特定分野で何に気をつけているか説明  

Slide 27

Slide 27 text

● 全ての component デザインシステム化されているわけではない   ○ 現在は、サイト横断で使用されるもの、積極的に意識してデザインに組み込みたいものが対象  ■ 例: News を表示する component 、サイト全体で使用されるボタン component  02.b  NewsPicks における、アウトプット＆管理方法  そろそろイメージわかせたいと思うので、ちょっとだけ画面共有するね 🤫 

Slide 28

Slide 28 text

Slide 29

Slide 29 text

02.c  NewsPicks における、具体的な開発フロー  ある日の開発風景  デザイナー  エンジニア 

Slide 30

Slide 30 text

02.c  NewsPicks における、具体的な開発フロー  デザイナー  デザインできました！おけ！レビューしまーす！これ、デザインシステムで定義された   この component 使えないですかね？   デザイナーチーム  これ、デザインシステムで定義された   この component を調整した形でいけない？   デザインできました！デザインシステムドキュメント側も   一緒に更新しときます！デザイナー 

Slide 31

Slide 31 text

02.c  NewsPicks における、具体的な開発フロー  ありがとうございますー！エンジニア  デザイナー  デザインできました！デザインできました！仕様共有します！   デザイナー  今回の仕様でデザインシステム   ドキュメント側も更新しました！   実装の際に component 集も  更新お願いします！   承知の助！エンジニア 

Slide 32

Slide 32 text

02.c  NewsPicks における、具体的な開発フロー  ありがとうございますー！   あ、これ、デザインシステム側の   この component で代えてもいいですか？   エンジニア  デザイナー  デザインできました！デザインできました！仕様共有します！   デザイナー  あー、たしかに工夫できそうですね。   これでいきましょう！   新しい見せ方だと思うのでドキュメント更新   しておきますねー！   承知の助！component 集も更新する！エンジニア 

Slide 33

Slide 33 text

02.c  NewsPicks における、具体的な開発フロー  ありがとうございますー！   あ、これ、アクセシビリティ的にちょっと   工夫したほうが良いかも！   エンジニア  デザイナー  デザインできました！デザインできました！仕様共有します！   デザイナー  あー、たしかに。  背景色を調整して…うん、良さそうです！   これ、他でも使うと思うので、   デザインシステムで管理したいです！   承知の助！  component 集側にも新しく追加します！   エンジニア 

Slide 34

Slide 34 text

02.c  NewsPicks における、具体的な開発フロー  デザイナー  エンジニア 

Slide 35

Slide 35 text

Slide 36

Slide 36 text

05  デザインシステムやったほうがいいの？  ● GOOD  ○ ドキュメントを普段から整理しようという気持ちになり、仕様書の健全化に繋がっている  ○ うちは組織構造上相性がよく、オンボーディング資料にもなりいい感じ    ● MORE  ○ それでもやっぱり忙しい時は更新作業の手が止まっちゃう！  ■ タスク優先度の見直し、管理工数も考えないと事故る 

Slide 37

Slide 37 text

05  ● 組織でも、チームでも多種多様、サービスの数だけデザインシステムの形は違う   ○ まずは、デザインシステムに何を期待しているのかチームや組織で話し合おう  ○ 「何を解決したいか」に向き合って、デザインシステムが有効そうならやってもいいかも    ● 解決方法が沢山ある中で、なぜデザインシステムなのかを人に話せるか   ○ プロダクト全体の仕様策定/デザイン/開発効率が上がったり、  チームの誰かが救われる未来があるならやってもいいかも！  ○ ちょっとキツそうな例  ■ かっこいいしイケてる企業風だから、運用経験を経歴書に書きたいから    ● 運用できる組織構造や周囲の理解があることが大前提   ○ 作ったけど「（メンテ大変すぎて）作って終わった」になりがち（実際に見た）  ○ 「あいつら作りたいから作ってるだけ」となるとキツイ（実際に見た）  デザインシステムやったほうがいいの？  サービスや組織課題に   向き合うのじゃ…  絶対に、じゃ… 

Slide 38

Slide 38 text

Slide 39

Slide 39 text

● デザインシステムについて、事例を交えながらざっくりお伝えしました！   ○ 実践的な話（どこから始めたらいい？等）はまた別の機会に！   ■ それはそれで話したいことが沢山ある！！笑   ○ これも一例でしかないので偏りはありますが …（なので、そのつもりで持ち帰ってくださいｗ）   ○ 今後いろんなデザインシステムを見かける際   「このデザインシステムは何に特化したデザインシステムだ？」等面白がる機会に繋がればうれしいです！     ● デザインシステムする /しないも論点ではあるが、   一番大事なのはプロダクトや組織課題と向き合うこと   ○ 向き合った結果のアウトプットがデザインシステムになったりならなかったりしてるだけ     ● デザインシステムをやるなら、相当な覚悟が必要   ○ （だと思ってる）  ○ デザインシステム始めたら、見せあいっ子しましょ！！   00  本日のまとめ 

Slide 40

Slide 40 text

Slide 41

Slide 41 text

最初からガチガチではなく、ゆっくりプロダクトを作りながら成長させていくイメージが近い   個人の感想です！  途中デザインも仕様も変わるし、最初にガチッとは難しそう。   デザインシステムとプロダクトを一緒に成長させていくイメージ。   （なので、プロダクトが成長する限り、デザインシステムも成長するのです …終わりのない戦いのようにも感じる …！！笑）  ©NewsPicks Inc. All Rights Reserved.  Q. 最初からガチガチに作るとデザインやりにくすぎるし   結局途中で変えるとこ多いけど、みんなどうゆう順序でやってるのか気になる   ともや氏 

Slide 42

Slide 42 text

©NewsPicks Inc. All Rights Reserved.  Q. デザインする前からデザインシステム作らんよね？そんなことできんよね？   ともや氏  ある程度どんな layout/component が必要かわかってないと厳しそう   一気につくるというより、プロダクトと一緒に成長させる方が手戻りも少なくいいと思う   実際にプロダクトに反映した時に無理のないシステムになってるかどうか確認しながら作ったほうが   よりプロダクトにフィットしたデザインシステムになるんじゃないかと思う！   （すげえ敏腕デザイナーとかだったら違うんかな？ｗいずれにせよ神業だと思うｗ）  

Slide 43

Slide 43 text

©NewsPicks Inc. All Rights Reserved.  Q. デザインシステムとデザインルールの違いの説明からあっても良いかと思ったりしました 󰢦  ごとうみな  デザインルールは「白って 200色あんねん」を防止する方法   デザインガイドラインは「この白を使う理由」を説明する場所   デザインシステムは「この白ってあのサービスの白だよね！」と思わせる方法   ちなみに、デザインシステムの中に「デザイントークン」と呼ばれるものもあり、   ルールをシステムに組み込んだ形だと個人的には思ってる！   アンミカ様の画像をここに貼ってましたが   アップロード用にいらすとやのお姉さんに   代理で出てもらってます（跡地）  

Slide 44

Slide 44 text

● 「デザインルール」に留める   ● 「デザインシステムと呼ばれる XX の部分だけ取り入れる」   など色々ある気がする   結局デザインシステムをやる /やらないって「プロダクトをどう管理していくかの設計」なので、   それに合ったやりかたをしていくのがいいのかなって思う！   ©NewsPicks Inc. All Rights Reserved.  Q. これ系でデザインシステム以外の対応方法って具体的にどんなのがあるん？  