Figmaアップデート前後のコンポーネント作りを比較してみた

はじめに

こんにちは、デザイナーのnaa(@sai_fan_3)です。

5月11日の夜、Figma Config 2022でメジャーアップデートがリリースされました。

Figmaに投資しているJohn Lillyが "Designing products, like everything else we do, is a team sport, but it was held back by the tooling." ( "The Decade of Design”: How 10 years transformed design’s role in tech )と言っていたように、チームスポーツのような「デザイン」というプロセスにおいて、ツールが障壁にならないようにするアップデートでした。さすがFigma……

折角なのでestieデザイナーのkenaraiさん(@rakenarai)とアップデート前後のコンポーネント作りを比較してアップデート内容を振り返りました。

アップデート前後で変化したコンポーネント作成

1. Auto Layout時のネガティブマージン

Figmateのみなさんもご存知の通り、今回のアップデート前は Auto Layoutで要素間のネガティブマージンを指定できませんでした。

その時、次のような切り替えボタン(Segmented controls)をどのように表現していたか聞いてみました!

kenarai の場合

私は今までこのようなUIを作る際、できるだけ少ないレイヤーで構成することと、できるだけ手動で要素を配置しないことを意識して、Inner shadowとAuto Layoutを使っていました。

まず、次のようなボタンのコンポーネントをAuto Layoutで作成します。余白と背景色の指定に加え、Inner shadowを以下のように指定しています。

このボタンを必要な数だけAuto Layoutで並べます。

あとは右端のボタンのInner shadowをOverrideする形で消し、3つのボタンを横に並べたAuto Layoutにshadowと同じ色の枠線と角丸を指定し、Clip contentにチェックをして角丸からはみ出したボタンの隅を削れば完成です。

このようにしてBorder用の要素を作らず、GroupやFrameによる手動の位置調整もせず、複数ボタンが並ぶUIを実現していました。

ただ、Inner shadowで内側に線を引いているため、余白の指定状態が以下のようになってしまいます。

画像の通り、厳密に言うとInner shadowで影をつけている方だけ余白が影の太さ分小さくなってしまいます。 これを回避するため、Inner shadowを指定している方向のみAuto Layoutで余白を「11px」にするということも可能ですが、一辺だけ1pxだけ異なる余白を設けるのは気持ち悪いですし、何よりこの指定を見た他のデザイナー・エンジニアが意図を読み解くのは難しいように感じていました。

余白は10pxだよ!ということを優先してAuto Layoutに余白を指定すると、実はInner shadowをつけた方向だけ余白が10pxではない。その一方、全ての余白を同じ見た目にするために、Auto Layoutで一方向だけshadowの分だけ大きい余白を指定するのも気持ち悪い。そんなジレンマを感じながら、かなり俺俺ルールでデザインを進めていました。

ちなみに、Drop shadowを使ってBorderを表現しても同じ問題に直面します。 どちらのshadowを使おうが完璧の状態にはできないため、私はDrop shadowはOpacityやBlurを指定した、いわゆる「影」を表現するために使い、Inner shadowは一方向のBorderを表現するために使っていまいした。これも俺俺ルールですね…笑

naa の場合

私は次のようにボタンを分割した状態のコンポーネントを作り、重ねて表現していました。

はじめにテキスト要素にAuto Layoutを設定して、デフォルトコンポーネントとする角丸0 pxの中央のアイテムを作ります。

アイテムの配置が変わった時のスタイルを状態管理したいため、作ったコンポーネントを複製して、左に角丸を持たせたコンポーネント、右に角丸を持たせたコンポーネントを作り、variantにleft, center, rightの状態を持たせてCombineします。

作成したコンポーネントを使う数だけ配置して、左右端にあるコンポーネントに対しては先ほど設定したleft, rightをvariantで指定していました。これらをAuto Layoutで並べたいのですが、アップデート以前はAuto Layoutで要素間のマージンに対して正の値しか指定できなかったため、線が重複していました。

それを避けるため、アイテムを1px重ねGroup化していました。

完成状態を分割したコンポーネントは、私にとって直感的でスムーズに作れるメリットがありました。しかし、Auto Layoutを指定していないため、アイテムの中身が変わったり、アイテムの数が変わる場合に全体のレイアウトが崩れてしまい、都度手動でレイアウトし直すことはデメリットでした。

今回のアップデートを利用した場合

今まではGroup化していた重なるパーツもAuto Layout機能を設定できるようになりました。

variantを設定したコンポーネントをAuto Layoutで並べて-1pxのマージンを指定するだけで表現できるようになりました。アイテムの中身が変わった時も、レイアウトが自動で調整されます。

2. Auto Layout時のAbsolute配置

2つ目もAuto Layoutでレイアウトを組む際に対応できなかった部分です。Absolute指定したい要素をAuto Layoutが指定されている要素に被せて配置することができませんでした。

以下のヘッダーを表現する時には、どのように作成していたのかを聞いてみました!

kenarai の場合

このようなUIをFigmaで再現する際、バッジをどう配置するかが悩みの種でした。極力Auto Laytoutでシステマチックに作るという考えに加え、私はレイヤーのネストを深くしたくない派でもありました。
ただ、左にロゴ・右にアカウント情報があるヘッダーをAuto Layoutで配置できても、バッジをアイコンの右斜め上に配置することはできなかったので、このようにバッジ要素をAuto Layoutの外に出し、Group化することで実現していました。

ただ、この方法で辛かったポイントは、文字が長くなるとバッジの位置がズレてしまうことです。

naa の場合

私もバッジ要素をAuto Layoutの外に出し、Group化することで実現していました。 バッジを移動しようとしたときに、Auto Layoutで配置しているヘッダーをロックしないと、バッジがAuto Layoutの中に含まれてしまうことも辛いポイントです。

今回のアップデートを利用した場合

アップデートで追加されたAbsolute配置を使えば、フレームに対して配置のルールを明確に定義することができます。つまり、Auto Layoutが設定されているコンポーネントに対して、要素を追加する場合にも作り直すことなく配置できるようになりました。

また、Groupを使うことによってネストが深くなることもなければ、文字量などの変化によってバッジの位置がおかしくなることもなくなりました。

3. 個別ストローク

estieのプロダクトでは次のようなテーブルを作る場面が多いので、最後に個別ストロークに注目しました。

アップデート前は、四方全辺へのBorder指定しかできませんでした。下一辺にBorderを引きたい場合はどのように表現していたのでしょう。

kenaraiの場合

1つ目に紹介した、複数ボタンを並べるUIの作り方といくつか重複しますが、私は一辺のBorderをBlur無し・Opacity無しのInner shadowを用いることで表現していました。

できるだけ要素の数を増やしたくないという理由でshadowを使っていましたが、線の役割を影の機能で満たすというトリッキーさから、初見殺しの指定をしている自覚もありました。

またDrop shadowとInner shadowの2種類があるので、一辺のBorderをshadowで指定すると決めても、Drop shadowを使うかInner shadowを使うかチームで完璧に統一するのは難しそうだなと思っていました。

naaの場合

1pxのレクタングルを用意して、テーブルの1列とレクタングルをFill containerに設定して、Auto Layout機能で囲んでいました。 常にテーブルの1列とレクタングルが同じ長さに調整されることの利便性を優先して、要素が増えることには目をつむっていました。

今回のアップデートを利用した場合

CSSでの指定と同様にborder-leftやborder-bottomという指定ができます。これにより、FigmaとCSSの間に表現の差がないため実装方法も明解になりました。

まとめ

naa: 普段Figmaの細かい表現方法を議論することは多くありませんでしたが、kenaraiさんと話をして今回のアップデート範囲でも細かな手法の差があることがわかりました。そのコンポーネントもAuto Layoutを設定できたんだ!という発見があったので、たまにUIを作るための手法について議論してみるのも良いなと思いました。

kenarai: かなり指定の仕方に違いがありましたね…!estieの他のデザイナーに聞いてみても結構違いが見つかりそうです。これまでは、良く言えばデザイナー各自の創意工夫、悪く言えば共通化されていない自分ルールがデザインファイルのあちこちにありました。今回のアップデートは特に痒い所に手が届く秀逸なものばかりで、これによってデザイナー間である程度ルールが統一されそうな機運を感じました。

naa: 今回のアップデートによって、作成方法で悩んでいた部分が解消されたりメンテナンス時の修正箇所が削減されたり、前よりシンプルにコンポーネントを作れるようになったと感じます。今後さらにデザイナーが増え、今よりもさらにメンテナンスしやすいデザインファイルを作ることが大事になってくるので、どんどん今回のアップデート機能を活用していきたいと思いました!

最後に

estieではPdMがロードマップをひく時や、チームでレトロをする時など、会社全体でFigmaを活用しています。少しでも会社に興味を持ってくださったFigmateのみなさん、カジュアル面談で話しましょう〜!

▼ カジュアル面談

hrmos.co

▼ 採用ページ

hrmos.co

© 2019- estie, inc.