Zenn
レバテック開発部
🎨

【便利tips】Figmaでデザインデータを作る時のイロハについてデザイナーに聞いてみた

Takuya
2024/03/05に公開
Figma
デザイン
tech

はじめに

レバテック株式会社で主にサービスサイトのディレクターをしている山本です！
普段はデザインシステムや、デザインの制作進行管理などをメインで担当しています。

レバテックでは、Figmaというデザインツールを用いて多くのメンバーがデザイン制作を行なっているんですが、いろんな人が各々のやり方でデザインデータを作成するので、属人的なズレがたくさん発生し、コミュニケーションコストや内部品質管理などの色々な問題が起きていました。

  • 例
    • Auto LayoutとFrameが混在
    • コンポーネントのプロパティ名がバラバラ
    • etc...

私自身、フロントエンドの理解はありつつもレバレジーズに入社してからFigmaを触り始めたため、社内のデザイナーにちょこちょこ質問を投げかけて勉強していました。当たり前に使っているtipsでも意外と「知らなかった」ような内容もたくさんあり、今回は私が「これは賢い！」と思ったTipsやレバテック内でのルールを8つご紹介します！

前提

この記事は 「Figmaでのデザインデータ」について解説 しているため、「かっこいいデザインを作るtips」は載せていません。
また、Figmaを普段から使っている人向けの内容になっているので、Figma用語についての詳細は省略しているのでご了承ください。

1. ショートカット覚えて、ビッグナッジを8にしてね

  • ショートカット覚えてないと作業がいつまで経っても速くならないんで、頑張りましょうw
  • UIデザインでは基本的に「4か8の倍数」で構成されているので、オブジェクトの値をキーボードで変更する（Shift + 矢印）とき、ビッグナッジが8pxだとめちゃめちゃ楽です
    • 人によっては4pxでも良いです

参照

2. 基本的には全てAuto Layoutで組んでね

  • Figmaには上記3つの「アイテムを囲む」機能がありますが、ほぼ例外なく全てAuto Layoutでデータは作ってください
    • 忘れがちですが、コンポーネントを囲う紫の点線エリアも全てAuto Layoutの設定をしてください

2.1 画像データとして書き出すものは例外

  • イラストやアイコンなどは親要素のサイズを変更しても、中の要素が自動変更できるようにFrameかGroupでのデータ作成を推奨します

参照

3. コンポーネントをしっかり作ってね

3.1 コンポーネントにすべき判断軸

  1. パターンが存在している
    • アイコンなど、似たような場面で使うがパターンが必要なもの
    • 例：アイコン、見出し、「3つの特徴」など同じレイアウトのもの、etc...
  2. 動的でステータスが存在している
    • ボタンなど、クリッカブルな要素
  3. 他ページでも使用する
    • フッターなど、現在作業しているページ以外でも使用するもの
    • これに関しては、すでにコンポーネント化されている場合もあるので、マスターデータを確認してから判断する

3.2 コンポーネント作成時の注意

  1. インスタンスのデータをいじるな
    • プロパティ以外何も触るな
    • もしサイズや色などを触る必要が出てきたら、それはコンポーネントの登録がミスっているに他ならない
  2. Hover時やActive時など、2パターンしかない場合は値名がTrue / Falseになるように管理
    • 例：プロパティ名「Hover」、値名「True / False」
  3. 似たようなコンポーネントを作らない
    • 微妙にサイズが違ったり、似ているものがたくさんあるのはコンポーネント管理の破滅の一歩目
    • 管理コストを考える上でも、似たようなものは「揃えられないか」を意識する
  4. パターンがあるなら、とりあえずコンポーネント作っとけ
    • ペライチものの制作の場面ではコンポーネントが縁遠いものに感じられるかもしれませんが、作業効率のために積極的に活用
    • 見出しや3つの特徴、よくある質問、ボタンなど、同じレイアウトでテキストや色だけ違うものはとりあえずコンポーネント化です
      • 主なメリットは修正が発生したら即時反映されることで、修正もれが防げるので基本マストです
  5. 何でもかんでも「Num」や「Type」にするな
    • 便利なプロパティ名で管理しきらない
      • 汎用性が高い命名になるため、できるだけ控える
      • 悪い例：「State：Active / Default / Default-PC / Active-PC」
      • 良い例：「Active：True / False、Device：PC」
  6. 1個のプロパティで乗り切るな
    • 連番のもの（例：Num、Size）以外は、しっかり分ける
    • 悪い例：「Type：PC-Active / PC-NotActive / SP-Active / SP-NotActive」
    • 良い例：「Active：True / false、Device：PC / SP」
  7. テキストプロパティちゃんと入れてね
    • 表示・非表示の要素はvariants管理じゃなくて、ちゃんとboolean管理にして

3.3 困った時のVariantsプロパティ名

  • Hover、Active、{ステータス名}
  • Device
    • PCとSPで分けたい場合
  • Type、Num
    • 01、02、03、etc...で分けたい場合
    • 昇順降順で管理できる場合
  • Size
    • Small、Middle、Largeで分けたい場合

また値名については、無理に英語にしなくても分かりやすいように日本語でも良いです

