はじめに
はじめまして！
レバテックでプロダクトデザイナーをしている成田です。
現在は日々のプロダクトデザインの業務に加え、デザインシステム『VoLT』の構築と運用に取り組んでいます。
なんとか社外公開まで漕ぎ着けた『VoLT』ですが、プロジェクトが開始してすぐの頃は「無理だ」と弱音を吐きたくなるほど課題が散見されていました。実際、私は何度も「え〜無理なんだが」と声に出しながら作業を進めていました（笑）
本記事では、Figmaでのコンポーネント管理の話を中心に、抱えていた課題を解決するために生み出した 「インスタンスガイドライン」 というものについてお話しできればと思います。
ちなみに、デザインシステム構築の背景や目的が書かれた記事も公開されているので、気になる方はぜひチェックしてみてください👏
何が難しい？レバテックのデザインシステム
デザインシステムは、定義すること自体は難しくありません。ただし、運用を軌道に乗せるのは本当に難しく、デザインシステムの構築が難しいと言われる所以はそこにあるのかなと思います。また、レバテックではさらにデザインシステムの構築の難易度を上げる背景がありました。
複数のプロダクトの状況を考えたデザインシステム構築
レバテックは、より多くの方に価値を届けるために1つのブランドの中に複数のプロダクトが存在しています。ITエンジニア向けの記事コンテンツを掲載しているコンテンツメディア、企業がITエンジニアをスカウトするためのダイレクトリクルーティングなど、プロダクトの形式も様々です。
レバテックが運営するプロダクト一覧
提供するプロダクトによって、文字組などのスタイルも変わります。
たとえば、ダイレクトリクルーティングとコンテンツメディアでは、本文のテキストが14pxと16pxで異なっていたり、Line-heightの高さも異なります。レバテックのデザインシステムの構築するには、各プロダクトのすべての状況を加味して仕組みをを作る必要があったため、構築のハードルが上がってしまっていました。
『VoLT』構築以前にもUIライブラリは運用されていた
とはいえ、以前から「Levtech-Components」と呼ばれるプロダクト横断して利用できるUIライブラリは存在していました。各プロダクトのカラーなど基本的な定義、ボタンなどの頻繁に使用するパーツのコンポーネントが用意されており、生産性と一貫性の担保という点では、一定機能しているガイドラインでした。
「Levtech-Components」を一部抜粋
ただし、こちらのUIライブラリはコンポーネント管理という観点で大きな問題を抱えていました。
現場のデザイナーはインスタンスを外してデザインを作っている！？
…。
響きだけでも恐ろしい見出しですが。（笑）
そうなんです。
実はこの「Levtech-Components」、各プロダクトで使用されていたのですが、現場のデザイナーがコンポーネントのインスタンスを外し、独自のコンポーネントが生み出されるという悲劇が多発していたんです。なぜそのようなことが起きてしまったのでしょうか？
事前に弁解しておくと、決して「Levtech-Components」の定義や考慮が浅かった、というわけではありません。ただ、レバテックの開発体制には少し合わないUIライブラリだったのです。
先ほどお話しした通り、レバテックはマルチプロダクト戦略をとっており、複数のプロダクトを運営しています。開発体制も同様で、各プロダクトにマーケター・エンジニア・デザイナーが所属し、担当プロダクトの改善に取り組んでいます。デザイン作成時は、各プロダクトを横断して使用できる「Levtech-Components」と、ユニークコンポーネントと呼ばれる各プロダクト独自で管理するコンポーネント2種類を使用していました。
日々生まれる様々な施策
より良いプロダクトにするために各プロダクトで様々な施策が立案されています。
簡単な事例で説明すると「登録フォームに遷移するボタンに無料という訴求を追加して、登録率を向上させよう」といった感じです。そういった有象無象のカスタマイズに、「Levtech-Components」は対応できませんでした。
その結果「訴求をつけたいから新しいパターンを増やそう」といった形で、徐々に「Levtech-Components」から派生したコンポーネントがユニークコンポーネントに追加される形で増えていきました。
たくさん生み出されるボタンの一例
それぞれのプロダクトで同様のことが発生していたため、プロダクトを横断して、めっちゃ似てるけどちょっと違うコンポーネントが大量に生まれてしまっていたのです😢
こうなってくると、コンポーネント管理の恩恵を受けることができない状態になってきます。
似ているが違うコンポーネントが使われることで、一貫性が徐々に損なわれていき、「Levtech-Components」に変更が入っても、違うコンポーネントになっているので一括で反映できない。また、エンジニアはどこまでが共通コンポーネントなのかわからず、確認のやりとりが逐一発生する…。
こうした状況が続き、「Levtech-Components」は少しずつ機能しなくなり、使われないシステムになってしまっていました。
使われるデザインシステムにするために
『VoLT』が使われるシステムになるためには、2つの課題がありました。
1つ目は、複数のプロダクトを横断しても使いまわせるコンポーネントを作ること、2つ目は使い続けてもらう仕組みを作ることです。この2つを達成するために、私たちは以下2点の取り組みを行いました。
取り組み①：汎用性が高く・管理コストの低いコンポーネントの作成
まずはデザイナーとエンジニアで、
「すべてのプロダクトで共通反映の施策だったのに、管理がバラバラだったから作業が大変だった」
「このパーツってプロダクトごとに独自性出す必要ないよね」
などの具体的な状況を挙げながら議論を重ね、プロダクト横断で使用するコンポーネントを選定しました。
共通化することを決めたパーツたち
次に、デザイナー主導でコンポーネントの作成に取り掛かりました。
事前に全プロダクトのコンポーネント利用状況を調査し、必要なパターン（バリアントやプロパティは何を持たせるべきかなど）を洗い出しながら作成を進めました。
調査の一例
以下は完成したコンポーネントの一例です。
各プロダクトで使用できるように、ベースはモノクロで作成しています。実際に使用する際は、カラーを変更し、プロダクトごとの独自性を出すことができます。デザイナー、エンジニアが使いやすいように、プロパティの持たせ方なども結構練られて作られています。今後Figma Community上にコンポーネントが公開された際にはぜひ、実際のコンポーネントを触ってみてください✨
コンポーネントの一例
おまけ🍭：ステータスの優先度
これはちょっと小話になるのですが、作成したコンポーネントをエンジニアに実装してもらう際、
「エラー状態でホバーした場合は、見た目ってエラーのまま？ホバーのスタイルになる？」
とステータスの状態管理について質問されたことがありました。
デザイナー側では一切考慮できていなかった部分で、「た、たしかに・・・！」とハッとしました。デザイナーの想定をきちんと伝えてられていないと、実装の際に迷いが生まれてしまいます。そのため、コンポーネントのガイドライン内に 「ステータスの優先順位」 という項目を追加して、実装時困らないように工夫しました。エンジニアと密に連携をとりながら取り組んでいたからこそ事前に気づけたことであり、とても嬉しい気持ちになるエピソードでした☺️
ステータスの優先順位
取り組み②：インスタンスガイドラインの作成
さてさて、本題に戻りまして。
コンポーネントの設計方針は大枠決まりましたが、運用する際の懸念は解消できていませんでした。特に問題になっていたのが、コンポーネントのインスタンス問題です。
Figmaのインスタンスにはかなり変更を加えることができます。文字はもちろん、カラー、角丸、影など基本的なスタイルはすべて変更できてしまいます。
とてもありがたいことではありますが、管理の観点では以下のような懸念が絶えませんでした。
- このまま共通コンポーネントを配布しても、色々な変更が加えられてしまうかも
- エンジニアはインスタンスに加えられた変更に気づけないから、確認の工数が大きくなりそう
そんな懸念を解消するために定義したのが「インスタンスガイドライン」というものです。
インスタンスガイドライン？
インスタンスガイドラインとは、各コンポーネントのオーバライド可能範囲を明記したものです。
Figmaのプロパティと照らし合わせて変更を加えて良い箇所について説明をしています。
例えば、チェックボックスのコンポーネントでは、横幅の変更が可能で、場合によって背景色や枠線のカラー変更も許容しています。
チェックボックスコンポーネントのインスタンスガイドライン
もちろんルールをガチガチに固めたり、発生するパターンごとにバリアントやコンポーネントを増やすことも1つの手ではありますが、レバテックではすべての状況をカバーすることはできませんし、ユニークコンポーネントの管理コストが発生します。あくまでもコンポーネント化は効率化のための手段の1つなので、そこにコストをかけるのは本来あるべき姿ではないと思っています。
私たちは、ルールの範囲内でできる限りの柔軟性を提供することで、コストを少なくコンポーネントを運用したいと考えています。（その基礎を作るのにはかなりの時間をかけていますが！（笑）未来への投資です！）
何が良かった？インスタンスガイドライン
という2点です。守って欲しいこと、変更可能なことが明確に定義されていることで、個人で意思決定をして進めることができます。また、エンジニアも、インスタンスガイドラインを参照すれば、マスターコンポーネントから加えられている変更を一目で把握することができ、いちいちデザイナーに確認する手間が省けるようになりました。
まだまだ、作成中のコンポーネントも多く本導入はできていない部分もありますが、デザイン制作・開発の生産性向上に寄与してくれる良いものになるのではないかと感じています。
『VoLT』はまだまだこれから
ここまで読んでいただき、ありがとうございました。
今回は、プロダクトを横断したコンポーネント管理についてお話しさせていただきました。参考になる部分が少しでもあれば幸いです。
色々書きましたが、『VoLT』はまだまだ構築中で、成長段階です。
コンポーネント管理についても、ユニークコンポーネントの管理方法はまだ定まっていないなど、決めてなくてはいけないことがたくさんあります。また、すでに定義した部分に関しても、運用に入ったからこそ見える課題も多くありますし、日々試行錯誤を繰り返しています。
問題を解決し切るにはまだまだ道のりは長いです。
多くの知見と協力者が必要なため、一緒に戦ってくれる方を大募集中です⚔️
興味のある方はぜひ一度お問い合わせください！
レバテック開発部の公式XのDMからでも大歓迎です！
ありがとうございました！
Discussion