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
MUIをベースにしたデザインシステムの構築
Search
KazukiHayase
January 27, 2023
Technology
0
360
MUIをベースにしたデザインシステムの構築
KazukiHayase
January 27, 2023
Tweet
Share
More Decks by KazukiHayase
See All by KazukiHayase
Goでテストをしやすくするためにやったこと
kazukihayase
1
610
GraphQLクライアントの技術選定 2023冬
kazukihayase
8
5.3k
Introduction and Insights of the Hasura-based Architecture
kazukihayase
0
730
自分だけが頑張るのをやめて、フルスタックなチームを作る
kazukihayase
2
2k
Goでテンプレートからファイルを自動生成するCLIを作る
kazukihayase
0
720
生産性が上がり続けるチームを作るための第一歩
kazukihayase
4
3.5k
GraphQLにおけるクライアントキャッシュ戦略
kazukihayase
0
2.3k
Hasuraを活用するためのTips集
kazukihayase
0
31k
ReactとGraphQLで実現する宣言的データフェッチ
kazukihayase
2
2.7k
Other Decks in Technology
See All in Technology
AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege
opelab
10
4.4k
Flutter研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
160
Luupの開発組織におけるインシデントマネジメントの変遷 ver.RoadtoSRENEXT2024
grimoh
1
270
年間一億円削減した時系列データベースのアーキテクチャ改善~不確実性の高いプロジェクトへの挑戦~
lycorptech_jp
PRO
3
2.9k
コミュニティサービスに「あなたへ」フィードを リリースするまでの試行錯誤
takapy
1
150
Datadog Cloud SIEMを使ってAWS環境の脅威を可視化した話/lifeistech-datadog-cloud-siem
gidajun
0
480
公共領域から学ぶ クラウド移行についてエンジニアが意識していること
kawakawa2222
0
140
Git 研修 Advanced【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
200
20240724_cm_odyssey_hibiyatech
hiashisan
0
110
推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事例を元に~
morinota
0
130
プレイドにおけるDatadog APMの活用方法
plaidtech
PRO
2
120
[NIKKEI Tech Talk]Bias for Action!! 実践から学ぶための仕組とコミュニティ / Community for Practice and Learning
kanamasa
0
280
Featured
See All Featured
It's Worth the Effort
3n
181
27k
Learning to Love Humans: Emotional Interface Design
aarron
269
39k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
129
32k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
26
2.1k
Adopting Sorbet at Scale
ufuk
71
8.8k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
78
15k
Agile that works and the tools we love
rasmusluckow
325
20k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
34
1.9k
Music & Morning Musume
bryan
43
5.9k
Principles of Awesome APIs and How to Build Them.
keavy
124
16k
Into the Great Unknown - MozCon
thekraken
20
1.3k
Transcript
MUIをベースにした デザインシステムの構築 CTOA若手エンジニアコミュニティ 勉強会#1
自己紹介 早瀬和輝 ◦ 2021年4月 BuySell Technologies入社 ◦ フロントエンドエンジニア ◦ React
/ TypeScript / Go / GraphQL / Hasura ◦ Zenn: kazu777 ◦ 趣味:マンガ、アニメ、開発、旅行 2
アジェンダ ◦ 背景 ◦ MUIとは ◦ デザインシステムを導入する目的 ◦ 具体的な取り組み ◦
おわりに 3
背景 1 4
背景 リユースプラットフォームを開発中 5
背景 ◦ 各サービスごとに開発チームが存在 ◦ サービス間でUI・UXを統一する必要がある ◦ プラットフォーム全体のデザインシステムはない 作りたい気持ちはあるが開発コストが大きい 全体のデザインシステムの構築はもう少し未来の話 6
背景 チーム間で共通のコンポーネントライブラリを 使用することで、UI・UXの統一を図る その他のルールや開発は基本的に各チームに委ねる 7 ※今回紹介するのは自分が所属するチーム内のデザインシステムについてであり、 プラットフォーム全体のデザインシステムについてではないです
MUIとは 2 8
MUIとは ◦ React用のコンポーネントライブラリ ◦ Github stars 84.1k(2023/01/21時点) ◦ かなり多い種類のコンポーネントを提供 9
MUIとは 10 https://mui.com
MUIを選択した理由 ◦ コンポーネントが豊富 ◦ デザインがカスタマイズしやすい ◦ Figmaが提供されている 11
デザインシステムを導入する目的 3 12
デザインと実装の同期 ◦ 変更の反映をしやすくする ◦ 運用コストは極力抑える 属人性の排除 ◦ 特定の実装者に依存しない ◦ 実装者による差異を減らす
◦ レビューコストの削減 デザインシステムを導入する目的 13
具体的な取り組み 4 14
具体的な取り組み ◦ カラーコードの集約 ◦ デフォルトスタイルのオーバーライド ◦ Typographyの定義 ◦ Atomic Designの不採用
15
具体的な取り組み ◦ カラーコードの集約 ◦ デフォルトスタイルのオーバーライド ◦ Typographyの定義 ◦ Atomic Designの不採用
16
カラーコードの集約 カラーコードをピックアップして名前を付け、 定数として定義 17 Figma src/styles/theme.ts
カラーコードの集約 コンポーネント側で指定する際は定数を使用 カラーコードが氾濫せず、型安全に実装できる 18
具体的な取り組み ◦ カラーコードの集約 ◦ デフォルトスタイルのオーバーライド ◦ Typographyの定義 ◦ Atomic Designの不採用
19
デフォルトスタイルのオーバーライド オーバーライドしたい場合はトップレベルで指定 20
具体的な取り組み ◦ カラーコードの集約 ◦ デフォルトスタイルのオーバーライド ◦ Typographyの定義 ◦ Atomic Designの不採用
21
Typographyの定義 fontSizeやfontWeightは使用するものを厳選 22
Typographyの定義 sizeとweightをconst assertionで定義して、 それらをPropsで受け取るコンポーネントを作成 23
Typographyの定義 MUIのTypographyのimportをeslintで禁止して、 独自定義のTypographyのみ使用する 予期しないsize, weightが使用されることがなくなる 24
具体的な取り組み ◦ カラーコードの集約 ◦ デフォルトスタイルのオーバーライド ◦ Typographyの定義 ◦ Atomic Designの不採用
25
Atomic Designに感じていた課題から不採用 ◦ Organismsの肥大化 ◦ コンポーネント設計の難しさ Atomic Designの不採用 26
ざっくりとしたディレクトリ構成 コンポーネントの分類はシンプルにする Atomic Designの不採用 27
コンポーネントの設計に悩む場面が少なくなる Atomic Designの不採用 28 アプリケーション共通で使用する src/components src/features/*/components Yes No
おわりに 5 29
おわりに ◦ MUIをベースにすることで、 低コストでデザインシステムを構築できた ◦ デザインシステムの導入目的も達成できている デザインとの同期には、ほぼコストがかかってない チーム全員でフロントエンドの開発に取り組めている 30