コンポーネント設計、基本すぎて誰も触れないけど確かめたいこと
先月、いつもオンラインで雑談してるイシジマミキさんにお声かけいただき、とあるプロジェクトのFigmaコンポーネントライブラリを猛烈に整理するというお仕事をしました。
わたしは普段、複数のスタートアップ企業に業務委託のUIデザイナーとして参画しています。いずれも既存プロダクトのリニューアルで、Figmaを使って様々なデザインワークを行なっています。
今回の「プロジェクトの”外の人”として、体験設計には踏み込まずコンポーネントの整理に集中する」という経験を通し、コンポーネント設計に関する超・基本的な部分についてあれこれ考えたことは個人的に大きな糧となりました。
自分自身が今後に活かすためにも、記憶が新鮮なうちに書き記しておこうと思います。
本題に入る前に；コンポーネントライブラリだけ見ても、コンポーネントの整理はできない
最初の打ち合わせで、イシジマさんから示された条件と要求は主に以下の内容でした。
チームのデザイナーは１人〜数人程度。常駐ではなく入れ替わりも多い。Figmaスキルもまちまち。
人に依存しない、シンプルで崩れにくい仕組みにしたい
対象のデザインデータ（Figma）は1ファイルで、作業状況や対応バージョン等によってページを分けてある他、１ページが「Components」となっていました。発展途上であるとか、規模の大きくないプロダクト開発ではよくある構成だと思います。
その他、今のデザイナーさんの仕事の進め方や実装者とのコミュニケーション状況なども確認させていただきました。
そう・・一口に「コンポーネントを整理する」と言っても、どのように整理していくのが最適かは、プロダクトの規模や種類、チームの構成やカルチャーなど、状況によって本当に様々。現状のコンポーネントライブラリだけポンと渡されても、設計しようがないわけです。なので、諸々の判断材料を得るための情報収集は最低限、行っておくべきですね。
では、ここから具体的に「コンポーネントを整理する」作業を通して、「基本すぎて誰も触れない・・けど、確かめたいね！」と思ったことを書いていきます。
そもそも、なぜ「コンポーネント」を使うんだっけ？
UIにおいて「コンポーネント」というと、だいたい「繰り返し使うUI部品」といった感じで理解されていることが多いと思います。
繰り返し使うのであれば、大元を一個（コンポーネント）にしておけば統一されるし、変更するときの効率もいい。だからコンポーネントというものを利用するんだよね！
・・てな感じでしょうか。これに関してはあまり異論ないと思います。わたしもざっくりと、そのように認識しています。
何をコンポーネント化する？
これ、根本的だけど意外と答えがバラつきそうな問いだと思いません・・？
当プロジェクトでは、シンプルに「画面を構成する部品はすべてコンポーネント化せよ」というルールにしました。
言い換えると「すべての画面が、コンポーネントのインスタンスだけで構成されている」状態を目指すということです。
画面内に、出自がわからない（コンポーネント化されていない）野良部品の存在を許さないという考え方になります。ちょっと過激でしょうかw？
冒頭では、コンポーネントとは「繰り返し使うUI部品」ですよねと書きました。
では、全てをコンポーネント化するとなると「1回しか使わないヤツ」もコンポーネントにすることにならない？・・色々と疑問が出てきそうです。実際わたし自身も、「本当にそうか？」とかなり自問自答しましたが、次のように考えました。
全画面を通しても1回しか登場しない部品（例：季節的なキャンペーンのページの装飾を含む部品など）があったとしても、
デバイスサイズによってどう調整するか、デザインのバリエーションを示す必要がある
別の機会に同じ構成の部品を使いたくなるかもしれない
画面内の「コンテンツ」は唯一無二だとしても、コンテンツの「入れ物」をコンポーネント化すれば、「レイアウトを維持したままコンテンツを差し替えて、他に展開する」という使い回しが可能になる。
→ 以上から、画面内のあらゆる部品はコンポーネント化しておく
トップにしか出てこないけど、イラストやプライスを差し替えて流用することも、ありそうじゃない？（だからこういったものもコンポーネント化しておくってこと）
もちろん、コンポーネントはボタンやテキストボックスなど、本当によく使う部品のみでいいのではという考え方もあると思います。「３回以上使ったら」など、回数で縛るのも手です。
そこを敢えて、全てをコンポーネント化・・というルールにしたのは、コンポーネント化するorしないの判断に迷わないようにしたかったからです。入れ替わりの激しいチームであれば、シンプルに・伝えやすい・誤解を生みにくいルールが望ましいので。
「コンポーネント」を作るのは、いつ？
前の話で、「すべての画面はコンポーネントのインスタンスだけで構成されている」状態を目指すと書きました。では、そのコンポーネントを作るのはいつ、どのタイミングでしょう？画面のデザインを構築する“前”？それとも“後”？？
ところでUIデザイナーの皆さん、「画面をデザインする」という行為をどのように行っていますか？
元々用意してある部品を使って、組み立ていく感じでしょうか？
まずは画面を「一枚の画」として描く（そして後から部品に分解する）感じでしょうか？
どっちが正解というわけではなくて・・「どっちもある」のが普通だと思います。
当プロジェクトでもその実態を反映する形で、
汎用コンポーネント
ドメインコンポーネント
の2種類を定義しました。
汎用コンポーネント
わかりやすいのは「ボタン」でしょう。ほとんど全てのアプリで、色んな画面で使われますね。一般化すると、あらゆるシーンで汎用的に使えるUI部品・・ボタンの他には、ヘッダー、リスト、カード、などでしょうか。これらを「汎用コンポーネント」と呼ぶことにしました。
汎用コンポーネントは、具体的な画面デザインを行う前にあらかじめ用意しておくとよいです。といってもゼロから作る必要はなく、開発する環境やプラットフォームに応じて、Material DesignやHIG、 そのほか各社から公開されているライブラリから抽出・アレンジして利用するのも良いと思います。
ドメインコンポーネント
基本的には、汎用コンポーネントを使えばさまざまな機能を果たす画面を構築することができます。
ただ、実際のプロダクトデザインでは、ある特定の画面／機能／オブジェクトに対してのみ使用するコンポーネントも必要になってきます。それらを「ドメインコンポーネント」と呼ぶことにしました。
ドメインコンポーネントは、その使用先となる画面のデザインをしながら・あるいは画面デザインがある程度完成された後に、画面から切り出すような形で作ることになるでしょう。
で、「コンポーネントはいつ作るのか」という問いに戻ると、結局答えは「最初に用意するのもあるし、後からも追加してOK！」です。
ここでは便宜上、「前に作る汎用コンポーネント・後から作るドメインコンポーネント」という切り分けで書きましたが、絶対そうしろという話ではなく、柔軟で良いと思います。
ただ気をつけたいのは、特にドメインコンポーネントを作る際に「再発明」をしてしまってないかという点です。まずは既存のコンポーネントの利用を検討し、似て非なるコンポーネントの量産をしないように・・！
無駄な重複を防ぐ意識は必須だと思います。
当プロジェクトでいえば「リスト(list)」と名のつくコンポーネントが沢山作られているのが気になりました。
何のリストか次第で構成要素に違いはあれど、余白やスタイルは共通でよいはずです。ところが、個々でバラバラの設定だったのです・・。
対応として、汎用コンポーネントの「リスト（とリストアイテム）」を新たに作り、あらゆる「リスト」の原型としました。
ドメインコンポーネントの話はこの記事を参考にしました。かなり規模が違いますがw
コンポーネント・・どう作る？
では、具体的な「作り方」についてです。
何度か出てきたように、コンポーネントとは「繰り返し使う部品」でした。少し詳しく言うと「構造はそのままで、ある部分をちょっとだけ変えて使い回す部品」です。
作り方については色んな考え方があって良いとは思いますが、「コンポーネントは使い回される前提で作る」という原則を特に意識したいと考えました。
コンポーネントを「使い回す」とは
ボタンの場合、「ボタンのラベルを書き換えて使う」のは「使い回す」の範囲内でしょう。では、「角丸のRを変える」「色を変える」「テキストのサイズを変える」「上下のPaddingを変える」・・はどうでしょうか・・？
ちなみにFigmaの仕様では、コンポーネントをインスタンス化したものに対して、テキスト、色、角丸、シャドウ（エフェクト）、AutoLayoutの諸々のプロパティなど、多くの属性がオーバーライドできてしまいます。内包するレイヤーの表示／非表示も切り替えられてしまいますね。
変えてよい（variableな）部分と、変えてはダメな（staticな）部分
コンポーネント作成時の意図を知らない人が、先ほど書いたような想定外のオーバーライドをしてしまうということは、普通に起こり得ることです。（もちろん、メンバー全員に一定以上の理解があれば問題ないでしょうけれど・・）
コンポーネントの原型をとどめないインスタンス化を防がなければ、コンポーネントを利用する意義もなくなってしまいます。なので、「正しく使い回される」ためには、「変えてよい（variableな）部分と、変えてはダメな（staticな）部分」が明確になっているのが望ましいです。
色・サイズ・Padding・スタイルはStatic。
アイコンの有り／無しもvaribleかな？ではラベルは？
変えてよいのはどこまでかを明確にするのに、Figmaの機能の「Variant」や「Component Properties」が有用と思います。
「Variant」の変異パターンと「Component Properties」で変更可能にしているプロパティだけは「変えてOK」とし、コンポーネント内のレイヤーを直接選んでプロパティを編集するのは「NG」とすれば、ルールとしてはシンプルですね。
ベータ版で公開されてるNested instanceやPreferred valuesも活用できるともっと良さそう！
ただ、今回のプロジェクトでは敢えてそのようにせず、Component Propertiesの使用は最低限としました（←あまり使い慣れてない様子だったので）。
代替としてVariantの構成を工夫したり、変えてOKなテキストの部分は明らかにダミーテキストとわかる文字列を入れておくなど、意図を理解しやすいように配慮しました。
Component Propertiesに頼らないとなると、Variantの変異パターン数が多くなってしまいがちです。そのため、コンポーネントをネストするとか、使い道ごとに別のコンポーネントにするなどの対応をしました。Variantの構成についてもかなーり頭を捻ったので、それもまた別記事にしたいなと・・
基礎知識として、Figmaのコンポーネントがどういう仕様になってるかは理解しておく必要があります。Figma公式のチュートリアルやYouTube（コンポーネントに関しては、この再生リストあたり）をご参考に。
いきなり「完成されたコンポーネント」を作ろうとしない
ここまでさんざん語っておいてなんですが・・。
実際のUIデザインはそんなにキレイに進むものではなく、アイデアをこねくり回して、色んな観点からのレビューを浴びまくって、少しずつ最適解に近づいていく（ときに遠のいたりもする）ものです。
コンポーネントも「作っては壊し、作っては壊し」な段階があるのは当然です。途中経過まで完璧である必要はないく、エンジニアさんにハンドオフするとか、他のデザイナーさんとの共用が必要になったタイミングで、辻褄の合う形になっていれば十分ではと思います。
コンポーネントライブラリを正しく活用するには？
・・・そろそろまとめに入ります（キリないのでw）。
この記事では、実務を通して改めて向き合った、「コンポーネント設計における基本中の基本」を中心に書きました。こういった内容は、基本すぎる故にあまり語られておらず、意外に共通認識になっていのではと思います。
色んな意味で認識のレベルを合わせることが必須だなと感じた他、適切にコンポーネントライブラリを活用・運用していくために仕組み側で対応できることも多々あるよなぁ、と思いました。例えば・・
プロダクトの成長によってコンポーネント構造も変わる。「常に最適化する」「変わり続ける」というマインドセットをみんなで持つこと
一定レベルのFigmaスキルを要求すること。スキル要求レベルを満たさない、学ぶ意志もない人を採用しないなど
ドキュメント（簡単なルールブック的なもの）の整備と共有。「読んでおいて」じゃなくて「読み合わせする」こと
定期的なメンテナンスを行うこと。複数人いるならば、可能な限り同期コミュニケーションで。
特に、コミュニケーションとメンテナンスですね。
とはいえ、本来の開発でパツパツな状況では、メンテナンスの工数もバカにならないです。やってられるか！と後回しになってしまうのは重々理解できます。
そこで、今回わたしが頼まれたように「外の人に整理を依頼する」のは全然アリだと思います。外の人ですから、プロダクトに入りこみ過ぎることなく適度にドライに、整理することに集中できるのでかえって効率が良い気がします。
わたし自身「整理整頓好き」な人間なので、今回のお仕事は短期間ながら相当のめり込んでやらせていただきました。（あとね、イシジマさんが褒め上手なのよ。）できることならまたやりたいと思っているので、散らかったまま見て見ぬふりしてやり過ごしてるコンポーネントライブラリがあったらお声かけいただければと！お片付けしに参上しますよ。
それでは。
この記事が気に入ったらサポートをしてみませんか？