はじめに

ピクセルグリッドでは、UIデザイナーである筆者が主にメインで使用しているデザイン作成ツールを、最近、Adobe IllsutratorからFigmaに切り替えました。この記事では、デザイン作成ツールを切り替えることになったきっかけとFigmaを選んだ理由、それによって起きた変化や見えてきた課題について紹介します。

きっかけ

UIデザイナーである筆者は、日常業務のデザインツールとしてIllustratorを利用していました。ご存知のようにIllustratorはデジタル媒体のアプリやページを作成することに特化したアプリケーションではありません。どちらかというと、紙媒体寄りのツールとして使われている印象があるのではないでしょうか。

そのため、Illustratorはグラフィカルなデザインを作成するには向いていましたが、Web媒体のデザインを作成するには、やや機能が不足する場面がありました。それでも、筆者がこのアプリを使い続けたのは、その自由度の高さと、デザインデータ全体を大きな設計図として利用できたからです。

しかし、フロントエンド・エンジニアとの協業を進めるには、デザインデータの共有という部分で少なからず問題があり、この部分については、ピクセルグリッド代表の中村とも「もっと効率よくできるはず」ということで意見が一致していました。

なぜFigmaを選んだのか

結果的にピクセルグリッドでは新しいデザインツールとしてFigmaを選んでいます。デジタル媒体をターゲットにしたデザインツールはSketch、Adobe Photoshopをはじめ、さまざまなツールがありますが、Figmaを選んだ理由は次の3つの特徴があったからです。

• ブラウザで動作する
• ローカルファイルが存在しない
• 複数ユーザーによる同時アクセスが可能

Figmaはブラウザで動作するアプリケーションです*。ブラウザで動作するということは、個別のアプリケーションをインストールする必要がありません。ブラウザは社員全員が日常的に使いますし、ブラウザが起動していないということも基本的にありません。ですので、デザインデータにアクセスするための障害がなくなります。

*注：Figmaの動作形態

単独で起動するアプリとしての提供もされています。

Illustratorのaiファイルでデザインデータのやり取りをしていたときは、フロントエンド・エンジニア側にもIllustratorがインストールされている必要があり、Photoshopはインストールされているが、Illustratorはインストールされていないということがありました。

次に、Figmaにはローカルファイルが存在しません*。すべてのファイルはオンライン上で管理されます。この特徴は「最新ファイルの所在不明」という問題を解決してくれました。デザイナーとフロントエンド・エンジニアの協業において、最新ファイルの共有はお互いに面倒を感じる問題のひとつです。

*注：Figmaのファイルの保存場所

通常ではローカルにファイルは作られませんが、意図的に.figファイルとしてローカルにファイルを保存することは可能です。

ローカルに存在するファイルでデザインデータを作成している場合は、エンジニアが常に「これは最新状態かな？」と気にかけたり、「最新データをください」とデザイナーに連絡をとりつつ、データが送られてくるのを待たなければなりませんでした。

デザイナー側も、ファイルを複数に分けていたりすると「最新ってどれだっけ？」という混乱が発生したり、データに変更があるたびに「最新データを送りました」などのやり取りが発生してしまい、無駄の多い状態です。

一方でFigmaは、常にオンライン上にあるひとつのファイルを編集しつづけるスタイルです。そのため、同一画面のデザインを意図的に並行状態で管理しない限りは、常にオンライン上にあるデータが最新状態であることが確約されています。加えて、データが常にオンライン上にあるため、必要なデザインファイルがデザイナーのPC上にしか存在していないという、リスキーな状態も解決してくれます。

最後に、Figmaは複数ユーザーによる同時アクセスが可能なことです。これはFigmaの名を世に広めた代表的な機能のひとつです。

ピクセルグリッドはフルリモートワークをベースにしています。それぞれが各々の場所で作業していますので、日頃のミーティングが対面で行われることは少なく、ほとんどはGoogle Meetなどを利用してオンライン上で行われます。ですので、プロジェクターで投影するなどして同一の画面を全員で共有しながら、細々とした内容の打ち合わせを進めるといったコミュニケーション方法はとれません。

なにかの資料を参加者全員で見ながら会話を進めようとした場合「全員がちゃんと同じものを見ている」という暗黙の確認は、打ち合わせを進行する上では思いのほか重要で、スムーズな進行と情報共有には欠かせません。その点、Figmaではアクセスしているユーザーのカーソルが全員にリアルタイムで共有されますので、特定のアイテムについて話を進めるにあたって、ファイル上に全員のカーソルがあるかを見ることで、擬似的に「全員がちゃんと同じものを見ているか」という暗黙の確認をとることができます。

このように、Figmaが備えている特徴は、いずれもフロントエンド・エンジニアとの協業をより良い状態へステップアップさせるために、相性の良さを感じさせるものでした。そして、Figmaを利用してフロントエンド・エンジニアとの協業を実践してみたところ、いままで「デザインデータの共有」という部分で発生していたコストが、大幅に低減されたのを実感しています。

デザインの作成と意図の伝達

続いて、Figmaを実際の案件に投入してみて起きた変化を紹介します。

ここでは変化を「データ作成」の視点と「データの共有」の2つの視点に分けてみてみましょう。担当する業務の違う人間が協業してひとつのものを作り上げる場合、効率的な案件進行には、どちらの視点も欠かすことができないからです。

特に、デザイナーとフロントエンド・エンジニアとの協業をする場合は、デザイナーが作成した見た目ベースのデザインデータに対して、それを引き継いだフロントエンド・エンジニアが具体的なコードに落とし込む必要があります。もし、デザイナーがいくらスムーズにデータ作成ができたとしても、その意図を正しくフロントエンド・エンジニアに伝達、共有することができなければ、最終的な成果物にデザイナーの意図が反映されなくなってしまいます。

