デザイナーとしてご活躍されている方々の中には、Figmaを使用しながら作業をする上でデザインファイルをどのように共有・連携したら良いのか、コンポーネントの作成や設計について悩まれている方も多いのではないでしょうか。

そこで、「デザインファイルを属人化させないFigma活用・コラボ方法 Part2」では、現在すでにFigmaを活用されている方に向けてFigmaを更に効果的に活用していただけるヒントを、ロンドンを拠点にフリーランスプロダクトデザイナーとして活躍されている「キャシさん」に教えていただきました。
Part1はこちら：【イベントレポート】デザインファイルを属人化させないFigmaの活用法を探る。

この記事で得られる学び

  • 拡張性のあるUI設計について学ぶことができる
  • コンポーネント設計について知識を深く掘り下げることができる
  • デザインシステムの構築と維持に大切なことを知れる

1. デザインファイルを属人化させないFigma活用・コラボ方法 Part 2


Figmaの活用は、デザイナーがチームと一体となってプロジェクトを進め、デザインファイルの属人化を防ぐ手助けをしてくれます。前回のPart1では、Figmaを使用した具体的なデザインファイルの共有方法と実践方法を教えていただきました。今回は「デザインファイルを属人化させないFigma活用・コラボ方法 Part 2」として、現在ロンドンを拠点にフリーランスプロダクトデザイナーとして活躍されている「キャシさん」に将来を見据えた画面・コンポーネント設計を中心にお話ししていただきます。

2.登壇者紹介


キャシ 氏
プロダクトデザイナー／Figma Community Advocate

ロンドン拠点フルリモートで8つの時間帯をまたいで働くフリーランスプロダクトデザイナー。現在は株式会社カケハシのチームKUSABIにてお薬連絡帳Pocket Musubiの管理システム・アプリUX/UIデザイン、Figma勉強会などに従事。PM、エンジニアと一緒にデザインを作り上げていくスタイルが好き。最近はイタリアでのワーケーションにハマっている。
Figma Community Advocateとして、Figmaの魅力を発信する勉強会やセミナーで多数登壇。

キャシ氏

3. 拡張性のあるUI設計について

デザインが壊れてしまう主な要因

デザインを行う際に、拡張性のあるUI設計はとても大切です。まず拡張性のあるUI設計についてお話しする前に、デザインが壊れる要因としてよくあるものをお伝えしたいと思います。最初に覚えておいて欲しいことは、「度重なるデザイン変更」と「事業側決定の影響」についてです。

例えばスタートアップで多く採用されているアジャイル型開発の場合、開発メンバーだけではなくチーム全体で、開発しているものやデザインするものについて優先度に順番をつけ、短いスパンで納品やリリース目指して動いています。そのため毎日のミーティング実施や、チーム内でスムーズに連携が取れるようなスクラムと呼ばれる手法が主に取られています。そうすると開発が始まった後でも、要求や仕様の変更は頻繁に起こり、その度重なるデザイン変更がデザインの崩壊に繋がります。

拡張性のあるUI設計がなぜ必要なのか

デザインが壊れてしまう要因でもう一つ主に考えられるのは、「自由奔放なデザイン」です。デザイナーがデジタルデザインのルールを知らないということは少なくありません。またアジャイル型開発だと特にそうなのですが、基本的な設計をする際に具体的な形がないところから設計を始めていかないといけないため、色々な内容を盛り込んでしまいがちです。

そのため、明確な根拠がないまま進んでしまい、実装ができないデザインになってしまう=デザインが壊れてしまうということに繋がります。
それらを防ぐために拡張性のあるUIを最初から設計する必要があるのです。

拡張性のあるUI設計って？

それでは拡張性のあるUI設計とはどのようなものでしょうか。お伝えさせていただきたいポイントは3つ。まず1つ目は既存部品の組み合わせで新しいMoleculesとOrganisms、Templatesを作り出せること。次に、見た目の一貫性を保持しつつ機能の追加・削除が可能であること。これは例えば、B to B向けのものを作成する場合、画面の数が何百と増えてしまいます。その全てのレイアウトを自由奔放に決めてしまうと全く使えないものになってしまうため、レイアウトのルールを部品単位だけではなくページ単位でもパターン化し設定しなければいけません。

