🤯

もし「バカ」がコンポーネントライブラリを作っても大きな損失のでにくい設計ルール

2021/11/02に公開

variantにまとめる？同じカテゴリの兄弟にする？

例えばボタンで以下のようなプロパティが存在するとしよう

私はかつて、これらをひとつにまとめたvariantを作成した事がある。

Figma上での開発体験としてはbuttonをとにかくAssetから呼び出しさえすれば、上記すべての内容を設定できるのが非常に便利だったが、しかしいくつかの問題が発生した。

例えばスタイルの違うボタンを配置したくなった時、Variantにまとめてしまうと探すことはできない。希望の見た目が存在するかどうかは実際にカンバス上にボタンを設置するまで分からないのだ。なのであらかじめ別のドキュメントを参照しなければならない。

「ある見た目のものを配置したい」というケースではvariantにまとめすぎるのは良くないのだ。

わたしのFigmaの理解度や設計力が足らないだけかもしれないが、そのような「バカ」でも設計時に損失が少なく、またやり直しやすくしておく事はとても重要である。

正解不正解はないので自分のチームがどのような構造で役割を分担しているかによって決めると良いだろう。
デザインシステムのメンテナーが専任だったりして、十分にメンテナンス可能なのであり、リリースサイクルに影響が出ないのであれば設計が複雑でも大丈夫だろう。

hotfixやfeature実装、はてはマーケティング側の制作も兼務しているようなオールラウンダーが多いチームで、複数の人間がコンポーネントライブラリを作るのであれば設計の方をシンプルにした方が良い。

プロパティをどこまでひとつのVariantにまとめるかどうかは判断の分かれるところである。複数の人間でコンポーネントライブラリを作っていく場合はその条件も定義する必要があるだろう。

重要なのは下記の二つと考える。

二つのコンポーネントを見比べて、親子として認識できるかどうかは非常に重要である

下記のような例を見てみるとどうだろうか、ベースとなるボタンに対して下に並ぶボタンはどのような継承関係があるのか考えてみよう。

この時、サイズを親子とするか、アイコンの有無にするか、いずれも全てひとつのvariantにするかどうか。わたしはこのようにした。

理由はアイコンの有無は目で見なくても想像できるが、サイズに関しては「いくつバリエーションがあるのか」「それぞれの違いはどのくらいあるのか」を想像しづらい点にある。

ボタンを利用してFigma上で検索したときに、variantに含まれたバリエーションは見つけることができないので、視覚的に差があるものはVariantに含めないようにしている。

上記の経緯をもとに今回は悩みがちなVariantにまとめるかどうかの条件を上記のように定義した。
基本的にvariantにまとめるものはState以外ではサイズ or アイコンとする。
またStyleのような見た目の異なるものはVariant化せず下記のように「兄弟」として分けることにした。

button/primary (fill)
button/secondary (hollow)

※カッコ名は役割ではなく見た目で命名した場合の例

暫定的ではあるがシステムやライブラリにて判断に迷うケースでは下記のようなことをチェックするようにしている。これらの影響範囲が小さければとりあえずやってみれば良いので簡単である。

問題はこれらについて多大な影響があるかどうかなので、そもそもとして「バカでも分かる」「壊れにくい」「原因究明がラク」といのは非常に重要なことなのだ

もし、これらの内容を見て参考になると感じたらぜひ「いいね」をしてもらえると嬉しいです。では！