Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PMFに役立つリーンなデザインシステムを構築する
Search
Nobuyuki OSAWA
October 16, 2019
Design
0
460
PMFに役立つリーンなデザインシステムを構築する
以下のイベントでLTした時のスライドです。
https://coralcapital.connpass.com/event/148183/
Nobuyuki OSAWA
October 16, 2019
Tweet
Share
Other Decks in Design
See All in Design
RAKSUL_DESIGN_DECK_20250319
raksulrecruiting
0
390
NAHO SHIMONO_Portfolio2025
nahohphp
0
880
21 Ways to Call American Airlines Customer Care Full Guide USA
americanhub
0
180
Kid Cowboy 103
marilutwin
0
270
Echoes Boomerang
artcloudyu
PRO
0
250
minpaku-community-scrum-patterns
norinity1103
1
120
今日から意識できるアクセシビリティ
fumiko
0
250
マンガで分かるサービスデザインガイドライン
senryakuka
1
900
“使いやすい”が生産性を変える!業務を効率化するためのUX/UI設計ポイント
ncdc
2
420
オープンデータを利用して色々なものを作った話
hjmkth
1
120
AI時代に淘汰されないデザインのしごと
akinen
1
140
オルタナUX | AIで高速化するのもいいけど品質も大事なんじゃない?というお話
iflection
4
1.2k
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Embracing the Ebb and Flow
colly
86
4.7k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
GraphQLとの向き合い方2022年版
quramy
49
14k
For a Future-Friendly Web
brad_frost
179
9.8k
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 エンジニア・デザイナー 募集中
ありがとうございました