4. 何でもかんでも「絶対位置」で配置しないよ

  • 絶対位置（Absolute Position）は便利に位置を移動できる機能ですが、この機能多用していたらAuto Layoutで作った意味がなくなります
    • 乱用は控え、可能な限りAuto Layoutで組みましょう

4.1 制約（Constrains）をちゃんと指定するなら使っていいよ

  • position: absolute;の使い方が正しく反映できる場合はOKです

5. WidthやHeightのサイズ指定はちゃんとしようね

  • サイズには「Width」「Max Width」「Min Width」の3種類、サイズ指定には「Fixed」「Fill」「Hug」の3種類があります
  • ちゃんと指定しないと実装時に分かりづらかったり、別の場所で使用したときに崩れたりするので、ちゃーんと指定する必要があります
  • 基本的にはこれが判断軸で、作成時のTipsについて以降に記します
    • Fixed：自分が設定した値以外には可変しない
    • Hug：コンテンツサイズで要素を可変
    • Fill：入っているボックスのサイズに合わせる

5.1 親要素でFixed指定してたら、その子要素にはFill指定する

  • 親要素のサイズが変わったとしても子要素が可変される
    • 例：コンテナとその中身

5.2 複数カラムレイアウトで、片方がFixed指定の場合はもう片方はFill指定する

  • 2カラムの場合
    • 例：サイドメニューとメインセクション

5.3 Fixed指定した場合、Paddingは指定する必要ないことが多いよ

  • Paddingを設定する場合、サイズは可変であることが前提な場合が多いので
    • 例：Height: 40px;で上下中央揃えしている場合、上下Paddingを指定しても意味ないよね

5.4 コンポーネントは使用する箇所に適した指定をする

  • ただただコンポーネントを作成すると自動的にHugかFixedになります
    • 使用箇所でFill指定する場合はコンポーネント自体をAuto layoutして、Fillにしておく必要があります

6. コンポーネントは必ずグループにしてね

  • 上記でも話しましたが、コンポーネントのサイズ指定をしたい場合、単体のコンポーネントだとHugかFixedしか指定することができないので、どんな場合でも何かしらVariantを追加してグループにしておきましょう
    • 紫の点線の枠線が周りを囲っているものを「コンポーネントのグループ」と呼んでいます
  • 特にバリエーションがない場合でも、とにかく設定です
    • 「Device」か「Hover」がおすすめです

7. GapにAutoはあんまり使わないほうがいいよ

  • ヘッダーなどで重宝する便利な機能なんですが、リストの場合はサイズ可変のオブジェクトが右のオブジェクトにぶつかって、折り返しされる時に間隔が0になってしまします
  • 結局はサイズ可変のオブジェクトのwidthをfillに、もう片方をFixedかHugにして、Gapに値を設定したほうが良い場合がほとんどです

7.1 要素同士が重なっても良い場合はOKだよ

  • 例：左側のテキストと、右側の人物画像が被っている
    • 中の要素が2つともHugやFixedの場合はGapがAutoでないと、この表現が実現できないためOKです

8. 折り返し機能は便利だけど、現段階では時と場合によるよ！

  • 近年Fimgaに登場したWrap機能によって、デザイナー界隈は大いに盛り上がりまくりました
  • 主に「タグ機能」の見せ方で重宝するWrap機能ですが、中のオブジェクトがFixedかHugのみの場合の利用に限定します
    • 逆に実装時にFillや%指定を使いたい場合は厳禁です

8.1 数カラム構成のカードなどはNGだよ

  • 実際、中のカードはWidthがFixedに指定されています
  • このようなデザインの場合、ぱっと見何も問題なさそうですよね
  • しかし、レスポンシブなデザインを考える上で、こういった3カラムのカードのWidth全てがFixedではなく、本来は%などで指定されるべきものです
  • 例としてレバテックキャリアのTOPページ内の求人特集（4カラム）のカードのCSSを例にすると
    • width: calc((100% - 80px) / 4);
  • こういった表記になっています
  • Figma（2024/01/30時点）ではサイズへの%指定が不可能であり、Figmaでの実装上の完全再現は不可能となっています
  • そのため、Wrapでの指定ではなく、一列ごとにAuto Layoutを指定し、それぞれのカードのWidthにFillを指定することを推奨します

おわりに

Figmaというサービス自体、ありがたいことにアップデート頻度が高いです。常に最新のトレンドを把握し効率的に開発を進めるためには各自の専門性の向上や、組織としての取り組みが必要不可欠です。

レバテックは、デザインシステムや横断的な組織改善に興味のあるエンジニアやデザイナーを募集中です！
ご興味のある方はぜひ以下からご連絡ください！
https://hrmos.co/pages/leverages/jobs/A_c_00057
https://hrmos.co/pages/leverages/jobs/A_d_00018

上記以外にも様々な職種を積極的に採用中です！興味のある方は是非カジュアル面談などでお話ししましょう！
https://hrmos.co/pages/leverages/jobs

レバテック開発部
レバテック開発部

レバテック開発部の公式テックブログです！ レバテック開発部 Advent Calendar 2024 実施中: qiita.com/advent-calendar/2024/levtech

Discussion