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

以下のイベントでLTした時のスライドです。
https://coralcapital.connpass.com/event/148183/

Transcript

1. PMFに役立つ リーンなデザインシステムを構 築する
2. - DIGGLEのフロントエンドエンジニア
 - フロントエンドという名前がない時代からフロントエンド エンジニア（JS11年、CSS14年）
 - 直近の何社かではプロダクトマネージャーもやってまし た
 - UI設計からSPA実装までが担当
 いま話している人
3. DIGGLE 株式会社
 B2B向け管理会計のため予実管理SaaS.
 
 一言で言うと「脱Excel」
 https://diggle.jp/
 
 バックエンド: Rails
 フロント: React/ReduxによるSPA
 DIGGLEのご紹介
4. - レイアウトから小さいコンポーネントまで幅広く活用
 - アプリケーションに十分浸透している
 - 開発メンバーにも浸透している
 デザインシステムが活躍しています
9. 過去数社で似た仕組みを 作ろうと試みてきたが ことごとく失敗してきた
10. なぜうまくいったのか？
11. - どうやって失敗を乗り越え、機能するデザインシステムを作れ るようになるのか？
 - その秘訣
 - やったこと
 今日話すこと
12. デザインシステムを作る理由 UI構築の手間が省ける 仮説検証に力を注げる PMFする
13. - 当時デザイナーはいなかった（2年前）
 - ブランドガイドラインやスタイルガイドラインが欲しかったが作 りようがなかった
 作るための制約
14. いずれ来るデザイナーのために ガワだけ準備だけしておこう
15. 大成功！
16. なぜなのか
17. 1. 独自にデザインシステムを定義していた
 2. MVPから始めていた
 3. 独自スタイル構築よりも浸透を優先していた
 何をやったのか
18. 独自の定義を考える （自社に最適な解釈）
19. ラクをすればするほど、 自然とデザインの一貫性が 保たれる仕組み
20. デザインシステムが機能する =少しずつ一貫性が向上する 一貫性を保てている割合 製品
21. - デザインシステムは夢を詰め込みやすい
 - その結果必要なリソースが肥大化してしまう
 - 現状の主要目標はPMF
 - 仮説検証のしやすさが重要
 - 一貫性さえ保てれば少なくとも仮説検証の邪魔しない
 一貫性に主軸を置く理由
22. ラクできると気付けば自然と デザインシステムをプルするはず （社内PMF）
23. - チャットボット経由で本番などにデプロイできる仕組み
 - あまりにも簡単、ラク
 - これの導入後に理由もなく以前のデプロイ方法を選択する人 はほぼ見かけない
 - デプロイオペレーションの自動化に寄与
 - ヒューマンエラー防止
 成功例としてのChatBotによるデプロイ (ChatOps)
24. MVPから始める
25. デザインシステムがエンジニアに届くまでの階 層 ブ ラ ン ド ガ イ ド ラ イ ン ス タ イ ル ガ イ ド ラ イ ン コ ン ポ ｜ ネ ン ト デザインシステムがエンジニアに届くまで エンジニア 遠い。めんどい。 距離 ボトルネック
26. デザインシステムがエンジニアに届くまでの階 層 ブ ラ ン ド ガ イ ド ラ イ ン ス タ イ ル ガ イ ド ラ イ ン コ ン ポ ｜ ネ ン ト すぐ使える状況にする必要ある エンジニア 出来そう！ パ ッ ケ | ジ イ ン ス ト | ル ド キ ュ メ ン ト チ ュ | ト リ ア ル
27. - 独自スタイルガイドラインは無し
 - スタイルとコンポーネントはOSS製をそのまま使う
 - ドキュメントがそのまま使える
 - 名前だけ変えた薄いラッパー
 - 動作確認用にstorybook入れる
 - packageにして提供
 - 最初はgithubにbuild済みコードを入れて本体に取り込むだけ
 DIGGLEでやったこと
28. デザインシステムがエンジニアに届くまでの階 層 ブ ラ ン ド ガ イ ド ラ イ ン ス タ イ ル ガ イ ド ラ イ ン コ ン ポ ｜ ネ ン ト 可能な限り薄く＆最後まで用意する エンジニア まあまあ便利 パ ッ ケ | ジ イ ン ス ト | ル ド キ ュ メ ン ト チ ュ | ト リ ア ル
29. https://www.ryuzee.com/contents/blog/2985 イテレーティブ
30. 浸透を優先する （独自スタイルの構築は後）
31. - デザインシステム由来のコンポーネントでアプリケーション側 を満たす
 - 十分に浸透すると、UIの大部分をデザインシステム側の改修 で対応できるようになる
 - 新規メンバーは自然とデザインシステムを活用する
 （すでに利用されているコードをあちこちで見るため）
 浸透？
32. 1. 影響範囲の小さいものから置き換える（少しずつ）
 2. レイアウト周りを置き換える（一気にやる）
 3. 独自コンポーネントを作成する
 4. ブランド/スタイルガイドラインに備える
 5. 各ガイドライン策定中 <- イマココ
 6. ガイドラインを元に独自スタイルに置き換えていく
 ステップ
33. 小さいパーツの置き換えは まだ様子見にすぎない
34. レイアウト周りを置き換えて初めて 大きな効果が出てくる （デザインシステムが機能し始める）
35. - レイアウトがデザインシステム側のコードに置き換わると、レ イアウト以下に（CSS的に）影響を及ぼす
 - 全ての画面にレイアウトが存在するはずなので、開発メン バーは改修時に必ずデザインシステムのコードに触れること になる
 - そういうものだという思わせる効果がある
 その理由
36. 時が来れば独自スタイルへの 置換も可能になる
37. まとめ
38. 1. 夢を詰め込みすぎず、目的を絞ろう
 2. オリジナル要素ゼロでも良いから最小限で始めよう
 3. アプリケーションにデザインシステムを浸透させることを最優 先しよう
 まとめ
39. DIGGLE エンジニア・デザイナー 募集中
40. ありがとうございました