見出し画像

フロントエンドの開発を少し楽にするFigmaでのコンポーネントデザイン

kiiita

こんにちは。
株式会社Caratでロボキャリアアドバイザーアプリ「GLIT」のUIデザインとフロントエンド開発を担当している北國です。

プロダクトを成長させる過程で日々機能の追加・変更・削除があるわけですが、UIデザイナーとしてはそれらの変更に強いFigmaファイルを作り、できるだけ無駄なUIデザインの工数(※1)を削減したいという想いがあります。

また、UIデザイナー目線だけではなく、フロントエンドエンジニアが開発しやすいFigmaファイルを作り、開発の効率を良くしたいというのもデザイン業務をする時にできる限り意識しています。

それら2つのためにはFigmaでのコンポーネントの作り方が結構大事だと思っていて、実際にどのような工夫をしているのかをご紹介します。

エンジニアがFigmaのコンポーネントを見た時にpropsを正しく把握できる状態にする

FigmaのUIコンポーネント管理が散らかってきて困っている方や、UIコンポーネント開発の際にフロントエンドエンジニアとのコミュニケーションコストが大きくなってきているなあと感じている方の参考に少しでもなれば幸いです。

※CaratではフロントエンドをReact(React Native)で開発しています。

Figmaを使ったデザイン・開発でのよくある課題

フロントエンドエンジニア目線

フロントエンドエンジニアがFigmaを見てUIを実装する時に困るケースは以下のようなものがあります。

  • FigmaのUIコンポーネントを見ただけではどのような状態やプロパティ(state, props)が必要なのかわかりづらい🤔

  • コンポーネントAに含まれているコンポーネントBが、既に実装したコンポーネントなのか新規のものなのかがわからない🤔

e.g. フロントエンドエンジニアがこのFigmaを見た時の感想「この2つのコンポーネントは1つのコンポーネントとして扱っていいの？別ファイルで作ったほうがいいの？」

UIデザイナー目線

  • プロパティをあまり活用しておらず、1つのコンポーネントに対して複数のパターンのコンポーネントできてFigmaが散らかる😥

  • プロパティ管理をしていないため、コンポーネントに新たな状態が追加された時に、そのコンポーネントを使っているスクリーンUIの方の変更が手間になる😥

e.g. 1つのコンポーネントに対してパターンが増えてきて、どれがどの状態に対応しているのかコンポーネント名で管理するものの可読性・保守性が悪い状態。


このような課題感に対して、Caratでは「フロントエンド開発を意識してFigmaでのコンポーネントプロパティの活用する」ことでデザイナー・エンジニア両者の業務効率が上がるように取り組んでいます。

フロントエンド開発者が実装時に困らないようにComponent Propertyを使う

上述のような課題を解決するために、この記事ではComponent Propertyを使う方法をご紹介します。

決して華々しいTIPSというわけではなく、当たり前のことを丁寧にやることでデザイナーもエンジニアも開発・運用が効率的に進められればいいね、というアプローチです。

先日のFigmaのアップデートでComponent Propertyの機能が更に強化されました。このアップデート以前からCaratではComponent Propertyを使ってフロントエンドとの連携をできるだけ滑らかにしていましたが、今回の機能強化によって更に連携がしやすくなり、CaratでもFigmaの既存コンポーネントを徐々にComponent Propertyへの移行を進めています。

では具体的にどのようなComponent Propertyを使っているのかですが、フロントエンドエンジニアがFigmaを見れば、型定義や変数名が読み取れる・参考にできるようにしています。

具体例がないとわかりづらいので、Input系のComponentを例にしましょう。以下のようなTextInputコンポーネントを作る場合を想定します。

上: 単位付きのTextInput
下: 単位なしでエラー時のTextInput

このFigmaファイルでは、TextInputというコンポーネントについて2パターンFrameが用意されていて、エンジニアはこれを見てTextInputを実装します。

もしComponent Propertyを使わずにこれら2つのFrameだけを見て実装するとなると、このTextInputが持つ状態をエンジニアが推測して実装することになります。

「上のTextInputの右にある人というテキストは何？」
「人というテキストは固定なの？可変なの？表示しないケースもあるの？」

もちろんそれで問題はないし、この例だとそこまで複雑ではないので開発効率に大きな影響はないかもしれません。ただ、コンポーネントの複雑度がました場合には認識の齟齬が発生したり、状態の考慮漏れ等に繋がることがあります。

このTableRowコンポーネントのように1コンポーネントに様々なパターンが存在する場合は、Component Propertyを使うとエンジニアは開発しやすい
良くない例(過去作っていたコンポーネント)。Component Propertyで管理されていないので、エンジニアはここから状態のパターンを推測しないといけない。