画面全体がきちんと整理されていて、実装の難航やユーザー自体が迷子になってしまうことを防ぐために、操作や見た目の一貫性を保ったまま機能の追加・削除が可能であることが条件として必要となってきます。つまり拡張性のあるデザインとは、変更に強く実装チームの負荷にならないデザインのことを示しています。

Figma活用法Part2_拡張性あるUI設計

拡張性のあるUI設計を実現するために

次に、拡張性のあるUI設計を実現するために、具体的に考慮すべきポイントをお伝えします。こちらも主に3つあります。まず1つ目は「事業側の目標を知る」ということです。これは物事を上空から見るように全体的な視点を持つことで、事業側だけではなくお客様の視点、運用面での視点など立場を変えて考えた時に、目の前のデザインはどのようなインパクトを与えるのか、使い勝手はどのようなものかなどを考えながらデザインを設計するということです。

2つ目に、「構造とはUX+API/データ」ということです。ここでいう構造とは情報設計の話で、UXのことは皆さんもちろん考えると思うのですが、実装者にとっての構造とはAPIとデータを示します。そのため、UXだけを考慮した画面構造だけではなく、実装者が見るときにデザインがどこのデータベースのものなのか、どのAPIなのかを考慮する必要があります。

その際に大事になってくるのが、3つ目の「部品・画面をパターン化」です。画面の骨格を全く別々に考えることはできません。結局、進めていった先に実装できなかったり、性能自体に問題があるプロダクトになってしまったり、運用に負荷がかかるようなものになってしまったりするのを避けるために、部品画面をパターン化する（コンポーネント化する）ことがとても大事になってきます。

Figma活用法Part2_拡張性のあるUI実現のために

4.デザインシステムの構築と維持

デザイントークンとは

デザインシステムの構築と維持には、デザイントークンというものがとても大事になってきます。デザイントークンとは、スペーシングや色、タイポグラフィ、オブジェクトスタイル、アニメーションなどデザインシステムの構築と維持に必要な全ての値をデータとして表現したものです。色はRGB値、不透明度は数値、アニメーションはベジェ座標などデザインで定義されたあらゆるものを表現することができます。

デザイントークンのメリットとしては主に「唯一のデザイン参照元」「UIの一貫性」「柔軟・迅速なスケールアップ」が挙げられます。
まず「唯一のデザイン参照元」についてですが、例えばプロダクトのチームやエンジニア、UXデザイナーなどの複数のメンバーが同じ製品に取り組んでいる場合、誰もが同じデザインツールのもとプロジェクトを進める必要があります。デザイントークンはその際にデザインルールの唯一の参照元を形づくる非常に重要な役割を果たしています。

デザイントークンのメリット

次に「UIの一貫性」についてですが、まず知っておいて欲しいこととして一貫性のないUIというのは、ユーザビリティだけではなく最終的にはブランディングのイメージにもダメージを与えてしまう様々な問題を引き起こしてしまいます。それどころか、リリースのたびにエンジニアリングとUXデザインの負債が少しずつ溜まっていってしまいます。
そこでデザイントークンを使用すると、その負債の予備軍自体を解消し、全てのデザイナーが同じスタイルとプロパティを使用して設計できるようになる強みがあります。

最後に「柔軟・迅速なスケールアップ」についてお伝えします。デザイントークンは、製品やデザインシステムの変更に対して柔軟な対応を可能にしてくれます。それにより拡張性が大幅に高くなり、普通であればプラットフォーム固定のプロパティを追加したい際に手間がかかっていたものを、デザイントークンを使用することで既存のデザイントークを更新するだけで全て変更が可能です。

その結果、プロセス自体もスピードアップかつスケールアップしやすく、エンジニアの方々はエラーや不整合を少なくして新しいプロジェクトを非常に早くリリースすることができます。

Figma活用法Part2_デザイントークンの利点

5.コンポーネントの重要さ

コンポーネントは何を担うのか

コンポーネントというと、デザイナー側が作成してエンジニアリングの実装チームに手渡していると思っている方もいらっしゃるのではないでしょうか。実はコンポーネントは、元々エンジニア側のフロントエンドの方々がずっと使用していたコンセプトなのです。
コンポーネントを使用してデザインすることでコンポジションや構成、インヘリット、無制限のオーバーライドなどの概念を、デザイナー側がエンジニア側に歩み寄って取り入れています。つまりコンポーネントとは、エンジニアリングとデザイナー側の共通言語と言えます。

