PMFに役立つリーンなデザインシステムを構築する

by Nobuyuki OSAWA

Slide 1

Slide 1 text

Slide 2

Slide 2 text

- DIGGLEのフロントエンドエンジニア  - フロントエンドという名前がない時代からフロントエンドエンジニア（JS11年、CSS14年）  - 直近の何社かではプロダクトマネージャーもやってました  - UI設計からSPA実装までが担当  いま話している人

Slide 3

Slide 3 text

DIGGLE 株式会社  B2B向け管理会計のため予実管理SaaS.    一言で言うと「脱Excel」  https://diggle.jp/    バックエンド: Rails  フロント: React/ReduxによるSPA  DIGGLEのご紹介

Slide 4

Slide 4 text

- レイアウトから小さいコンポーネントまで幅広く活用  - アプリケーションに十分浸透している  - 開発メンバーにも浸透している  デザインシステムが活躍しています

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

過去数社で似た仕組みを作ろうと試みてきたがことごとく失敗してきた

Slide 10

Slide 10 text

なぜうまくいったのか？

Slide 11

Slide 11 text

- どうやって失敗を乗り越え、機能するデザインシステムを作れるようになるのか？  - その秘訣  - やったこと  今日話すこと

Slide 12

Slide 12 text

デザインシステムを作る理由 UI構築の手間が省ける仮説検証に力を注げる PMFする

Slide 13

Slide 13 text

- 当時デザイナーはいなかった（2年前）  - ブランドガイドラインやスタイルガイドラインが欲しかったが作りようがなかった  作るための制約

Slide 14

Slide 14 text

いずれ来るデザイナーのためにガワだけ準備だけしておこう

Slide 15

Slide 15 text

大成功！

Slide 16

Slide 16 text

なぜなのか

Slide 17

Slide 17 text

1. 独自にデザインシステムを定義していた  2. MVPから始めていた  3. 独自スタイル構築よりも浸透を優先していた  何をやったのか

Slide 18

Slide 18 text

独自の定義を考える（自社に最適な解釈）

Slide 19

Slide 19 text

ラクをすればするほど、自然とデザインの一貫性が保たれる仕組み

Slide 20

Slide 20 text

デザインシステムが機能する =少しずつ一貫性が向上する一貫性を保てている割合製品

Slide 21

Slide 21 text

- デザインシステムは夢を詰め込みやすい  - その結果必要なリソースが肥大化してしまう  - 現状の主要目標はPMF  - 仮説検証のしやすさが重要  - 一貫性さえ保てれば少なくとも仮説検証の邪魔しない  一貫性に主軸を置く理由

Slide 22

Slide 22 text

ラクできると気付けば自然とデザインシステムをプルするはず（社内PMF）

Slide 23

Slide 23 text

- チャットボット経由で本番などにデプロイできる仕組み  - あまりにも簡単、ラク  - これの導入後に理由もなく以前のデプロイ方法を選択する人はほぼ見かけない  - デプロイオペレーションの自動化に寄与  - ヒューマンエラー防止  成功例としてのChatBotによるデプロイ (ChatOps)

Slide 24

Slide 24 text

MVPから始める

Slide 25

Slide 25 text

デザインシステムがエンジニアに届くまでの階層ブランドガイドラインスタイルガイドラインコンポ｜ネントデザインシステムがエンジニアに届くまでエンジニア遠い。めんどい。距離ボトルネック

Slide 26

Slide 26 text

デザインシステムがエンジニアに届くまでの階層ブランドガイドラインスタイルガイドラインコンポ｜ネントすぐ使える状況にする必要あるエンジニア出来そう！パッケ | ジインスト | ルドキュメントチュ | トリアル

Slide 27

Slide 27 text

- 独自スタイルガイドラインは無し  - スタイルとコンポーネントはOSS製をそのまま使う  - ドキュメントがそのまま使える  - 名前だけ変えた薄いラッパー  - 動作確認用にstorybook入れる  - packageにして提供  - 最初はgithubにbuild済みコードを入れて本体に取り込むだけ  DIGGLEでやったこと

Slide 28

Slide 28 text

デザインシステムがエンジニアに届くまでの階層ブランドガイドラインスタイルガイドラインコンポ｜ネント可能な限り薄く＆最後まで用意するエンジニアまあまあ便利パッケ | ジインスト | ルドキュメントチュ | トリアル

Slide 29

Slide 29 text

https://www.ryuzee.com/contents/blog/2985 イテレーティブ

Slide 30

Slide 30 text

浸透を優先する（独自スタイルの構築は後）

Slide 31

Slide 31 text

- デザインシステム由来のコンポーネントでアプリケーション側を満たす  - 十分に浸透すると、UIの大部分をデザインシステム側の改修で対応できるようになる  - 新規メンバーは自然とデザインシステムを活用する  （すでに利用されているコードをあちこちで見るため）  浸透？

Slide 32

Slide 32 text

1. 影響範囲の小さいものから置き換える（少しずつ）  2. レイアウト周りを置き換える（一気にやる）  3. 独自コンポーネントを作成する  4. ブランド/スタイルガイドラインに備える  5. 各ガイドライン策定中 <- イマココ  6. ガイドラインを元に独自スタイルに置き換えていく  ステップ

Slide 33

Slide 33 text

小さいパーツの置き換えはまだ様子見にすぎない

Slide 34

Slide 34 text

レイアウト周りを置き換えて初めて大きな効果が出てくる（デザインシステムが機能し始める）

Slide 35

Slide 35 text

- レイアウトがデザインシステム側のコードに置き換わると、レイアウト以下に（CSS的に）影響を及ぼす  - 全ての画面にレイアウトが存在するはずなので、開発メンバーは改修時に必ずデザインシステムのコードに触れることになる  - そういうものだという思わせる効果がある  その理由

Slide 36

Slide 36 text

時が来れば独自スタイルへの置換も可能になる

Slide 37

Slide 37 text

まとめ

Slide 38

Slide 38 text

1. 夢を詰め込みすぎず、目的を絞ろう  2. オリジナル要素ゼロでも良いから最小限で始めよう  3. アプリケーションにデザインシステムを浸透させることを最優先しよう  まとめ

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text