デザイナーと会話するためにインプットしたFigmaのこと
私はFlutterチームの一員として、デザインのコンポーネント整理に取り組んでいます。幸運なことに、私たちのチームには才能あるデザイナーがおり、Figmaを用いて再利用可能なコンポーネントをまとめてくれています。このリソースを基に、私たちは実装作業を進めています。
しかしながら、Figmaに関する知識の不足がデザインの意図の理解を妨げたり、デザイナーとの意見交換を難しくしていました。デザインの価値を最大限に活用するため、Figmaについて学んだので共有します。
この学習により、デザイナーとの共通言語を持つことができ、エンジニアとしてFigmaの管理に関する提案も行えるようになりました。基本的な知識は多くのデザイナーが既に持っているかもしれませんが、全てをデザインファイル完璧に取り入れるのは現実的ではありません。
そこで、私たちエンジニアは、デザインを批判するのではなく、改善点や提案を通じて貢献することが重要です。
FigmaにおけるComponentの活用
Componentとは
Componentとは、Figmaで複数のデザイン間で再利用可能なUI要素のことを指します。実装では、頻繁に使用される要素を別のクラスとして切り出すのと同様、Figmaでもこのような再利用が可能です。
エンジニアは、これらのComponentを複製したインスタンスをよく目にすることでしょう。Componentが作られているということは、それが再利用を意図していることを示しています。これを実装時に意識することは重要です。
左サイドバーにおける◇マークの意味
UI実装中に左サイドバーで◇マークのついたComponentを見かけることがあります。これは「インスタンス」と呼ばれ、別のComponentから複製されたものであることを意味します。
"Go to main component"を使えば、元のComponentに素早く移動できます。
Variantの利用
"Go to main component"をし、Componentを見ていると紫色の点線で囲わレているのを見かけることがあるかもしれません。
これはVariantといい、例えばボタンのように、ユーザーのインタラクションによって状態が変わる複数のComponentを1つにまとめたものです。Enable、Disable、Hoverなどの状態がこれに該当します。
UI実装では、これらのVariantのうちの1つしか表示されていない場合がありますが、Componentにアクセスすれば他の状態も準備されていることが分かります。
Variantが設定されている場合は、それが同じComponentであるとすぐに理解できますし、設定されていない場合は、エンジニアから提案を行うことが可能です。
FigmaにおけるVariantの活用は、ユーザーのインタラクションだけでなく、その他の要因によっても異なるデザイン要素を一つのComponentにまとめる際に非常に有用です。
たとえば、マテリアルデザインのボタンは外見が似ていますが、枠線の有無などの細かな違いが存在します。これらの微妙な違いを含むデザインを一つのVariantとしてまとめることで、Figma上での管理が簡潔かつ効率的になります。
このようなまとめ方はチームごとに異なる可能性があるため、具体的な実装方法についてはデザイナーに相談することが重要です。また、エンジニア側からも、実装に反映しやすい形での提案を行うことで、デザインと開発の連携をよりスムーズにすることができます。
このプロセスを通じて、FigmaのVariantを用いることは、デザインとコードの一貫性を保ちながら、効果的にプロジェクトを進めるための鍵となるはずです。
Propertyの活用
Componentにはプロパティを設定する機能があり、これは実装でいうクラスの変数のようなものです。インスタンスごとに値を切り替えることができます。例えば、アイコンの有無を切り替えるためにBooleanのプロパティを使用することができます。これは、実装上で「showIcon」のような変数でアイコンを表示非表示に切り替えるのと似ています。これらのプロパティを理解することで、見た目は異なるものの、同じComponentの異なる状態であることを認識できます。完璧なデザインの作成は難しいですが、これらの機能を知っているだけで、エンジニアは効率的に設定や提案を行うことができます。
同じComponentのインスタンスだがBooleanプロパティが異なる
プロパティには主に以下の3種類があります：
- boolean
- string
- instance swap
Figmaの効果的な命名
Componentの命名の重要性
プロジェクトによって異なるかもしれませんが、一般的にComponentには特定の名前が付けられます。Figmaの命名と実装時の命名をなるべく一致させることで、エンジニアはComponentの名前だけで関連する実装を容易に特定できるようになります。
たとえば、Figmaで「Article / Large button」と名付けられたComponentがあれば、実装では「article_large_button.dart」というファイル名を用いることができます。VSCodeなどのエディタで実装している場合、⌘+Pなどのショートカットを使用してファイル検索を行えば、素早く必要なコードを見つけることができます。
「/」の使用法とその意味
コンポーネントの名前に「/」で区切られたものを見かけることがあると思います。「/」は、Figma上ではディレクトリディレクトリのように扱うことができます。
これにより、例えば「button/primary/large」や「button/primary/small」といったComponentを作成し、ある種グルーピングのようなことができ、Componentを探しやすくなります。
実装側で同じようなディレクトリを切ることはないかと思いますが、デザインはこの区切りを利用して命名を決めたりするので参考になるはずです。
Local Stylesの活用
Local Stylesは、テキストスタイル、カラースタイル、エフェクトスタイルなど、アプリケーション全体で使用されるスタイルを指します。Figmaでは、これらの基本スタイルを変更すると、アプリ全体にわたって変更が適用されます。これはコーディングにおける変数と似た概念です。
マテリアルデザインのテキストスタイルの定義
UI実装時は右サイドバーに名前が表示されるため、コードとFigmaの名前を一致させることで、実装コストを大幅に削減することが可能です。
Nameをみれば実装と照らし合わせられる
私のチームでは、テキストスタイルやカラースタイルがFigmaと統一されていなかったため、UIごとに定義され、スタイルが無限に増えていく状態でした。現在、これらを置き換える作業を行っており、新規実装も容易になりました。また、Figmaでたとえばテキストスタイルの特定のline heightが変わった場合も、コード上では1箇所の変更で済むようになりました。
さいごに
今までなんとなくUIを実装していたのを、Figmaの知識を入れるだけでより効率的なコンポーネント設計ができたり、変更に強い実装ができると思います。
また、デザイナーとの会話も楽しくなり、仕事も楽しくなるのではないでしょうか。
他にも知っておいた方が良いFigmaの知識はまだまだあると思います。
それについてはまた別の記事で取り上げたいなと思います。
デザインやFlutter周りの発信をしていくつもりなのでよかったらZennやTwitterのフォローをお願いします。 ☺️
Discussion