またコンポーネントを使用されている方々の中では、「再利用」が一番のメリットだと考えている方も多いのではないでしょうか。コンポーネントを使った設計は、特に大きなシステムや画面数が多いプロダクトのデザインをしていると、とても利点を感じやすいです。

例えコンポーネントがない部分を設計していても、すでにある大きなコンポーネントのルールやパターンから小さい部分について推論を立てることが簡単にできるようになります。コンポーネントを再利用することで工数をはじめとした全てのコストを節約することができるのは、大きな利点なのではないでしょうか。

また、仮にコンポーネントを使わずに設計した場合を考えると、そのプロジェクトやプロダクトの成長や進み具合においてデザインや構成自体が自由奔放に派生してしまい、一貫性がなくなってしまいます。そのようなことを防ぐためにも、Atomic DesignでいうAtom段階の単位の時からちゃんと設計することで、全体デザインの整合性を担保することができます。そういう重要な役割を担っているのが、コンポーネントです。

良いUIコンポーネントを設計するために

それではより良いUIコンポーネントを設計するにはどのようにしたらいいのでしょうか。
コンポーネントの裏側をきっちり理解した上で、具体的に考慮に入れるポイントとして「ゆるいAtomic Design」「メンバー全員の共通認識」「トークン+レベル別」が大事だと考えています。

メンバー全員の共通認識は、特にデザイナーチームと実装チーム間で認識を合わせることが大切です。そのため1から10まで全て決められたAtomic Designで設計してしまうと、定義の定義をしないといけない作業が発生し複雑になってしまうため、ゆるいAtomic Designが必要になります。

また「トークン+レベル別」というのは、先ほどお伝えさせていただいたデザイントークンと、コンポーネントのレベル別を表しています。コンポーネントのレベルは、レベル1がAtomで少数単位、レベル2が分子単位、レベル3はレベル2と比べてより複雑な分子、というように作成しています。
ただしここでもやはり、厳しくルールを設定してしまうと非常に複雑になってしまうため、ある程度のゆるさが必要になってきます。

良いUIコンポーネントを設計するためには、同じUI要素なのに表層と裏側ではかなり違うプロパティで構成されていると理解し、さらにそれをチームメンバー同士で共通認識にしておくことが非常に大事になってくるのです。

Figma活用法Part2_コンポーネントプロパティ

6.質問コーナー


最後に、参加者の方からの質問に答えていただきました。

Q1.コンポーネントの作成基準はなんでしょうか？またいつ作成していますか？

A.コンポーネントは最初からLocalコンポーネントとして作成しています。3回以上適用したらLibraryに入れてPublishしています。

Q2. レスポンシブデザイン用の作り方はどうしていますか？

A.まずAuto Layoutを適切にかけています。その他、Webアプリ・サイトの場合はAndroidの横幅想定を大事にしています。

Q3.コンポーネント作成時のプロパティ選択や、Variantで対応する判断ポイントを教えてください。

A.プロパティはサイズ、アイコンの有無、タイプステートなどを大事にしています。またVariantについては
「複数の類似かつステート、サイズ、レイアウトなどのプロパティが同じコンポーネントの場合」
「2つのコンポーネント間でBoolean（true/false）でトグルできる場合」
「Reactのようなフロントエンドフレームワークで使用されているprop/valueフォーマットに従って、コードコンポーネントに沿ったプロパティにマッピングされている場合」
の3つの場合は使用OKにしています。

Figma活用法Part2_Variant使用OK

一方で、
「Variantを追加することで管理できない数のバリエーションになる場合」
「色やテーマのバリエーションごとにVariantを作ってしまい管理不能になる場合」
はVariantの使用をNGにしています。

Figma活用法Part2_Variant使用NG

7.まとめ


今回はデザインファイルを属人化させないFigma活用とコラボ方法を、前回のPart1よりもさらに深い観点でお話していただきました。これまでなんとなく使用していた方も、今回学んだ新しい認識と使い方で、チームでのプロジェクトに貢献できる一歩を踏み出す準備が整ったのではないでしょうか。ぜひ何か一つでもお持ち帰りいただいて、これからの活躍に役立てていただければと思います。