あっ、使いやす〜い！Figma UIライブラリのページ構成を考えた

ogp

🎄この記事はenechain Advent Calendar 2024の18日目の記事です🎅

こんにちは！enechainデザイナーのET(@et_universe)です！

JTC総合職やデザインファームでの経験ののち、今年の10月からenechainで働いています。

enechainでは、有志のエンジニアとプロダクトデザイナーによるデザインシステムチームが活動しており、私も入社直後からデザインシステムチームに参加しました。現在はFigmaのUIコンポーネントライブラリのページ構成や使いやすいコンポーネントの作りについて考え改善をしています。

※デザインシステムについて、今までの経緯などはメンバーの記事が詳しいです！

techblog.enechain.com

はじめに

この記事では、「Figmaコンポーネントライブラリで便利なページ構成ってなんなんだろう？」「理想的なUIコンポーネントライブラリにするために必要なことって何？」ということを私が考えたTipsをまとめました。

デザインシステム全体のHow toや思想、詳細のそれぞれのコンポーネント単位のすがた/かたちについては世の中にたくさん本や記事があるものの、「現行公開されている優れたデザインシステムのFigmaコンポーネントファイルの構成」についてはあまり参考となる文献がなかったため、自分で調べまとめてみようというのが記事のきっかけでした。

Figmaのデザインシステムライブラリによくある要素

※今回はFigmaのUIコンポーネントライブラリ（＝UIライブラリ）について取り扱います。UIライブラリはデザインシステムに内包されているものもあれば、UIフレームワークに内包されているものもあります。

はじめに
今回参考にしたデザインシステム/UIライブラリ
各社どんなページ構成になっているの？
1コンポーネント=1ページにするってどういうことだろう？
コンポーネントをまとめた上位カテゴリはいらないの？
まとめ
Appendix: 参考にしたデザインシステム/UIフレームワークライブラリ

今回参考にしたデザインシステム/UIライブラリ

今回、理想のコンポーネントライブラリを検討するにあたり、以下のtoBのWebアプリケーションを展開している海外事例を中心に調査しました。

上記の事例を中心に調査した理由は以下の2つです。

enechainの各プロダクトがtoBのWeb SaaSであるため
enechainにある10のテックカンパニーの定義の1つ目にWorld-class Tech Organizationがある。Japan-classではなくWorld-classを目指すためにも海外で評価されているものをベンチマークにしたいため

enechainのテックカンパニーの定義 World-class Tech Organization

記事の最後に今回調査した25事例のURLを載せているので興味のある方はご参照ください🙌

各社どんなページ構成になっているの？

各社のFigmaのUIコンポーネントライブラリを眺めて、分類すると以下の傾向がわかりました。

✅コンポーネント数が多く複雑になるほど、1つのコンポーネントにFigma1ページを使用している

コンポーネントの種類が多岐に渡り、複雑性が増しているサービスやUIライブラリほど1コンポーネント=1ページの構造をしている。このようなページ構成のファイルほど、ガイドラインが充実していた。
一方で、コンポーネント数が少ない＆モードの切り替えやバリエーションの数が少ない場合、多くは1ページで複数のコンポーネントを表示していた。ガイドラインがなく、1ページで表示しても一覧性が高くなるようなコンポーネント数の場合、特に国内事例でシンプルなコンポーネントを使用している場合によく見られた。

✅UIライブラリ以外ではほぼ各コンポーネントの上位のカテゴリ(ディレクトリ)を設けていなかった

UIフレームワークでは上位カテゴリを設けている事例が見られた。一方で、特に企業のデザインシステムのFigmaファイル公開においては上位カテゴリで各コンポーネントを分けていなかった。
1社、Uberのみ一般的なコンポーネントを使用するモバイルアプリであるからか、コンポーネントの上位カテゴリを設けていた。

各社のFigmaのUIコンポーネントライブラリ

※海外事例はBlue, 国内事例はPinkにしています

なぜこのような傾向が見られるのでしょうか？以下で考察した結果をご紹介します！

1コンポーネント=1ページにするってどういうことだろう？

1コンポーネント=1ページにするメリットとして、まず思い浮かんだのが、FigmaのAssetsからの呼び出しが容易になるからだろうということでした。

Figmaでは、Assets機能を活用することで、ライブラリからコンポーネントを簡単に呼び出し、作業中のファイルに追加・編集できます。この機能を活用することで、ライブラリファイルを直接開くことなく、publishされた最新のコンポーネントを常に使用できます。

また、Assetsの呼び出しでは、コンポーネントが格納されているページがA〜Z順に並ぶため、ページ名を英語表記にすることで、日本語表記による並び順のばらつきをなくし、コンポーネントページの並びとAssets呼び出し時の並びを一致させ、検索性を向上させることができます。そのためなのか、1コンポーネント=1ページとしているライブラリは国内企業でもすべて英語名を使用していました。

