デザインシステムにおけるコンポーネントライブラリ管理の改善 - enechain Tech Blog

• はじめに
• コンポーネントライブラリ管理の課題
• デザインと実装の乖離
  • 見た目における乖離
  • プロパティの乖離
• コンポーネントやバリエーションの増加による管理の負担
• ガイドラインの浸透
• さいごに

はじめに

enechainプロダクトデザインデスクの伊藤です。現在、私は複数プロダクトのデザインを行いながら、デザインシステムの改善にも携わっています。

今回は、デザインシステムにおけるコンポーネントライブラリの管理と、その改善についてご紹介します。

コンポーネントライブラリ管理の課題

enechainのデザインシステムではガイドライン作成やダークモード対応などの改善を進めてきました。プロダクトのユースケースとして必要なコンポーネントも徐々に網羅されつつありますが、新たに3つの課題が浮上しました。

• デザインと実装の乖離があった
• 新規コンポーネントやバリエーションの増加に伴い、管理の負担が増した
• ガイドラインが浸透しておらず、インスタンスの扱いが統一されていなかった

それぞれの課題の詳細と、課題に対する改善アプローチについて記載します。

デザインと実装の乖離

具体的な乖離として、以下のような事例がありました。

• 実装不足による不一致（すぐには必要にならないコンポーネントをデザインしたことによるデザイン過多）
• デザイン不足による不一致（実装段階で発覚した新規要件によるデザイン不足）
• Figmaと実装におけるコンポーネント名称の不一致

これらの課題を調査していく中で、デザインと実装をどこまで一致させるべきかを定義することが第一ステップなのではないかと考えました。

そのため、エンジニアとデザイナーが協議し、デザインと実装の乖離をどの程度許容できるかを定義しました。

そして、enechainとしてのデザインシステムにおけるデザインと実装との乖離の許容範囲を以下のように定義しました。

見た目における乖離

✅　許容されること

• 仕様で予めデザインシステムのプロパティの上書きが許容されているコンポーネントの見た目の乖離
  • 例えば、WarningButtonは一部のプロダクトでしか使用していないため、デザインシステムにあるButtonのプロパティの上書きを一定の条件のもと許容しています。

❌　許容されないこと

• FigmaのメインコンポーネントのVariantsの並びとStorybookの並びの不一致

  • デザインと実装の乖離を発見しやすくするために同じプロパティのValueの順序を統一しています。

• プロダクト上ではまだ使用していないが、今後必要になると検討されたコンポーネントのバリエーションの不足

• Icon、Color、Size、Radius、Shadow、Typographyの不一致

プロパティの乖離

✅　許容されること

• StorybookのプロパティとFigmaのVariantsの不一致
• 動的および静的なプロパティの組み合わせによる不一致

• コンポーネント同士を組み合わせて作られるコンポーネントのバリエーションの不一致

  • 例えば、Modalコンポーネントで使用しているButtonはデザインシステムでButtonコンポーネントとして用意しているプロパティが含まれているので、ModalにおけるButtonのプロパティを含めたバリエーションの用意は不要です。

• StorybookとFigmaにおける静的なプロパティのValue名と動的なプロパティのValue名の書き方の違いによる不一致

  • 例えば、Buttonコンポーネントの左側にアイコンがあるバリエーションは、静的なプロパティなのでValue名は「Leading Icon」としており、StorybookとFigmaで同じ名称にしています。一方でButtonコンポーネントのホバーのバリエーションは、動的なプロパティなのでStorybookではValue名は「hover」としており、Figmaでは「Hover」としています。

• 実装時にのみ必要なプロパティはFigmaには用意しないことによるStorybookとのプロパティの不一致

  • 例えば、ToastコンポーネントはStorybookでは実装観点の効率からプロパティとしてUpdate（プロパティの変更が可能なプロパティ）を用意していますが、これはFigma上では用意していません。

• 複数コンポーネントを組み合わせた場合の動作に関連するプロパティ

❌　許容されないこと

• Storybookのプロパティ名・Value名の不一致
• 静的なプロパティの欠如
• 動的なプロパティの欠如

この定義に基づいて、既存のコンポーネント間で生じていたデザインと実装の乖離を修正しました。また、この定義を作成したことで、これまでの業務フローで発生していた乖離に対しても、エンジニアとデザイナーが意識を持ち、改善を図ることができました。

コンポーネントやバリエーションの増加による管理の負担

enechainのデザインシステムが成長するにつれて、個別のコンポーネントや、それらを組み合わせた複合的なコンポーネントが増え、それに伴いバリエーションも多様化してきました。

1. バリエーションが多すぎて、アップデートのたびに整理が必要になる
2. 複数のコンポーネントを組み合わせたバリエーションが多岐にわたる

1については、Figmaのプラグイン「Propstar」を使用して整理し、負担を軽減しました。また、プロパティやValueの順序を調整し、Storybookのコンポーネントの並びに寄せる工夫も行いました。

2については、上記の「プロパティの乖離」で定義した、「コンポーネント同士を組み合わせて作られるコンポーネントのバリエーションの不一致」は許容にあてはまるため、管理の負担を軽減できました。

さらに、コンポーネントの見つけやすさを向上させるため、Chakra UIを参考にコンポーネントをカテゴリごとに分類し、同じカテゴリ内のコンポーネントはABC順に並べました。

• Brand
  • Logoなど
• Media
  • Iconなど
• Navigation
  • Linkなど
• Form
  • Buttonなど
• FeedBack
  • Toastなど
• Data Display
  • Tableなど
• Disclosure
  • Tabsなど
• Layout
  • SideMenuなど
• Overlay
  • Modalなど
• Other
  • Dividerなど

ガイドラインの浸透

enechainでは、コンポーネントのガイドラインをNotionで管理しています。このガイドラインには、コンポーネントの使い方やデザインの背景、アクセシビリティに関する情報を記載されています。しかし、エンジニアへの浸透が課題で、積極的に参照しにいかなくてもガイドラインを認識できるような改善を行いました。

コンポーネント管理シートの上部にガイドラインの一部を記載することで、意識せずともガイドラインの要点を把握できるようにしました。

例えば、DatePickerではApplyButtonの有無のガイドラインについて明文化してあります。Storybook側での制御も検討しましたが、プロダクトや画面に応じてApplyButtonの有無を変えたい場合があるため、どういった場面でどちらを推奨しているのかを明文化しました。

さいごに

今回、デザイナーとエンジニアが協力してコンポーネントライブラリの管理を改善することで、より実務的な改善が可能となりました。デザインと実装の乖離や、コンポーネントやバリエーションの増加による管理の負担、ガイドラインの浸透について改善することで、質の高いコンポーネントをより効率的に利用しやすくなりました。 また、今回の改善がきっかけで双方が互いの業務について理解を深める良い機会にもなりました。

enechainのデザインシステムにはまだ改善すべき点もありますが、今回の変更によって大きく改善できたと実感しています。私たちのデザインシステムに関するナレッジが、世の中のデザインシステムに少しでも貢献できることを願っています。

デザインシステムの改善は一度で終わるものではなく、プロダクトやユーザーのニーズに合わせて進化していくものだと考えています。これからも、チーム全体でさらなる改善を続け、ユーザーにより最適な体験を提供できるシステムを目指していきます。

enechainでは、一緒に事業を拡大していける仲間を絶賛募集中です。新しい取引と価値を一緒に作っていきたいチャレンジングなデザイナー、エンジニアの応募をお待ちしています。