Microsoft Outlook設計プロセスの抽象化

Abstractが設計チームのファイル編成とコラボレーションを改善した方法

画像の説明:設計システムからのUIコンポーネントの選択。

デザイナーとして、ファイルストレージとチームコミュニケーションにさまざまなツールを使用しましたが、どれも非常に堅牢ではありませんでした。ファイルを失ったり、最新のデザインを探して何時間も費やしたり、貴重な時間とエネルギーを無駄にしたりすることは無数にあります。

開発者はGitのようなバージョン管理システムをしばらく持っていましたが、デザイナー向けの同様のメカニズムは今まで利用できませんでした。

Abstractは、デザイナーがプロジェクトで協力できるように構築されたツールです。チームに設計作業の中心的なハブを提供し、設計コンポーネントとファイルの管理と保守を支援します。デザイナーはSketchファイルを一度Abstractにインポートし、そこからファイルを開くだけです。

数年前、MilesとVictorはOutlookチームでAbstractの使用を開始し、それ以来Microsoftの設計チームで採用されています。この投稿では、Abstractの使用方法について説明し、ファイル構造、マージプロセス、ファイルメンテナンス方法、および改善できると思われるプロセスのいくつかの領域を共有します。このプロセスは大規模なチームで機能しますが、私たちはまだそれを把握しており、これを改善する方法を聞きたいと思っています。

プロジェクトのファイル構造の設計

プロジェクトは、Android、iOS、Mac、Web、ユニバーサル(Windows 10のメールとカレンダー)のプラットフォームごとに分かれています。これらのプロジェクト内で、ファイルはアプリのさまざまなセクションに分割されます。以下は、Abstract内のiOSファイル構造の例です。ここでは、ファイルを「iOS UI-Kit」、「Mail」、「Calendar」などのセクションに分割して、ファイルを迅速に実行します。

まず、Start Hereは、新しいデザイナーと外部パートナー向けのファイルです。設計原則、抽象の使用方法、アセットのエクスポート、Sketchプラグインの使用に関するいくつかのヒントとコツに関する情報が含まれています。

ここから開始ファイル

次に、UI-Kitはすべてのコンポーネント、タイポグラフィ、アイコン、色を含むSketchライブラリです。設計ファイルのすべての画面は、このライブラリのリンクされたシンボルを使用します。

UI-Kitは2つのページに分かれています。1つはシンボル用で、もう1つはすべてのデザインコンポーネントステッカーシート用です。後者には、各要素の詳細情報と直感的なレイアウトが含まれているため、探しているものをすばやく見つけることができます。

iOS UI-Kitファイルには、コンポーネントのステッカーシートとシンボル自体の両方が含まれています

残りのファイルは、アプリのさまざまな部分(オンボーディング、メール、カレンダー、検索、設定など)を表します。各カテゴリを分離することで、作業中の遅いファイルや遅れを回避できます。また、デザインをマージする場合にも利点があります。新しい機能を作成するときは、アプリの特定の部分に触れるだけで済むため、競合が少なくなるためです。

設計プロセスのステップスルー

最初のステップはブランチを作成することです。ブランチはマスター内のすべてのSketchファイルを取得し、レプリカを作成します。フォルダーを複製するようなものだと考えてください。ブランチを識別するために、作業中の作品に簡単なラベルを割り当て、ラベルの後に適切なタイトルを追加します。通常、「Feature」、「Kit」、「Exploration」などのラベルを使用してプロジェクトを説明します。 Outlookでは、新しいアイデアを試して、改善できると思われるものを変更することをお勧めします。これは、「Exploration」などのタグを使用した場合です。これらのラベルは、取りかかっている。ブランチを作成することは、複数のデザイナーが同じファイルで作業し、後でそれらをマスターにマージできるため、大きな利点です。

ブランチのラベル​​付けの例