そのような問題を防止するために、フロントエンドエンジニアが状態のパターンを推測するのではなく、読解ができるようにComponent Propertyを設定しています。

具体的にどのように設定しているかですが、上記の例では実際には以下のようにComponent Propertyを設定しています。

invalid, value, unitという3つのComponent Propertyを設定している

このComponent Propertyをフロントエンドエンジニアが見れば、invalidというboolean型のプロパティがあり、「人」というのはoptionalでの単位テキストのことであるということが読解できます。まあ100%読解できるわけではないので、読解のサポートができます程度かもしれませんが。

無事コンポーネントの状態管理が読解できたエンジニアは以下のように実装ができます。

type Props = {
  invalid?: boolean
  unit?: string
  value?: string
}

プロパティ名

上記の例だとinvalid, unit, valueがプロパティ名に該当しますが、これらをデザイナーがFigmaで追加する時は、できる限りフロントエンドの実装でそのまま使えるものを考えて命名しています。

CaratではReact(React Native)での開発をしているので英語のcamelCaseでComponent Propertyも命名している。プロパティ名を日本語にすることも避ける。

これは良し悪しがあると思いますが、自分の場合ですとフロントエンド開発もやるので命名を考えることは苦痛ではなく、むしろこの段階で命名をちゃんとしていた方が開発時に考えなくて済むので楽だと感じています。

required or optional

フロントエンドの実装をする時には、そのプロパティが必須なのかどうかがわかっていると開発が少し進めやすいです。

なのでFigmaのComponent Propertyのプロパティ名でそれが読解できるようにOptionalのプロパティには接尾辞に「?」をつけています。これはCaratでTypeScriptを採用しているため、それに倣った形式をFigmaに流用しています。

この例だと「人」というunitプロパティはoptionalなので、値が無いケースを想定してエンジニアは実装できる

プロパティの値

プロパティの値はできる限りフロントエンドエンジニアが型を読み取れる形式にするようにしています。
上記の例だとinvalidはtrue/falseなのでboolean、valueはText Propertyなのでstringという読み取りができます。

また、boolean型の場合はちゃんとFigmaのプロパティの値をtrue/falseで設定することで、Figmaでコンポーネントを使う時にtoggleでプロパティの変更が可能なのでデザイナーにとっても楽です。

最近追加されたInstance Swap Propertyを使えば、Iconコンポーネントが可変であることがわかる。また、この例ではannotationプロパティはoptionalで、titleは必須であることがわかる。

この運用方法で気をつけていること

この方法で運用する上で気をつけていることがあります。

  • FigmaでのComponent Propertyの命名はあくまで参考まで。実装時にフロントエンドエンジニアが変更してもちろんOK。エンジニアの開発を少しでもサポートできたらいいな、という程度。

  • プロパティ絶対主義は避ける。FigmaのComponent Propertyは進化してるが、まだまだ全部やりたいことを実現できるわけではない。できる範囲で、完璧主義にならないようにする。FigmaやComponent Propertyで表現しづらい場合には、コミュニケーションや別の方法でカバーすればOK。

実際に運用してみてどうだったか

Caratでは今年に入ってから新規事業がスタートし、そこで独自のUI KITライブラリを作るというプロジェクトがあったのですが、そのプロジェクトもこの方法でデザイン・運用をしています。

実際にやってみて、エンジニアはコンポーネントの実装がスムーズになり、デザイナーもコンポーネントの整理ができるようになったので、今後もこの運用を続けようと思っています。

上述の通り、現状のFigmaでできる範囲で且つデザイナーの負担になりすぎない程度でのデザインファイルの運用ができればベストかなと思います。

その他にもデザイナー↔フロントエンドのコミュニケーションを滑らかにするための取り組みを色々やっているのですが、今回すべて紹介しきれなかったので、また次回ご紹介できればと思います。

新規事業でのUI KITライブラリの制作過程やデザインシステムの運用方法などを紹介する予定です。実際に運用しているUIコンポーネントファイルの一部を外部の方も見れるような取り組みも検討中です。

新規事業で作ったUI KITライブラリの一部。Figmaのライブラリ機能を使って、各プロジェクトにUI KITをimportしている(後日紹介予定)

もし興味があればnoteやTwitterでフォローをして頂けますと幸いです。

Caratでは下記職種の採用活動も行っているので、ご興味あれば気軽にDM等でもご連絡ください。

※1…Figmaやプラグインの機能を活用すれば省略できる作業


この記事が気に入ったらサポートをしてみませんか？