MUIをベースにしたデザインシステムの構築

Transcript

1. MUIをベースにした
   デザインシステムの構築
   CTOA若手エンジニアコミュニティ 勉強会#1
   

   View Slide

2. 自己紹介
   早瀬和輝
   ◦ 2021年4月 BuySell Technologies入社
   ◦ フロントエンドエンジニア
   ◦ React / TypeScript / Go / GraphQL / Hasura
   ◦ Zenn: kazu777
   ◦ 趣味：マンガ、アニメ、開発、旅行
   2
   

   View Slide

3. アジェンダ
   ◦ 背景
   ◦ MUIとは
   ◦ デザインシステムを導入する目的
   ◦ 具体的な取り組み
   ◦ おわりに
   3
   

   View Slide

4. 背景
   1
   4
   

   View Slide

5. 背景
   リユースプラットフォームを開発中
   5
   

   View Slide

6. 背景
   ◦ 各サービスごとに開発チームが存在
   ◦ サービス間でUI・UXを統一する必要がある
   ◦ プラットフォーム全体のデザインシステムはない
   作りたい気持ちはあるが開発コストが大きい
   全体のデザインシステムの構築はもう少し未来の話
   6
   

   View Slide

7. 背景
   チーム間で共通のコンポーネントライブラリを
   使用することで、UI・UXの統一を図る
   その他のルールや開発は基本的に各チームに委ねる
   7
   ※今回紹介するのは自分が所属するチーム内のデザインシステムについてであり、
   プラットフォーム全体のデザインシステムについてではないです
   

   View Slide

8. MUIとは
   2
   8
   

   View Slide

9. MUIとは
   ◦ React用のコンポーネントライブラリ
   ◦ Github stars 84.1k（2023/01/21時点）
   ◦ かなり多い種類のコンポーネントを提供
   9
   

   View Slide

10. MUIとは
    10
    https://mui.com
    

    View Slide

11. MUIを選択した理由
    ◦ コンポーネントが豊富
    ◦ デザインがカスタマイズしやすい
    ◦ Figmaが提供されている
    11
    

    View Slide

12. デザインシステムを導入する目的
    3
    12
    

    View Slide

13. デザインと実装の同期
    ◦ 変更の反映をしやすくする
    ◦ 運用コストは極力抑える
    属人性の排除
    ◦ 特定の実装者に依存しない
    ◦ 実装者による差異を減らす
    ◦ レビューコストの削減
    デザインシステムを導入する目的
    13
    

    View Slide

14. 具体的な取り組み
    4
    14
    

    View Slide

15. 具体的な取り組み
    ◦ カラーコードの集約
    ◦ デフォルトスタイルのオーバーライド
    ◦ Typographyの定義
    ◦ Atomic Designの不採用
    15
    

    View Slide

16. 具体的な取り組み
    ◦ カラーコードの集約
    ◦ デフォルトスタイルのオーバーライド
    ◦ Typographyの定義
    ◦ Atomic Designの不採用
    16
    

    View Slide

17. カラーコードの集約
    カラーコードをピックアップして名前を付け、
    定数として定義
    17
    Figma src/styles/theme.ts
    

    View Slide

18. カラーコードの集約
    コンポーネント側で指定する際は定数を使用
    カラーコードが氾濫せず、型安全に実装できる
    18
    

    View Slide

19. 具体的な取り組み
    ◦ カラーコードの集約
    ◦ デフォルトスタイルのオーバーライド
    ◦ Typographyの定義
    ◦ Atomic Designの不採用
    19
    

    View Slide

20. デフォルトスタイルのオーバーライド
    オーバーライドしたい場合はトップレベルで指定
    20
    

    View Slide

21. 具体的な取り組み
    ◦ カラーコードの集約
    ◦ デフォルトスタイルのオーバーライド
    ◦ Typographyの定義
    ◦ Atomic Designの不採用
    21
    

    View Slide

22. Typographyの定義
    fontSizeやfontWeightは使用するものを厳選
    22
    

    View Slide

23. Typographyの定義
    sizeとweightをconst assertionで定義して、
    それらをPropsで受け取るコンポーネントを作成
    23
    

    View Slide

24. Typographyの定義
    MUIのTypographyのimportをeslintで禁止して、
    独自定義のTypographyのみ使用する
    予期しないsize, weightが使用されることがなくなる
    24
    

    View Slide

25. 具体的な取り組み
    ◦ カラーコードの集約
    ◦ デフォルトスタイルのオーバーライド
    ◦ Typographyの定義
    ◦ Atomic Designの不採用
    25
    

    View Slide

26. Atomic Designに感じていた課題から不採用
    ◦ Organismsの肥大化
    ◦ コンポーネント設計の難しさ
    Atomic Designの不採用
    26
    

    View Slide

27. ざっくりとしたディレクトリ構成
    コンポーネントの分類はシンプルにする
    Atomic Designの不採用
    27
    

    View Slide

28. コンポーネントの設計に悩む場面が少なくなる
    Atomic Designの不採用
    28
    アプリケーション共通で使用する
    src/components src/features/*/components
    Yes No
    

    View Slide

29. おわりに
    5
    29
    

    View Slide

30. おわりに
    ◦ MUIをベースにすることで、
    低コストでデザインシステムを構築できた
    ◦ デザインシステムの導入目的も達成できている
    デザインとの同期には、ほぼコストがかかってない
    チーム全員でフロントエンドの開発に取り組めている
    30
    

    View Slide