Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
PMFに役立つリーンなデザインシステムを構築する
Nobuyuki OSAWA
October 16, 2019
Design
0
340
PMFに役立つリーンなデザインシステムを構築する
以下のイベントでLTした時のスライドです。
https://coralcapital.connpass.com/event/148183/
Nobuyuki OSAWA
October 16, 2019
Tweet
Share
Other Decks in Design
See All in Design
YOUは何しにそのデザインチームへ?【デザインマネージャー編】RAKSUL編
izumi_junichi
1
650
コミュニケーションデザイン組織のタタキ台 - SmartHR Communication Design Group
bebe
8
19k
Омские улицы — 2022
roudakov
0
190
ペルナ
rkinoshi
0
140
「気持ちのよい朝」をつくるデザイン
zhikto
0
140
Memories
honeysink
PRO
0
190
ANTIEK
8sided
PRO
1
210
ブランドイメージを戦略的に浸透させる VI策定プロセス
sevendex
0
150
Doll.pdf
yzhang0425
1
300
あじたま販売株式会社_最終プレゼンテーション
zhikto
0
120
デザイナーからプロダクトマネジメントへの挑戦
fumiko
0
230
Jen Blatz - Keep Cognitive Biases from Creeping into your UX Design and User Research
uxaustralia
PRO
0
120
Featured
See All Featured
Designing Experiences People Love
moore
130
22k
Why Our Code Smells
bkeepers
PRO
324
55k
Gamification - CAS2011
davidbonilla
75
3.9k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
15
980
Fantastic passwords and where to find them - at NoRuKo
philnash
27
1.6k
Testing 201, or: Great Expectations
jmmastey
21
5.5k
Designing the Hi-DPI Web
ddemaree
272
32k
Fashionably flexible responsive web design (full day workshop)
malarkey
396
62k
Large-scale JavaScript Application Architecture
addyosmani
499
110k
Code Reviewing Like a Champion
maltzj
506
37k
Robots, Beer and Maslow
schacon
152
7.1k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
119
28k
Transcript
PMFに役立つ リーンなデザインシステムを構 築する
- DIGGLEのフロントエンドエンジニア - フロントエンドという名前がない時代からフロントエンド エンジニア(JS11年、CSS14年) - 直近の何社かではプロダクトマネージャーもやってまし た - UI設計からSPA実装までが担当
いま話している人
DIGGLE 株式会社 B2B向け管理会計のため予実管理SaaS. 一言で言うと「脱Excel」 https://diggle.jp/ バックエンド: Rails フロント:
React/ReduxによるSPA DIGGLEのご紹介
- レイアウトから小さいコンポーネントまで幅広く活用 - アプリケーションに十分浸透している - 開発メンバーにも浸透している デザインシステムが活躍しています
None
None
None
None
過去数社で似た仕組みを 作ろうと試みてきたが ことごとく失敗してきた
なぜうまくいったのか?
- どうやって失敗を乗り越え、機能するデザインシステムを作れ るようになるのか? - その秘訣 - やったこと 今日話すこと
デザインシステムを作る理由 UI構築の手間が省ける 仮説検証に力を注げる PMFする
- 当時デザイナーはいなかった(2年前) - ブランドガイドラインやスタイルガイドラインが欲しかったが作 りようがなかった 作るための制約
いずれ来るデザイナーのために ガワだけ準備だけしておこう
大成功!
なぜなのか
1. 独自にデザインシステムを定義していた 2. MVPから始めていた 3. 独自スタイル構築よりも浸透を優先していた 何をやったのか
独自の定義を考える (自社に最適な解釈)
ラクをすればするほど、 自然とデザインの一貫性が 保たれる仕組み
デザインシステムが機能する =少しずつ一貫性が向上する 一貫性を保てている割合 製品
- デザインシステムは夢を詰め込みやすい - その結果必要なリソースが肥大化してしまう - 現状の主要目標はPMF - 仮説検証のしやすさが重要 - 一貫性さえ保てれば少なくとも仮説検証の邪魔しない
一貫性に主軸を置く理由
ラクできると気付けば自然と デザインシステムをプルするはず (社内PMF)
- チャットボット経由で本番などにデプロイできる仕組み - あまりにも簡単、ラク - これの導入後に理由もなく以前のデプロイ方法を選択する人 はほぼ見かけない - デプロイオペレーションの自動化に寄与 -
ヒューマンエラー防止 成功例としてのChatBotによるデプロイ (ChatOps)
MVPから始める
デザインシステムがエンジニアに届くまでの階 層 ブ ラ ン ド ガ イ ド ラ
イ ン ス タ イ ル ガ イ ド ラ イ ン コ ン ポ | ネ ン ト デザインシステムがエンジニアに届くまで エンジニア 遠い。めんどい。 距離 ボトルネック
デザインシステムがエンジニアに届くまでの階 層 ブ ラ ン ド ガ イ ド ラ
イ ン ス タ イ ル ガ イ ド ラ イ ン コ ン ポ | ネ ン ト すぐ使える状況にする必要ある エンジニア 出来そう! パ ッ ケ | ジ イ ン ス ト | ル ド キ ュ メ ン ト チ ュ | ト リ ア ル
- 独自スタイルガイドラインは無し - スタイルとコンポーネントはOSS製をそのまま使う - ドキュメントがそのまま使える - 名前だけ変えた薄いラッパー - 動作確認用にstorybook入れる
- packageにして提供 - 最初はgithubにbuild済みコードを入れて本体に取り込むだけ DIGGLEでやったこと
デザインシステムがエンジニアに届くまでの階 層 ブ ラ ン ド ガ イ ド ラ
イ ン ス タ イ ル ガ イ ド ラ イ ン コ ン ポ | ネ ン ト 可能な限り薄く&最後まで用意する エンジニア まあまあ便利 パ ッ ケ | ジ イ ン ス ト | ル ド キ ュ メ ン ト チ ュ | ト リ ア ル
https://www.ryuzee.com/contents/blog/2985 イテレーティブ
浸透を優先する (独自スタイルの構築は後)
- デザインシステム由来のコンポーネントでアプリケーション側 を満たす - 十分に浸透すると、UIの大部分をデザインシステム側の改修 で対応できるようになる - 新規メンバーは自然とデザインシステムを活用する (すでに利用されているコードをあちこちで見るため) 浸透?
1. 影響範囲の小さいものから置き換える(少しずつ) 2. レイアウト周りを置き換える(一気にやる) 3. 独自コンポーネントを作成する 4. ブランド/スタイルガイドラインに備える 5. 各ガイドライン策定中
<- イマココ 6. ガイドラインを元に独自スタイルに置き換えていく ステップ
小さいパーツの置き換えは まだ様子見にすぎない
レイアウト周りを置き換えて初めて 大きな効果が出てくる (デザインシステムが機能し始める)
- レイアウトがデザインシステム側のコードに置き換わると、レ イアウト以下に(CSS的に)影響を及ぼす - 全ての画面にレイアウトが存在するはずなので、開発メン バーは改修時に必ずデザインシステムのコードに触れること になる - そういうものだという思わせる効果がある その理由
時が来れば独自スタイルへの 置換も可能になる
まとめ
1. 夢を詰め込みすぎず、目的を絞ろう 2. オリジナル要素ゼロでも良いから最小限で始めよう 3. アプリケーションにデザインシステムを浸透させることを最優 先しよう まとめ
DIGGLE エンジニア・デザイナー 募集中
ありがとうございました