ページ名=コンポーネント名で並んでいる例

コンポーネントが1つorサムネイルが異なるものが2~4個程度の例

また、1コンポーネント=1ページの企業ほど、ページ内部でのコンポーネントに対する情報が充実している傾向が見られました。モードやステータスによる異なる見た目のバリエーションやガイドライン、使用例などの情報が充実しています。スペースが広く使えるので、そのコンポーネントに対する情報を個別最適で入れやすいのはもちろん、Figmaでは一括変更などをページ単位で行えるのでコンポーネントの更新性も高いのではないでしょうか。つまり、一括変更をしても他のコンポーネントが意図せず変更されてしまうような心配がありません。

特に、enechainでは海外の社員もいるため、コンポーネント名を英語で管理することは、将来的に海外のメンバーを迎える上でも重要だと考えています。

コンポーネントをまとめた上位カテゴリはいらないの？

コンポーネントをまとめた上位カテゴリの事例

今回調査して面白かったのは、各社企業のUIライブラリではコンポーネントの上位カテゴリを設けておらず、UIフレームワークでのみ存在する傾向が見られたことでした。

ここは企業UIライブラリとUIフレームワークの違いを考えるとなぜその傾向があるのかわかりやすそうです。

企業のUIライブラリ

目的: 自社のブランドアイデンティティを反映し、デザインの一貫性を効率的に保つこと。
範囲: 自社製品やサービスに特化した、ボタン、入力フォーム、カードなど、具体的なUI要素のセット。一般的ではない独自UIも存在する場合がある。
特徴:
- 企業独自のスタイルガイドに厳密に従う。
- 社内での共通認識を確立し、開発効率を向上させる。
- 長期的にメンテナンスされ、コンポーネントが増減したり進化し続けるものである。

一般のUIフレームワーク

目的: 幅広いWebアプリケーションやモバイルアプリに対応できる、汎用的なUIコンポーネントを提供する。
範囲: ボタン、ナビゲーション、レイアウト、フォームなど、汎用的なUI要素のセット。
特徴:
- さまざまなプロジェクトで再利用可能。
- コミュニティによる活発な開発が行われ、新しい機能やバグ修正が頻繁に提供される。
- 一度コンポーネントの種類が確定するとアップデートはされても増えることはあまりない。

一番の違いは、コンポーネントの種類の増減が頻繁に発生するか否かではないでしょうか？

カテゴリは恣意的なもので、人の頭の中を視覚化したものだと考えています。また、最適なカテゴリはその中身が何であるかによって、都度変わってくるものでもあります。（例えば、Form内のコンポーネントの数が他のカテゴリよりもかなり増えた場合、Form内でもさらにカテゴリを分割すべきかなどを検討するとより使い勝手が上がるかもしれません。）

そのため、UIフレームワークでも一意のカテゴライズは存在せずにそれぞれ独自の定義を設けています。

これを頻繁にアップデートされ、独自性の高く複雑なコンポーネントの追加や変動が起こる企業デザインシステムのコンポーネントライブラリに適用するのは、毎回カテゴライズも検討することになり更新コストが上がるために難しく採用していない企業が多いのかもしれません。

まとめ

今回は、Figmaのコンポーネントライブラリにおける理想的なページ構成について、調査結果と考察をまとめました。enechainでは以下のポイントを意識して、今後のライブラリを作ってみようと考えています。

コンポーネントはページ単位で管理する： FigmaのAssets機能を最大限に活用するために、各コンポーネントを個別のページに配置することで、検索性と管理性を高めます。ページ名はアルファベット表記に統一することで、Assets呼び出し時の並び順との整合性を保ち、日本語表記による並びのばらつきを防げます。また、各ページ毎の更新作業もしやすくなりそうです。
カテゴリ分けは必須ではない： 調査の結果、企業のデザインシステムではカテゴリ分けを行っていない事例が多いことがわかりました。カテゴリ分けは必ずしも必要ではなく、コンポーネント名を適切に定義し、検索機能を活用することで、効率的なコンポーネント管理が可能です。UIフレームワークでは、コンポーネントの増減が少ないためかカテゴリ分けが見られる事例もありましたが、広く普及した明確な基準はありませんでした。

今回の調査は現時点でのFigmaで各社が提供しているライブラリに基づくものです。Figmaはどんどん進化しているので、理想的な形は今後変わる可能性があります。

アップデートし続けるFigmaを武器にして、enechainメンバーがより使いやすいUIライブラリづくりもアップデートしながら探求＆更新しつづけます👌

enechainでは一緒にプロダクトを成長させ、信頼性のあるブランドに育てていける仲間を絶賛募集中です。eSquare Liveを始めとしたプロダクトのより良い体験を目指しながら、新しいエネルギーの取引と価値を一緒に作っていきたいチャレンジングなデザイナー、エンジニアの応募をお待ちしています！

herp.careers