Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Cd7da48d7d9d03d2b9a84d702694e6d3?s=47 Nobuyuki OSAWA
October 16, 2019

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

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

Cd7da48d7d9d03d2b9a84d702694e6d3?s=128

Nobuyuki OSAWA

October 16, 2019
Tweet

Other Decks in Design

Transcript

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

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


    いま話している人
  3. DIGGLE 株式会社
 B2B向け管理会計のため予実管理SaaS.
 
 一言で言うと「脱Excel」
 https://diggle.jp/
 
 バックエンド: Rails
 フロント:

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

  5. None
  6. None
  7. None
  8. None
  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. ありがとうございました