データ作成での変化

データ作成における変化は、次の4点があげられます。

• アプリが軽快に動くようになった
• 要素の名前を意識するようになった
• 寸法を書き込まなくなった
• 寸法が取りやすいデータ作りの必要性が発生した

アプリが軽快に動くようになった

個人的にはこの変化はとても大きなものでした。Illustratorもファイル内の要素数が少ない状態では軽快に動作しているのですが、要素数が多くなってきたり、ビットマップの情報が増えてくると、どうしてもアプリ自体の動作や反応が、もっさりとしたものになっていました。

もちろん、Figmaもデータ内の要素数が増えるにつれて動作が遅くなる傾向に変わりはありません。しかし、かなりの要素数を配置した状態でも、軽快に動作しているという印象はありました。毎日使うツールですので、局所的にみれば小さな時間短縮も、全体でみると大きな効率化につながってきます。

要素の名前を意識するようになった

現時点でのIllustratorには、アプリケーションのデザインを目的とした、コンポーネントの概念をもった機能はありません。基本的には各要素は単にベクター座標の集まりでしかなかったため、これまでは、コンポーネントをある程度意識したデザインをすることはあっても、すべての要素や状態について厳密に名前を付けることはありませんでした。

しかし、ツールがFigmaになると（Figmaに限らずコンポーネント機能を備えたデザインツールに共通することですが）、データを効率的に作成しようとするために、コンポーネントを強く意識する必要がでてきます。これによって、コンポーネントを上手に使いこなすために、細かな分類をしつつ、それらに適切な名前付けをしなければなりません。

これは元々Sketchが備えていた機能で、後追いでFigmaにも実装されたものです。コンポーネントをスラッシュ区切りで命名することで、コンポーネントをグループ化します。たとえば、次のような書式です。

• Button/normal
• Button/hover
• Button/disabled

このグループ化が行われていれば、画面上でのコンポーネント切り替えを容易にできるようになります。

その結果、対象を分類をして名前をつけるという作業が増えはしたものの、要素の役割と適用範囲についてしっかりと考える良いきっかけになりました。

寸法を書き込まなくなった

Illustratorでは筆者がデータを作成する際に必ず寸法を書き込んでいたのですが*、Figmaでは、この作業は必要なくなりました。

*注：従来のデザインデータ

従来、Illustratorで作成していたデザインデータは次の記事を参考にしていただくといいかもしれません。

• デザイナーの道具箱 第7回 デザイン指定のポイント 1

そもそもIllustratorには要素の寸法や余白を簡単にフロントエンド・エンジニアに伝達する機能がありませんでした。そのため、なるべくこちらの意図を正確に伝達するために、デザインデータに寸法を書き込んでいました。寸法を書き込むには、それなりの手間が発生してはいましたが、こちらの意図がうまく伝わらなかったときに、やり取りを重ねるよりは、デザイン意図の共有はずっとスムーズだったと思います。

一方で、Figmaにはガイド機能があります。このガイド機能は優秀かつ高速なので、知りたい要素の寸法や余白をとても手早く取得することができます。その結果、こちらで寸法を書き込まずとも、データさえ、しっかりとした位置に配置できていれば（これがポイントなのですが）、Illustrator使用時に書いていた寸法の書き込みは不要となりました。

寸法が取りやすいデータ作りの必要性が発生した

Illustratorではデータ上に寸法を書いていましたので、データ自体がどのような状態になっていても、値の取得に影響をあたえることはありませんでした。しかしFigmaでは、前述のとおり、データに寸法を直接書き込むことをしなくなったため、この問題が発生します。筆者がFigmaでのデータ作成に不慣れだったこともあるのですが、普段のデータ作成時に、このデータを受け取ったフロントエンド・エンジニアがデータの読み取りに不都合がでないようにする配慮が抜け落ちている部分がありました。

具体例としては、ボタン内に配置されたテキストと、ボタンまでのpaddingがうまく取得できないということがありました。

当時、私の作ったコンポーネントは、ボタンの背景色を塗っているオブジェクト（仮にボタンオブジェクトと呼びます）とテキストオブジェクトの寸法が同じで、テキストの配置が上下左右ともに中央という設定になっていました。つまり、ボタンオブジェクトの上に、同じ寸法のテキストオブジェクトが載せられている状態です。

そのため、見た目としてはボタンとテキストにpaddingが見て取れるものの、データからはFigmaのガイド機能によってpaddingを取得することができない状態になっていました。ボタンオブジェクトとテキストオブジェクトが同じ寸法で重なっているので、データではpaddingは発生していないのです。

もしガイド機能を使って正確にpaddingを伝えたいのであれば、テキストオブジェクトの寸法と、ボタンオブジェクト上の位置を正確に調整しなければいけません。

このような調整は、寸法の値をデータ上に記載していたときには無用でしたが、Figmaでは必要になりました。ただ、データ作成時間全体でみると、寸法の記載に使っていた時間に比べれば、だいぶ短い時間で済みますし、Figmaでのデータ作成にもっと慣れる、もしくは会社内で共有できるようなコンポーネントとしてしまえば、必要な時間はさらに短縮されていくので、さほど負荷とはならないと感じました。ただし、実装に必要なあらゆる値が取得できるかというと、そうでもありません。それらについては後編で紹介します。

ここまでのまとめ

前編ではIllustratorからFigmaにツールを変えた経緯、理由と、データ作成にどのような変化が生まれたかを紹介しました。概ね、作業効率は良くなりましたが、いくつかの課題も見つかりました。

後編では、UIデザイナーがフロントエンド・エンジニアやクライアントとデータを介してコミュニケーションを取るデータ共有の場面で、どんな変化が起きたのかを紹介します。また、これからの課題についても合わせて言及したいと思います。