Figmaが解いたデザイナーの課題とは
数週間前、Oktaは年次レポートを発表しました。レポートの中では、新しいワークスタイル、特にリモートワークをサポートするために、どのアプリケーションが最も急速に成長しているかが紹介されています。下の図は、Oktaエコシステムの中で、2020年から最も急成長したアプリを示したものです。今回は、Figmaについて、製品がどのように機能するのか、何が特別なのか、そして今後についてお話します。
簡単に言うと、Figmaは現代のコラボレーション・デザイン・システムです。ウェブサイト、アプリ、マーケティング・コンテンツ（あるいは、デジタル関連のあらゆるもの）を作成する場合、コーディングを始める前に、デザイン、つまり最終的なデザインに辿り着くまでデザイナーとあらゆる関係者の間で何往復もの作業が必要です。デザインファイル（ベクターエディターとも呼ばれます）は、フロントエンドのエンジニアに提供される完成イメージのようなもので、最終的にエンジニアによってコード化されるものをグラフィックで表現したものです。モバイルアプリを例に挙げてみましょう。最終的にプロダクトチームは、エンジニアにアプリの「見た目」のイメージを伝えるだけでは不十分です。エンジニアにデザインを渡さなければなりません。そして、Figmaはそのデザインを作成するためのプラットフォームなのです。Figmaでデザインがどのように作成されるか、Googleの画像を以下に引用します。
デザインには多くの複雑さがあります。ヘッダーをどこに置くか、背景色をどうするかなど、単純な側面もある一方で、ボタンが押されたときにエフェクト、あるページから別のページに移るときにトランジションなど、は複雑です。これらの詳細をデザインに反映させることは、エンジニアリングチームが何を作るべきかを正確に把握するために非常に重要です。
なぜデザイナーが重要なのか？
今日、すべての企業がソフトウェア企業になりつつあり、エレガントなUIとカスタマーエクスペリエンスが重要視されています。ソフトウェアの開発速度が急上昇するにつれ、デザイナーの必要性も高まってきました。使いやすく、視覚的に魅力的で、直感的に操作できる製品でなければ、競合他社に潰されてしまいます。そのため、デザイナーの必要性は非常に高まっています。ここ数年、デザイナーと開発者の比率にこの傾向が見られます。FigmaのCEOであるDylan Fieldは、3.5年前にこの傾向を強調した記事を書きました。以下の画像は、さまざまな企業における、デザイナー1人に対するエンジニアの数を示しています。この比率が下がると、デザイナーの数が増えていきます。企業はかつてないほど多くのデザイナーを採用しており、この傾向は2021年も続いています。
数年前までは、この市場を見て、「世界にはそれほど多くのデザイナーがいないし、この市場は大企業を支えるには小さすぎる」と言うのは簡単だったかもしれません。しかし、後述する理由から（そして前述の理由から）、これはあまりにも単純な仮定であることがわかりました。一般的には、以前はクラウドではなかった製品のクラウド版が、市場を大きく拡大することが多いのです。
Figmaが解いた課題
Figmaの特徴に入る前に、Figmaが登場する前の世界がどのように機能していたかを理解することが重要です。ここでは、（Figma以前の）デザイナーの典型的なワークフローを説明し、課題が発生する箇所を強調します。
デスクトップ：限られたコラボレーション
数年前に市場で主流だったベクター・エディターは、SketchとAdobe（Photoshop、Illustrator、InDesign、そして最近ではAdobeXDなどの製品があります）でした。これらの製品は強力で素晴らしいものでしたが、クラウドベースではなく、デスクトップアプリケーションでした（SketchもAdobeも最近になってクラウド製品をリリースしました）。
これは何を意味するのでしょうか？コラボレーションが非常に難しかったのです。モバイルアプリのデザインを作成し、同僚に見てもらいたい場合は、ファイルを何らかのファイルシステム（Boxなど）に保存し、同僚にはBoxのフォルダから「Design v1のファイルを見て」と伝えていました。あるいは、ファイルシステムがなくて、ファイルをメールで送っていたかもしれません。すると同僚は、Design v1を開いて変更を加え、新しいファイルをDesign v2として保存し、完了したら私にファイルをメールで送り返します。しかし、その編集の際に、同僚が自分のコンピュータでローカルにダウンロードした新しいフォントを使用したとしたらどうでしょう？Design v2を開くと、テキストの代わりに"$%^@@#$$#%&"のようなものが表示されるかもしれません。私は彼に、どのフォントを使ったのか聞いて、それを私のコンピュータにダウンロードしてから仕事に戻らなければなりません。他にも似たような問題（カラーパレットなど）がたくさんありますが、デスクトップベースのベクターエディターで管理するのは非常に困難です。
バージョンコントロールの悪夢
デスクトップアプリのベクターエディターに起因するもう一つの問題は、バージョン管理です。上でも少し触れましたが、あるデザインファイルの最新バージョンを階層的に管理することは非常に困難です。1つのファイルに2人の人間が同時に作業をすることはできませんし、ほとんどの人は、ファイル名の末尾に「v1, v2, v3」などと付けて、どのバージョンが最新かを示すシステムを採用しています。ここで、バージョン管理が大きな頭痛の種になる例をいくつか挙げてみましょう。同僚が仕事を終えて、「最新バージョンはBoxに保存されているよ」と教えてくれました。私がBoxに入ると、v1、v2、v3と表示されています。論理的に考えれば、v3が最も新しいということになります。私はv3を手に取り、2時間かけて編集し、v4として保存しようとした。しかし、待てよ! 保存」を押すと、「v4はすでに存在していますが、変更を上書きしますか」というメッセージが表示されました。私は慌てて同僚にメールを送り、「どのバージョンまで保存したのか」を尋ねました。彼女が教えてくれたのはv4..... 最新のファイルの同期が間に合わず、古いバージョンを手に入れて変更してしまったのです。私が変更した部分と、彼女が変更した部分をオリジナルのv4に統合することはできません。 私たちは、もう一度最初からやり直さなければなりません。
別の例として、私のデザインチームは金曜日の午後にようやくデザインを完成させました。私たちはそれを「vF」（「ファイナル・バージョン」の略）と名付け、エンジニアリング・チームに製作を依頼して、週末に迎えました。しかし、ちょっと待ってください。私たちがデザインしたアプリのある画面で、「ログイン」ボタンをページの一番上に置いていることにすぐに気づきました。最初の指示では、「ログイン」ボタンをページの下に置くように言われていたのを忘れていたので、すぐに変更してvFFとして保存し、新しい「最終」バージョンができたことをエンジニアにメールで伝えました。エンジニアは月曜日に出社して、デザインが完了したというメールを見て、すぐにBoxフォルダの中のvFを見て、それを手に取ります。そして、アプリを起動してから、間違った「最終バージョン」を使ったことに気がつきました。この例は単純で、簡単に修正できるものでした。しかし、「vFの悪夢」には、そう簡単には修正できない、もっと深刻な問題があります。
この問題を解決するために、Abstractのような企業が最新のバージョンコントロールシステムをリリースしました。彼らは素晴らしい会社です。ソフトウェア開発者がGitHubを使っているのと同じ仕組みを、デザインファイル管理にも取り入れたのです。これで「デザイナー・スタック」（デザイナーに必要なツール）は、Sketch + Abstractとなりました。
プロトタイピング：ますます増えるツール
プロトタイプ作成は、デザイナーにとって一般的なプロジェクトです。プロトタイプとは、最終的なデザインを決定する前に、最終製品（例えばウェブサイト）のさまざまなバージョンやフローを作成することです。例えば、ホームページのヘッダーに「採用情報」のページへのリンクを設けたバージョンをテストしたいとします。また、ホームページのヘッダーには、"製品、価格、お客様の声、リソース "だけを表示したいとします。バージョン1では、ホームページにアクセスした人は、すぐに「採用情報」をクリックすることができます。バージョン2では、まず「リソース」をクリックし、そのページから「採用情報」をクリックする必要があります。これらの「ユーザー・フロー」の2つの異なるバージョンをテストしたいと思いますが、2つの別々のウェブサイトを開発することはしたくありません。InVisionのようなプロトタイピング・ツールを使えば、異なるビジュアル・プロトタイプを驚くほど簡単に作成できます。
これで「デザイナー・スタック」は、Sketch + Abstract + InVisionです。ご覧の通り、ツールの数はどんどん増えていますね。
デザイナーからエンジニアへの引き継ぎ：何を作るの？
デザインファイルが完成すると、エンジニアに引き渡されます。エンジニアは、デザインファイルを見て、何を作ればいいのかを把握すればいいように思えます。簡単でしょうか？そうではありません。
デザインファイルには、基本的なことはすべて書かれていますが、具体的なことは書かれていません。いくつか例を挙げてみましょう。あなたがデザインしたWebサイトには、赤い枠で囲まれた画像があります。そのボーダーの太さはどのくらいでしょうか？1ピクセル？2ピクセル？10ピクセル？また、その赤のRGB（赤、緑、青）の値は何ですか？画像は中央に配置されていますか？あるいは、画像を配置するページのXとYの座標は決まっていますか？ユーザーがブラウザを拡大した場合、画像は拡大縮小されるのか、それとも同じサイズのままなのか？デザインには、エンジニアが実際に作るとなると知る必要とする多くの情報が存在します。この問題に対処するために、デザイナーはこれらの詳細をデザイン上に記載するか、エンジニアと一緒に議論することになります（あるいは何百回もslackメッセージをやりとりすることになります）。これは大変なことです。
そこで、「デザインから開発者へ」の引き継ぎを行う新しい企業が登場しました。Zeplinは、デザインを自動的にマークアップするソリューションを提供し、デザインからデベロッパーへの引き継ぎにかかる時間を短縮しました。これで「デザイナー・スタック」は、Sketch + Abstract + InVision + Zeplinとなりました。
"Sketch +"モデル：数え切れないプラグインによる死
デザイナー・スタックが増えたため、プラグインの管理やツールの切り替えのため、使い勝手が悪くなっていました。また、ベクターエディターがデスクトップアプリケーションであることから、プラグインの管理は非常に困難でした。デザインスタックのプレーヤーが新しいバージョンにアップデートするたびに、すべてのプラグインが壊れ、再構築しなければなりませんでした。プラグインの更新、ワークフローの崩壊、プラグインの修正という戦いが続きました。その繰り返しでした。
デザインシステム
デザインシステムは、旧来のデザイナーのワークフローにおける最後の課題です。企業がすべての顧客接点（ウェブ、モバイルなど）で一貫したブランドを確立するためには、クリエイティブな資産の中央管理が必要です。ロゴを例にとってみましょう。すべての企業にはロゴがあります。しかし、会社がブランドを一新して、そのロゴが更新されたらどうなるでしょう。デザイナーはどこに行けば、そのロゴを手に入れることができるのでしょうか？すべてのクリエイティブ資産を一元管理できる場所はありませんでした。そして、利用可能なツールがあっても、この唯一の真実の源を置く場所がなかったのです。真実の源である中央のリポジトリに保存されるべきデザイン資産は（ロゴ以外にも）何千もあります。
要約すると、Figmaが登場する前のデザイナーのワークフローの課題には、デスクトップ・アプリケーションとのコラボレーション機能の欠如、バージョン管理の難しさ、デザインからデベロッパーへのコンテキストの課題、別のツールで行うプロトタイピング、管理が不可能な多数のプラグインなどがありました。
Figmaの参入：クラウドベース
Figmaは2012年に設立されましたが、優れた企業の例に漏れず、顧客に支持されるようになるまでには時間がかかりました。その理由は？それは、製品を作るのが非常に難しく、時間がかかったからです。単純化しすぎかもしれませんが、Figmaがやったことを最も簡単に言うと、ベクター・エディターをブラウザーに移したものです。デスクトップでアプリを開くのではなく、ブラウザでアプリを開いたのです。いろいろな意味で、Microsoft WordとGoogle Docsの比較が簡単にできます。Figmaでは、デザイン・ファイルのリンクを同僚に送ることができます。複数の人が同時にそのファイルで作業することができます（そして、お互いのマウスの動きや編集内容をリアルタイムで見ることができます）。簡単そうに聞こえますか？そうではありません。デザインファイルは非常に複雑です。高解像度の画像、多数の異なるレイヤー、さまざまなデバイスやOS、ブラウザ用のレンダリングなどで構成されています。そして、これらすべてが、リアルタイムで高品質に更新され、レンダリングされる必要があります。ある意味では、Figmaのような会社は、その前に存在することができませんでした。Chromeのようなブラウザは、単にサポートするのに十分な性能を持っていなかったのです。私はデザイナーを投資銀行の従業員に例えるのが好きです（ご理解ください）。Sketchは業界を席巻したソリューションで、excelのようにキーボードショートカットや機能性が豊富にあり、デザイナーはそれを利用していました。Excelと同じように、投資銀行の従業員もショートカットを使っています。彼らに聞いてみるば、ExcelのショートカットがWindowsとは違うので、Macを使うのは間違いだと言うでしょう。また、Excelの機能性が100倍以上であるため、グーグルシートを使うこともないでしょう。
ベクターエディターやデザイナーは、Excelや投資銀行の担当者によく似ています。デザイナーは、Sketchのようなツールに存在するショートカットと機能性の両方に非常に精通しているので、彼らに変更してもらうのはとても難しいのです。Figmaのような新規参入企業がチャンスを得るためには、機能性を同等にする必要があるだけでなく（これは控えめに言うべきではなく、ベクター・エディターは信じられないほど強力です）、この機能性のすべてをブラウザで表現しなければなりません（非常に困難です）。これが、Figmaが顧客に支持されるまでに何年もかかった理由です。しかし、それが実現したとき、門が開きました。その理由を説明するために、これからFigmaの製品について詳しく説明します。
私たちはすでに、製品の中核的な側面である、ブラウザ上のクラウド・ベクター・エディタについて触れました。しかし、それ以外に何ができるのでしょうか？標準的なコラボレーション機能（ファイル内でのコメント、チームとしての共同作業など）に加えて、Figmaは、上述した「デザイナー・スタック」の多くのプラグイン機能を製品に直接組み込んでいます。バージョン・コントロールは、ネイティブに組み込まれています。プロトタイピングは、Figmaの中で直接行われます。エディタ内では「コード」ビューに切り替えることができ、デザインから開発者への引き継ぎをシームレスに行うことができます。これまでの使ってきたSketch＋多くのプラグインを、Figmaが実現してくれたのです。それがFigmaです。必要なものがすべて1つのツールに集約されているというシームレスな体験は、言葉では言い表せません。
その上、Figmaはデザイン・システムのためのエレガントなソリューションを導入しました。すべてのクリエイティブ・アセットのための、中心となる単一ソースのリポジトリです。Figmaのウェブサイトから、そのデザイン・システムを説明するスクリーンショットをいくつか紹介します。
Figmaが構築したものは、本当に特別なものです。Dylan（FigmaのCEO）は、ビジョンを持ち、それを実行するのに何年もかかりましたが、今では基礎となるSaaSビジネスを構築しました。また、Sketchも素晴らしいビジネスを展開していることを強調したいと思います。彼らのルーツはデスクトップ・アプリにありましたが、クラウド製品にエレガントに移行し、素晴らしいプラットフォームを持っています。先に述べたFigmaの話は、ほぼすべてSketchにも当てはまります。唯一の違いは、Figmaはクラウドで生まれ、Sketchはクラウドに移行したということです。私は、この2社が今後何年にもわたって競い合うことを楽しみにしています。このようなクラウド市場の驚くべき点は（私がずっと説いてきたように！）、ほとんどの場合、当初の予想よりもはるかに大きくなるということです。FigmaとSketchの両方とも、独立した大きな上場企業となることができますし、そうなると信じています。
🚀🚀🚀
原文：Figma - Worth the Hype? Absolutely
著者：Jamin Ball
免責事項
当該和訳は、英文を翻訳したものであり、和訳はあくまでも便宜的なものとして利用し、適宜、英文の原文を参照して頂くようお願い致します。当記事で掲載している情報の著作権等は各権利所有者に帰属致します。権利を侵害する目的ではございません。
あなたのおすすめの海外記事を教えて下さい！翻訳して皆さんに共有させて頂きます💁♂️➡️➡️Twitterへ
この記事が気に入ったらサポートをしてみませんか？