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

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

対象読者は以下です。

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

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

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

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

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

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

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

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

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

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

1.違うコンポーネント

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

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

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

figma	コード

3.サイズの違い

これもvariantsです。
プロパティでサイズを分けることができますし、同じパーツなので同一ファイル内で書き分けをします。

figma	コード

4.ブレークポイントによる見た目の違い

賛否両論あるかもしれませんが、これも私はvariantで管理するのがいいと思っています。
コードは割愛しますが、メディアクエリというものを使い同一ファイル内で書き分けできるためです。

例外もあるよ

同じコンポーネントでもvariantsで管理しなくていい例もあります。
それはpropertyが荒れてしまう場合です。

右側のheaderはCONCEPTがドロップダウンメニューになっており、左側のheaderはハンバーガーバーの折りたたみ、さらにCONCEPTが畳まれている構造です。
(トレースしたもの)

propertyのstatusを見てみると、可読性が悪くなっていると思います。
このような場合は、ブレークポイントで分けても良いのではないかと考えています。

注意点としては、同じheaderであることをきちんと示さなければいけないことです。
例外のパターンであることをエンジニアに伝えましょう。

最後に

いくつか紹介しましたが、デザイナーがエンジニアの気持ちを完全に理解するには多少マークアップの知識は必要です。
マークアップの知識がつくと自ずと必要なコンポーネント管理の方法が見えてきます。
興味がある人はフロントエンドも触ってみると面白いと思います！