Figmaコンポーネントづくりきほんの考え方 2024 Xmas版
Money Forward Design Advent Calendar 2024。ついにクリスマスイブですね！
今年はFigmaのアップデートでこれまでできなったことが色々解消され、より効率的でシンプルに使えるようになりました。そこで、あらためてコンポーネントをつくるときに私が心がけている「きほん」を整理してまとめてみました。
毎度のニッチなノウハウやケース紹介ですが、お楽しみください！
ともかく命名する
さて、まずは、もっとも重要と言っても過言ではない命名です。命名しないといけない場所はたくさんあります。
コンポーネント名
レイヤー名
バリアント、プロパティ名
バリアブル、コレクション、モード名
Figmaのコンポーネントにおいてはこれらの命名はすべて大切です。
とくにアップデートするとき、バリアントを切り替えたり、似たようなコンポーネントをスワップしたりするときなどは名称をキーとして入れ替え先を見つけることが多いです。うまくオーバーライドが引き継がれなかった！とかの事故はおおむね命名がずれている場合ではないでしょうか。
命名規則を用意して、複数のコンポーネント間でブレないようにすること、パブリッシュ前にはよく確認して命名されてないレイヤーが無いか、スペルが間違ってないかのチェックはとても重要です。
また、大きな影響はありませんが、複数コンポーネント間でプロパティ名の順番などもきれいに揃えると使い勝手も良いと思います。
ともかくバリアブルつかう
コンポーネントを構成するありとあらゆるバリアブルが使える場所にはバリアブルを使います。
これにはデザインを構造化するとか、共通言語化して実装コンポーネントと連携したりすることを容易にする、というのがもっとも重要な側面ですが、コンポーネントライブラリを運用するひととしても重要なポイントがひとつあります。
それは、デタッチへのちょっとしたフェールセーフになるということです。
デタッチ、されたくないですよね？でもどうしてもされてしまうことあると思います。コンポーネントをデタッチした場合でもその中で利用されているバリアブルの指定は消えません。（もちろん消されてしまえば消えますが…）
可能な限りの要素にトークンが利用されていれば、自分の知らないバリエーションが作られてしまった場合でも、大きなズレは起こりにくく、またトークンのアップデートは受けられるので、更新性もすこし担保されます。
それはそれとして、ビジネスプラン以上だったらデタッチされているかどうかは解析をみるなどしてチェックもしましょう！
ともかくプロパティつかう
ともかくプロパティが使える部分はプロパティを使う、ということも心がけています。
いろいろな理由がありますが、個人的に重要なのは、組み合わせ爆発を防ぐということと、変更できる場所を明確にすること、アップデートが行いやすくなることなどです。
組み合わせ爆発をふせぐ
たとえば特定のレイヤーのオンオフはバリアントとして作っても、プロパティのBooleanを利用しても出来ますが、そういったすべてをバリアントで作ってしまうと、状態の組み合わせを表現するためにバリアントがどんどん膨らんでしまいます。
画像の例だと、アイコン無し、左に有り、右に有り、左右に有りの4パターンですが、プロパティは一つのコンポーネントで表現できますが、バリアントでやると4つのコンポーネントレイヤーが必要です。
これが3つだと9、4つだと16…となってしまうのでプロパティを使えるときはプロパティを使うのはとても大切だと思っています。
プロパティで良いところはそのようにして、必要な所だけバリアントにすることで管理のしやすいコンポーネントにできると思っています。
明確にする
ボタンのラベルのようにコンポーネントをつかうときに変更して使う部分をプロパティにしておくことで、明確に「そこは変えて良い場所だ」ということを伝えることができます。
また、プロパティがしっかり設定されていれば、対応するテキストレイヤーなどが変わってしまってもオーバーライドが引き継がれます。この点からも変更して使う場所については確実にプロパティ化するのが安心です。
ともかくシンプルにする
特にコンポーネントをつかうのが自分以外のとき、いろいろな使われ方をして期待通りに使ってもらえるかは重要なポイントです。
そのときに効くのはここまで書いてきたことに加えて、可能な限りシンプルにつくると言うことです。
とくに使ってもらってから問題が起きやすいのはオートレイアウト周辺で幅高さをちゃんと変えられるか？コンテンツによって適切に伸び縮みするか、の所ではないでしょうか？
Figmaのオートレイアウト、折り返しなども出来るようになりとても便利になりました。それでもなお、レイヤーがネストしているときに期待通りの挙動をさせることが難しいときもあります。
これはFillやHugなどの計算がどうしてもレイヤーの親子構造によってしまうためです。つまり、構造が深ければ深いほど意図しない挙動になる可能性がたかくなります。
必要最低限の深さかどうか？無駄に深くしていないか？もっとシンプルに出来ないか？という視点でブラッシュアップします。
構造がシンプルになると命名しないといけないレイヤーも減ってハッピーです。逆に命名しにくいレイヤーがあるとき、それは構造上おかしな部分のシグナルだったりするときもあります。
メリークリスマス！
ひとつでもヒントになることがあったら幸いです。それでは良いクリスマスを！
それぞれのプロダクトでもっとユーザーフォーカスを実現するための大規模なデザイン基盤をつくっています。こんな細部に気を配りながらも、大きなチャレンジを一緒にしてくれる人、募集中です。
あしたはセルジオさんから「CDOってどんな仕事？その参」をお送りします。おたのしみに！
