大規模な設計：Figmaを使用した1年間
公開: 2022-03-10この記事では、大規模なチームがよりオープンで協調的なツールを使用することでどのように利益を得ることができるか、および採用と移行を実現可能で快適にする方法について説明します。 また、記事のタイトルからまだ推測できない場合は、多くの場合、Figmaと、この設計ツールをチームに採用することに成功した方法について説明します。
対象となるのは、組織内で部門の枠を超えたチームの作業方法を改善しようとしている設計システム、開発者、または製品マネージャーとの大規模なチームで作業する経験豊富な設計者です。
私は10年以上プロの環境でデザインツールを使用しており、常にサービスを提供しているチームをより効率的かつ効果的に機能させるように努めています。 Photoshopのスクリプトやアクションから、Axureのウィジェットライブラリ、Sketchプラグイン、そして今ではFigmaまで、開発者や製品マネージャーを置き去りにすることなく、設計チームが最先端を維持できるように支援してきました。
設計システムとツールの基本的な知識は役立ちますが、特定の例と、チームまたはコンテキストに適応できる「高レベル」の概念と方法を共有したいので、必須ではありません。
2015年頃のデザインワークフロー
2015年の私たちの主要なツールはSketchでした、そしてそれはほとんど共通点が止まったところです。 デザインのプロトタイピング、エクスポート、および関係者（InVision、Axure、Marvel、Googleスライド、さらには時代遅れのAdobe PDF）や開発者（Avocode、Zeplin、Measureなどのスタンドアロンアプリのないプラグイン）との共有には、さまざまな方法がありました。 まれに、MacBookとSketchライセンスのまれな組み合わせを持っている幸運なエンジニアにファイルを直接送信することができました。
InVisionがCraftプラグインをリリースしたとき、SketchからInVisionに画面のプロトタイプを作成してアップロードし、ファイル間で初期のライブラリのコンポーネントとスタイルを共有できることに喜びを感じました。それはデザイナーの夢の実現でした。
最終的に、私たちは全員InVisionプラットフォームに収束しました。 利害関係者のコラボレーションと開発者の引き継ぎにおける摩擦の多くを軽減するのに役立つプロセスを作成し、文書化しました。 それでも、複雑な権限構造のため、InVisionは閉鎖生態系のままでした。デザイナーでない場合は、承認チェーンがあり、InVisionアカウントを取得するのが困難でした。アカウントを取得したら、追加する必要がありました。適切なグループに。
バージョンとファイルを手動で管理し、それらを共有ドライブに保存して整理し、同期の競合に対処することは、私たちに多くの頭痛の種を引き起こしたほんの一部でした。
Googleドキュメントにあるリアルタイムのコラボレーション機能とコミュニケーション機能を備えた、SketchとInVisionのすべての最高の機能を備えたオールインワンツールを本当に手に入れることができるでしょうか。 コンテキスト切り替えによるオーバーヘッドを削減することに加えて、3つのツールサブスクリプション（モックアップ、プロトタイピング、および開発者ハンドオフ用）から1つだけに単純化できる可能性もあります。
プロセス
私たちのチームで最初にFigmaを採用した設計者は、2016年に最初のFigmaベータ版がリリースされたときに実験を開始しました。機能は限られていましたが、必要なものの80％をカバーしていました。 スケッチのインポートにはバグがありましたが、リアルタイムで共同作業できることには大きな価値があり、最も重要なことは、プロジェクトの設計作業の90％を単一のツール内で実行できることです。 利害関係者のフィードバック、改訂、および開発者の引き継ぎは飛躍的に向上しました。
2017年までに、ほとんどの作業に数人のデザイナーが使用し、Lexiconデザイナーの1人（Liferayのデザインシステム）であるEmiliano Ciceroはすぐに伝道者になりました。これは、残りの人々を説得するための重要な要素であることが判明しました。切り替えを行うチーム。
2017年の夏にフィグマ2.0がデビューし、プロトタイピング機能が追加され、開発者のハンドオフ機能が大幅に改善されたとき、これがグローバルチームにとって実行可能なツールになる可能性があることがわかりました。 しかし、20人以上のデザイナーに、彼らが愛し、何年も快適に使用してきたツールやワークフローを放棄するように説得するにはどうすればよいでしょうか。
そのテーマについてシリーズを書くことはできますが、2つの最大のことは、小さなものから始めることと、堅固なインフラストラクチャを作成することでした。
小さく始める
2017年の秋に、米国とブラジルに分散した製品チームでFigmaの最初のトライアルを開始しました。 ロサンゼルスのオフィスで1週間のキックオフを一緒に行うことができて幸運でした。 Figmaでフローとワイヤーフレームを一緒に設計することは、はるかに高速で効率的でした。 フォルダやライブラリを常に同期することを心配することなく、タスクを分割し、ファイルやコンポーネントを共有することができました。
2018年1月のグローバルキャザリングでは、移行が可能な限りシームレスになるように、このチームの経験を使用して、組織の他の部分に必要なインフラストラクチャを形成するために、Figmaをゆっくりと採用する計画を策定しました。
私たちが直面した最大の課題は、締め切りが厳しいことでした。世界中に複数のエンジニアリングチームと製品マネージャーが分散しているプロジェクトの規模が大きいため、レビューと引き継ぎのプロセスをやり直すことは意味がありませんでした。 最終結果はもっと良かったのに、タイミングは正しくありませんでした。 もう1つの要因は、Figmaの信頼できるオフラインデザインエクスペリエンスの欠如でした（詳細は後で説明します） 。これらの理由から、チームはワイヤーフレームとモックアップにSketchとFigmaを使用することにしましたが、プロトタイピングやレビューはInVisionで行う必要がありました。
堅実なFigma構造の作成
最初のステップの1つは、プロジェクト、ファイル、およびコンポーネントの編成に関する大まかなガイドラインを策定することでした。 これらの基礎は、2人のジュニア（当時）のデザイナー、AbelHancockとNaokiHisamotoによって始められました。彼らは、Photoshopで歯を食いしばったデザイナーから来ているように見える悪いレイヤー命名の習慣を決して開発しませんでした。 この組織化の方法は、Liferay.comプロパティのコンポーネントの小さなライブラリの開発に費やされた年と相まって、グローバルチームの残りのメンバーを成功に導くために重要でした。
ベンのツイートに触発されて、Liferay.comのデザイナーの1人によって作成された初期の組織の改善は、カバーのシステムでした。
このファイルをコピーしたい場合は利用できるようにしました。それ以外の場合は、非常に簡単なハックです。
- ファイルの最初のページに620×320の単一のフレームを作成します。
- デザインを追加します。 テキストがある場合、最小サイズは最大24であり、例のタイトルは48に設定されています。
- 楽しみ！
注：表紙の周囲には常にわずかな余白がありますが、ページキャンバスをカードと同じ色に設定すると、この余白の外観が減少します。
これは、デザイナーだけでなく、物事をすばやく見つけようとしているプロジェクトおよび製品マネージャーやエンジニアにとって、ライブラリを変革するのに役立ちました。 検索機能はすでに非常に優れていましたが、カバーを使用すると、ユーザーはさらにすばやく物事を絞り込むことができ、さらに、特定のファイルのステータスを即座に伝えることができました。
Figmaを使用する前は、「マスター」設計システムのスケッチファイルに加えて、ほとんどの設計者は、ワイヤーフレーミング要素や基本コンポーネントなどを使用して、時間をかけて開発したベースファイルを持っていました。 単一のパターンに合体するにつれて、すべてを組み合わせて1つのライブラリに改良し始めました。 Figmaでワイヤーフレーム、モックアップ、プロトタイプを作成していたため、Figmaで独自のタスクフローコンポーネントを作成する代わりに、Lucidchartなどのフローアプリも廃止し始めました。
私たちが時間をかけて開発した他のユーティリティは、正確なハンドオフ仕様を作成するためのレッドラインコンポーネント、アフィニティ図（およびほぼすべて）の付箋、およびフローノードでした。
Figmaでこれを行う最大の利点の1つは、デザイナーが行ったこれらのコンポーネントの改善をライブラリに簡単に取り入れて、すべてのインスタンスにプッシュできることでした。 チームの誰もが比較的簡単なプロセスで改善に貢献できるため、これを一元化された場所に置くことで、メンテナンスも非常に簡単になります。
レッドラインドキュメントは、開発者がUIコンポーネントまたはコンポーネントのセットの寸法、視覚的仕様、およびその他のプロパティを簡単に理解できるようにするためのものです。 このトピックに興味がある場合は、設計図に関するDmitriyFabrikantの記事を確認することもできます。
コンポーネントを作成するときに覚えておくべきいくつかの推奨事項：
- 強力なベースコンポーネントのオーバーライドとマスターの使用（詳細はこちら）。
- 命名の一貫したパターンを確立します（アトミックモデルを使用します）。
- すべて、特にレイヤーを文書化してラベルを付けます。
2017年6月の初めにリリースされた高度なスタイリング機能により、システムチームは、7月の大規模な製品リリースと8月の立ち上げの間に、Lexiconライブラリの完全バージョンを完成させました。 これは、グローバルチームをサポートするために必要な最後のピースでした。 マーケティングや他の部門で働くデザイナーは、すでにしばらくの間Figmaを使用していましたが、昨年の秋までに、他のほとんどすべての製品チームがFigmaへの移行を完了しました。
現在、ほとんどの製品設計者はFigmaのみを使用しており、Figmaにインポートする価値のない既存の複雑なSketchプロトタイプが多数あるレガシーシステムで作業している設計者も2人います。 もう1つの例外は、Figmaでは意味をなさないより高度なアニメーションのためにPrincipleやAdobe AfterEffectsなどのアプリを使用することがある少数のデザイナーです。 特に、あらゆる種類のデータを大規模に活用する必要がある作業で、さらに堅牢なプロトタイプを求めてFramerXを検討している設計者もいます。 半定期的に複数のツールを使用しているデザイナーもいますが、当社の製品デザイナーの80％は、すべての設計およびプロトタイピング作業にFigmaを使用しています。
継続的な改善
私たちは常により効果的に作業する方法に取り組んでおり、現在繰り返していることの1つは、ページに名前を付けるためのベストプラクティスです。 最初はページ名に基づいてページに名前を付けましたが、問題があることがわかりました。さらに、ライブラリを改善することで、複数のページを含む大きなファイルの必要性が減りました。
現在、ファイル内で番号付けシステムを使用しており、最上部のページが開発者に配信されるものです。 今日議論している次のフェーズは、明示的なラベル（ワイヤーフレーム、モックアップ、ブレークポイントなど）を使用してバージョンをより意味のあるものにし、Figmaの組み込みバージョンをより有効に活用して、バージョンを保存するタイミングと方法のベストプラクティスを確立することです。
Final_Final_Last_2 —もうありません！
私は一般的に「ゲームチェンジャー」という用語を使用するのは嫌いですが、Figmaが昨年3月にバージョン履歴への名前付け/注釈付けをリリースしたとき、ファイルの整理方法が劇的に変わりました。 以前は、イテレーションとバージョンを保存する方法はすべて異なりました。
通常、単一のファイル内に新しいページを作成しますが、大きなファイルの場合は、それらを複製し、ファイル名の最後に文字を追加して反復を通知します。 大幅な変更を行う場合は、新しいファイルを作成してバージョン番号を追加することができます。 これは非常に自然なことであり、すべてのファイルを複数管理するというPhotoshop / Sketchのパラダイムに由来しています。
以前にGitのようなバージョン管理を使用したことがある人なら誰でも、ある時点に名前を付けたり注釈を付けたりするために定期的に一時停止して作業する機能は非常によく知られています。 ファイル履歴全体を確認し、過去のスナップショットを調べて、1つを選び、名前を付けて注釈を付けることもできます。
過去のバージョンに戻って元に戻したい場合は、それを復元して、履歴のその時点からそのファイルで作業することができます。 最良の部分は、「復元した」バージョンが何も削除していなかったため、作業が失われなかったことです。 その状態をコピーして上部に貼り付けるだけでした。
この図では、設計者はfinal 1.1を復元した後、 final 3.0に到達しますが、ファイルのバージョン履歴は完全に表示され、アクセス可能です。
新しいプロジェクトを開始する場合、またはファイルに非常に劇的な変更を加えたい場合は、ファイルを「フォーク」する必要があります。 Figmaを使用すると、履歴の任意の時点でファイルを複製できますが、ファイル履歴はコピーされないことに注意してください。
このバージョン管理されたシステムで作業する良い方法は、開発者がgitを使用するのと同じようにファイル履歴を使用することです。Figmaバージョンをコミットまたはプルリクエストと考え、名前を付けて注釈を付けます。そのような。 これに関するより賢明な考えについては、Seth Robertsonの「頻繁にコミット、後で完璧、一度公開：Gitのベストプラクティス」をお勧めします。これは、バージョン管理されたエコシステムでの作業方法に関する優れた一般的な哲学です。 また、ChrisBeamsのGitCommitメッセージの書き方は、作業中に意味のある有用なメモを書くための優れたガイドです。
私たちが発見したいくつかの実用的なヒント：
- タイトルは25文字以下にしてください。
長いタイトルは切り取られ、バージョン履歴のメモをダブルクリックして「バージョン情報の編集」モーダルを開いて読む必要があります。 - 説明は140文字以下にしてください。
完全な説明は常に表示されるため、要点を把握しておくと、履歴を読みやすくするのに役立ちます。 - タイトルには命令法を使用します。
これにより、「ボタンの色を青に変更する」と「ボタンを青に変更する」など、その時点をクリックしたときに何が起こるかをより明確に把握できます。 - 説明を使用して、「何を」および「なぜ」と「どのように」を説明します。
「なぜ」に答えることは、デザイナーの仕事の重要な部分です。したがって、これは、作業中に重要なことに集中し、将来、より良い情報を提供するのに役立ちます。
オフラインでの作業
免責事項：これは私たち自身の経験に基づいており、その多くはそれがどのように機能するかについての私たちの最良の推測です。
前に述べたように、Figmaでのオフラインサポートは希薄です。 オフラインにする前にすでにファイルを開いている場合は、ファイルの作業を続行できます。 行った変更にはそれぞれタイムスタンプが付いているようです。 オフライン中に他の誰かが同じファイルで作業している場合、最新の変更は、オンラインに戻ったときにレンダリングされたものになります。
この単純な例では、それほど大したことではないように見えますが、実際には、これは非常に厄介で、非常に高速になる可能性があります。 誰かがあなたの作品を上書きする可能性が高いことに加えて、フレームとグループが互いに積み重なる可能性があります。
私たちのワークフローは、オフラインになる前（または後）にページを複製し、そのコピーで作業を行うことです。 そうすれば、オンラインに戻ったときに手つかずのままになり、必要なマージを手動で行うことができます。
「F」は未来のためです
新しいツールの採用は決して簡単ではありませんが、最終的には、メリットがコストをはるかに上回る可能性があります。
私たちのチームが経験した最大の改善領域は次のとおりです。
- コラボレーション
私たちの仕事と改善点をチームやコミュニティと共有する方がはるかに簡単です。 - 透明性
デフォルトで開いているシステムは、当然、設計分野以外の人々にとってより包括的なものです。 - 進化
設計者とエンジニアの間の「層」を取り除き、設計の成熟度の次のステップに進むことができます。 - 操作
ワイヤーフレーム、モックアップ、プロトタイプ、および開発者の引き継ぎに単一のツールを採用することで、経理、IT、および管理の作業が容易になります。
サブスクリプションの総数を減らすことは、私たちのチームにとって非常に役立ちましたが、コストは「無料」から年間500ドル以上までさまざまであるため、特定のコンテキストやニーズには意味がない場合があります。 完全な内訳については、Figmaの価格ページを参照してください。
成長し、より良くなる
もちろん、完璧なツールはなく、常に改善の余地があります。 以前使用していたツールに欠けていたものは次のとおりです。
- プラグインエコシステムはありません。
スケッチの拡張性は、Photoshopからの切り替えを簡単にするための大きな要因でした。 FigmaにはWebAPIがありますが、現在、「書き込み」機能はありません。 今のところ、Sketchは、拡張機能とプラグインの活気に満ちたコミュニティでマーケットリーダーであり続けています。 （もちろん、Figmaがプラグイン開発のステージを開く場合には、将来的に状況が変わる可能性があります。） - WebまたはJSONデータをプロトタイプにインポートします。
実際のデータを使用して設計する方がはるかに簡単です。 Sketchは最近v.52で「データ」機能を導入しましたが、InVisionのCraftプラグインは、大量の異なるデータを簡単に追加することに関しては依然として非常にゴールドスタンダードです。今のところ、テキストフィールドに手動で入力することはできません。 - より多くの動き。
Principleの統合は素晴らしいですが（Principleがある場合）、Figmaに基本的なアニメーションと高度なプロトタイピング機能がある方がはるかに優れています。 - よりスムーズなオフライン体験
前述のように、オフラインにする前にFigmaファイルを開いている限り、問題はありません。 これはほとんどの人にとっておそらく問題ありませんが、毎晩コンピュータをシャットダウンしたい場合、朝、電車や飛行機でコンピュータを開いて、フィグマを開いたままにしておくのを忘れていることに気付くと、苦痛になります。
オープンソースデザイン
数か月前、常に物議を醸しているDann Pettyは最近、GitHubを持っている開発者、Unsplashを持っている写真家についてツイートしましたが、デザイナーは無料で物事を共有するためのプラットフォームを持っていません。 デザインTwitter️が急襲し、スクリーングラブを入手する前に彼はツイートを削除しましたが、私が言及したいことの1つは、Liferayで非常に情熱を注いでいるのはオープンソースであるということです。 そのために、デザインコミュニティと共有するリソース用のFigmaプロジェクトを作成しました。
これらのファイルのいずれかにアクセスするには、liferay.design / resources / figmaをチェックして、私たちが成長し、共有するのを楽しみにしていてください！
参考文献
- 「フィグマとの最初の6か月」、ダニー・サルタレン
- 「設計チームのコンポーネントライブラリの構築を開始するためのサインを待っていますか？」、William Newton
- 「Figmaを使用してUI / UXワークフローを合理化する方法」NicoleSaidy
- 「FigmaOrganizationのチーム入門」ThomasLowry
- 「Figmaのページでワークフローを構築する5つの方法」JoshDunsterville
- 「ベストプラクティス：コンポーネント、スタイル、共有ライブラリ」、Thomas Lowry
- 「Figma：コンポーネントを使用したタイポグラフィへの流動的でモジュール式の設計アプローチ」Mirko Santangelo
その他のリソース
- スペクトラム上のFigmaコミュニティ
- デビッド・ウカウワによるフィグマデザインハンドブック