新しいブランチでは、Abstract内から新しいファイルを作成します。ファイルに「Working」などの名前を付けます。これにより、他の人が最新の反復がどこにあるかを知ることができます。その後、他のファイルからこのボードにアートボードをコピーできます。フローを視覚化したり、既存の画面を変更したりするのに役立ちます。

「作業用」ファイルを作成する

Abstractから開いたSketchファイルには、プレビューとコミットのオプションを備えた小さなフローティングダイアログが含まれています。サーバーに作業を保存し、チームの他のメンバーが変更を確認できるようにします。コミットはマスターに影響せず、ブランチを更新するだけです。私のチームでは、1日に1回作業をコミットするという一般的なルールに従います。変更をコミットする前に、行った変更の概要を説明するメモを追加します。私は常にすべての変更にアクセスできるため、必要に応じて、変更を元に戻すか、ファイルの以前のバージョンを調べることができます。

毎日コミット

デザインが完成したら、レイヤーを整理し、デザインをマスターファイルにマージします。レイヤー名が正確であり、順序が画面に表示されている順序に従っていることを確認します(上から下)。これは、画面ごとに繰り返す必要があります。 [Kit]というラベルの別の新しいブランチを作成し、新しい画面を適切なファイルにコピーするか、最新のライブラリコンポーネントを使用してこれらの画面を最初から再作成できます。新しいファイルを開始する理由は、メイン画面のみをマスターに取り込むためです。 Abstractアーカイブ内の古いブランチは、後でいつでも再確認できます。少し時間がかかり、機能をより定期的に統合することはできません。統合プロセスを改善するための提案をお持ちの方からの連絡をお待ちしています。

以下は、ブランチを作成し、ライブラリのUIコンポーネントを使用してアプリの画面を設計する方法のデモです。この抽象とコンポーネントライブラリの組み合わせにより、チームに完全な透明性と可視性を提供しながら、迅速かつ効率的に作業できます。同じファイルから作業しており、新しいファイルは誰でも利用できます。

画像の説明:UIコンポーネントを使用してOutlook画面を構築します。

マージボタンを選択する前に、チームの全員にレビューをリクエストできます。リンクされたシンボルレイヤー、正しい名前付け、シンボルの複製、ライブラリの変更を探します。レビュー担当者は通常、アブストラクトのコメントセクションまたは特定のアートボードにフィードバックを残し、すべてを同じ場所に保持します。レビューが完了したら、設計をマージし、古いブランチをアーカイブします。

メンテナンスのベストプラクティス

私のチームは、キットを機能で更新する責任を共有し、特にオペレーティングシステムの更新または大規模な設計の見直しを考慮して、スケッチファイルを正常に保ち、キットを継続的に改善および更新する作業に取り組みます。

設計者はいつでもキットに関するフィードバックを提供し、問題を提起したり、改善の可能性について会話を開始したりできます。このフィードバックをGitHubの問題で追跡し、時間内に誰でも貢献できるようにします。以下に、UI-Kitで追跡したフィードバックの種類の例を示します。これには、重複アイコンの削除や、すべてのアイコンへの色のオーバーライドの追加が含まれます。

UIキットの問題を追跡するGithubの問題

マイクロソフトのプロセスとUIキットは、よりオープンで協調的なアプローチで設計するため、マイクロソフトの設計チームに受け入れられています。 Fluent Designがモバイルで進化するにつれて、マイクロソフト製品を通じて共通の要素が見られます。

私たちはまだ学習中で、プロセスを改善する方法を常に探しています。他のチームが設計プロセスでAbstractをどのように使用しているか、どのように改善できるかについての提案をお聞きしたいと思います。

コメントyourで自由にアイデアを共有してください。

Microsoft Designの最新情報を入手するには、Dribbble、Twitter、Facebookでフォローするか、Windows Insiderプログラムに参加してください。また、当社のチームに参加することに興味がある場合は、aka.ms / DesignCareersにアクセスしてください。

とMiles FitzgeraldとOutlook Teamの助けを借りて書かれました。