コンポーネント管理の重要性

こんにちは、Ayakoです。
デザイナーとして、フロントエンドエンジニアとして普段PlayGroundで活動する中で、なぜデザイナーがコンポーネント管理を丁寧にしなければいけないか、どう管理するべきなのか伝える必要性を感じたので本記事を書こうと思いました。

対象読者は以下です。

figmaの基本的な機能をある程度理解していること
WEBページの見た目をfigmaで表現できること

前置き、そもそもデザインシステムとは

デザインシステムは良いデザインを統一感・一貫性を持って管理する仕組みです。
デザインの原則やガイドライン、そしてそれらに沿ってデザインされたコンポーネントとその実装コードがひとまとめになったものです。

エンジニアはデザインシステムに用意されたボタンやフォームなどのコンポーネントを組み合わせ実装します。
デザインシステムが確立されていないと、エンジニアが自分でコンポーネント設計をしなければならなくなり、負担になります。
わかりやすいデザインシステムはサービスを利用するユーザーの体験価値を上げるだけでなく、引き継ぎのしやすさやチーム内の意見交換が活性化するなど内部にも良い影響をもたらします。
エンジニアの負担をデザイナーが軽減してあげられるよねという話。

Frame-40

じゃあどうやってコンポーネントを管理するの？

figmaをある程度触ったことがある人なら答えられますかね？
component機能とvariant機能です。

これらの使い分けがうまくできないとデザインシステムは逆にわかりにくくなり、エンジニアは地獄を見ます。
エンジニアにとってどういう使い分けができていればわかりやすいかを本記事で説明します。

HTMLが根本的に違う場合はcomponent, CSSで書き分けるならvariants

要するに、違うコンポーネントはcomponent、見た目の違いはvariantsで管理しよう！ というのが私の考えです。
はにゃ？はにゃはにゃ？
代表的な４つのパターンを紹介するので順番に見ていきましょう。

エンジニアはコンポーネントごとにファイルを作成します。同じコンポーネントで場合により見た目が変わる場合は、同一ファイル内で書き分けます。
どこまで同じコンポーネントと見なすか、よく考える必要があります。

case2

1.違うコンポーネント

違うコンポーネントはvariantsで管理しようがないですよね。
これは大丈夫なはず。

case1-1

2.マウスアクションによる見た目の違い

これはvariantsで管理しましょう。
variantsのプロパティを見るとわかるかと思いますが、ホバーした時にデザインが変わるボタンコンポーネントです。
注目して欲しいのはコードの枠線部分。このようにマウスアクションによる違いは、同一ファイル内で書き分けができるので違うコンポーネントとはみなしません。
よってvariantで管理したほうがエンジニアにとってわかりやすいのです。
また、少し細かいかもしれませんがfigmaのコンポーネント説明にどのようにデザインが変化するかメモを残しています。どのように動くかまで想像し、伝えることも重要です。
参考: 変化の度合いの種類