優れた設計システムのレシピ

公開: 2022-03-10

簡単なまとめ↬設計システムの保守は大変な作業です。この記事では、Atila Fassinaが学んだ教訓と、Backlightなどのプラットフォームが一連のツールを組み合わせてアーキテクチャのセットアップを高速化するのにどのように役立つかを共有します。

理論的には、「デザインシステム」の意味については、誰もが比較的似た概念を持っていますが、現実の世界に近づくにつれてニュアンスが現れ始めます。目標は同じかもしれませんが、組織が異なれば、それを達成するためにさまざまな戦略が必要になります。エンジニアリングやアーキテクチャにおける多くの複雑なタスクと同様に、優れた設計システムを作るための特効薬はありません。

成功した取り組みは、ツールとベストプラクティスの発生を可能にするいくつかの共通のパターンを共有しています。この記事では、設計システムの傘の中にどのようなソリューションが適合するか、およびプロジェクト全体で監視する必要のあるいくつかの重要な手順とチェックポイントについて説明します。私たちの経験は異なるかもしれませんが、うまくいけば、私が個人的に失敗して成功したあなたのための学習があるでしょう。

目標と意味

「システム」を部品の組み合わせとして、「デザイン」を何かの見た目と機能の計画と考えると。 次に、設計システムを、システムの相互接続部分が外観、感触、および機能するパターンを指示する定義の集合として理解できます。これはまだかなり抽象的なものですが、見た目以上のものとして理解するには十分です。

これは、パズルのように組み立てて一貫したレイアウトに到達するコンポーネントライブラリではありません。デザインシステムには確かにプレゼンテーションの側面がありますが、それは機能と統合にも関係しています。それは経験についてです。

ユーザー体験
信頼性が高く、機能的に一貫性のあるユーザーインターフェイスを備えています。
開発者の経験
統合が容易なコンポーネントと定義されたパターンを備えています。
利害関係者の経験
製品がどのように進化し、成長するかについての一般的な概要を示します。

非常に多くの可動部品があるため、すべての設計システムに単一の答えがあるわけではないことは理解できます。

意図的vsオーガニック

チームが設計システムを作成することを決定する場合、事前に決定する必要がある2つのアプローチがあります。

オーガニック
既存のアプリを参照し、その一部を抽出して、別のアプリで使用できるように抽象化します。このアプローチでは、最初から決定が少なくなりますが、採用者が新たに見つけた要件に対応するために、チームによるより積極的な取り組みが必要になります。アーキテクチャ上の決定は、積極的にではなく、必要に応じて行われる傾向があります。
意図的
トークン、パターン、およびコンポーネントは事前に検討されます。最小実行可能製品（MVP）の境界が定義され、作業が開始されます。このアプローチでは、目標と要件を持つことが、期待を利害関係者と一致させるための重要なステップです。

オーガニック

設計システムが有機的に発展することを可能にするとき、努力の成功は利害関係者と採用者からの賛同に帰着します。そして、チームが継続的なサポートで過度に混乱することなく、途中で見つけたすべての未知数をクリアするときに、チームがどれほど効果的に対応できるか。それはトリッキーな道であり、コミュニケーションが鍵となります。チームのコンテキストと緊密に連携しているため、明確な行動経路はありません。

さらに、システムの実行中にシステムを微調整することは難しく（地元の電気技師に尋ねてください）、タスクに時間がかかるため、要件が変わる可能性があります。市場はコンポーネントライブラリを待ちません。有機的な設計システムの通常の「成功または失敗」の瞬間は、コンポーネントMVP（最小実行可能製品）の開発ストーリーを見つけることです。

一方では、可能な限り最高のエクスペリエンスと典型的なコード品質を作り上げたいと考えている開発者やデザイナーがいます。一方、成功を測定するためのKPI、ROI、およびその頭字語のバンドがあります。バランスを見つけてスケーラブルな状態を維持するのは難しいです。未完成のものを抽象化する方法はさらにトリッキーであり、これらのフォローアップタスクがバックログで忘れられないようにすることは、製品管理の100万ドルの問題です。

設計システムで迅速かつ段階的に反復できることは、有機的なアプローチを扱う際の基本的な要件になります。また、消費者開発者からの追加レベルの明確さも必要です（1つは設計システムを作成し、もう1つは製品機能を作成するという別々のチームがある場合）。適切な共生を実現するには、両方が製品要件と開発者エクスペリエンス要件に明確に期待を合わせる必要があります。デザインシステムは、使用するのが面倒な場合や、ユーザーエクスペリエンスを何らかの形で悪化させる場合は、何の意味もありません。

意図的

設計システムを使用する製品を用意する前に、設計システムを構築することを意識的に選択する際には、さらに多くの計画が必要であり、未知数をクリアし、インフラストラクチャを準備する必要があります。裏返しは、制約により明確になります。目標と期待。港を出る前に帆を再確認すれば、嵐はそれほど恐ろしくありません。

システムの予測可能性は、事前に計画するときにも向上します。これは、設計システムが独自の製品になり、他の人をより良くするためのツールではないためです。この抽象化により、他で使用されているパターンとソリューションをより簡単に転送できます。

有機よりも意図的な選択は、テストする概念実証がないため、経験の少ないチームにとっては逆効果に見えるかもしれませんが、開始時に一般的な落とし穴を回避することは特に役立ちます。「巨人の肩の上に立つ」というのは一般的な専門用語であり、この場合は真実です。したがって、これから先の最良のレシピは大まかに次のようになります。

基本的な要件を特定します。
同様のケースについて早期かつ徹底的に調査します。
スキムは、暗黙のソリューションと戦略の2から得られます。
一般的なソリューションの組み合わせを組み立て、独自のソースを追加して、すべてを独自のものにします。
繰り返します。

これらの5つのステップは単純で明白に聞こえるかもしれませんが、そうではありません。要件収集の1つをスキップしたり、調査を短縮したりするのは簡単です。ただし、アドバイスの一部です。これらのいずれかを忘れた場合は、ステップ4で利息を支払うことになります。

効率化のための構築

依存関係の更新によってアプリが破損した場合、パッケージの利用者はそれを楽しむことができません。問題のパッケージがデザインシステムの一部である場合も同じです。実際、それはもっと悪いことを指摘することができます。アプリを壊す社内の依存関係の反発は、オープンソースパッケージの場合よりも大きくなる傾向があります。さらに、UIの変更は、最初にエンドユーザーの前で「静かに壊れる」傾向があります。これは特に苛立たしいことです。

それを念頭に置いて、私たちはすでにいくつかの問題を並べることができます：

APIドキュメント
簡単に見つけて使用できるようにします。
バージョニング
リリースが消費者にどのように影響すると予想されるかを示します。
変更ログ
各リリースでどのような変更が行われるかを示します。
リリース
安定したコードをすべての消費者に簡単に提供できるようにするための正しい方法。
開発環境
それを使用しているアプリはまだありません。アーティファクトを紹介して開発する方法を理解する必要があります。

重要な点として、これらの各アイテムの優先度は、マイレージによって異なる場合があります。しかし、設計システムの拡張、採用の増加、機能の拡大に伴い、それらの必要性は高まります。チームが前進するのを妨げるのに十分ではないかもしれませんが、それらのソリューションを理解するために容量が歪められている場合、それらは確かに生産性を妨げます。

信頼できる情報源

多くのチームが直面するもう1つの最終的な問題点は、設計システムの信頼できる情報源を特定することです。それはコード、UI、またはドキュメントですか？多くの種類の製品について、私たちは消費者側に目を向けるだけで、主な出力が何であるかを簡単に特定できます。この場合に注意が必要な理由は、消費者の種類ごとに使用方法が異なるため、回答は人口統計に基づいて異なるためです。

デザインシステムは、多くの場合、コンポーネントライブラリ、ドキュメント、およびスタイルガイドを組み合わせたものです。そして、消費者はそれらのアーティファクトごとに異なるだけでなく、職人も異なります。開発者、デザイナー、テクニカルライター。各出力を作成するには、さまざまな人が必要になります。

焼き芋

配信の一貫性を保つには、コミュニケーションとコラボレーションが重要です。そして、すでに確立されている滝のようなプロセスは、どちらも勇気づけられません。

各専門分野に基づいたコラボレーションまたは反復のための設計された（しゃれを意図した）スペースはありません。多くの場合、デザイナーはいくつかのコードの制限に気づいておらず、開発者は出力用のUXについて無知です。このアプローチは極端に不利ではなく、それを使って良い製品を作ることは可能です。しかし、すばらしいものは難しいものです。チームが積極的に修正しない限り、プロセスの各部分はほとんど切断されています。

常に素晴らしいダンモールとブラッドフロストは、新しいプロセスの同じように素晴らしい名前を作り出しました：ホットポテト。このプロセスは、コミュニケーションを促進するだけでなく、作業の真実の情報源を統合することにより、チームに直接的なコラボレーションを課します。これにより、提供された各アーティファクトは共通の起源を共有するだけでなく、結合されたチームの専門知識の産物でもあります。

ただし、この種のコラボレーションを摩擦のないものにすることは、口で言うほど簡単ではありません。「あなたはミュートされている」、「私の接続が切断された」、「あなたは私を聞くことができますか？」をかわすために並んで座っていても。煩わしさは、情報交換を併置すると非公式になりがちであり、その結果、プロセスを文書化するのが困難になったり、同期しすぎたりする可能性があります。ボトルネックを減らしたいのですが、増やしたくないのです。

ライブコラボレーションは、ピア間で非常に長くなりました。 VSCode ShareやFigmaのFigJams、クラウドIDEのように、多くのオプションがあります。しかし、異なる専門分野間を繰り返すことになると、それは非常に簡単ではありません。これを前のセクションで説明したツール、アーキテクチャ、またはプロセスの山に追加すると、作業を開始する前に行うべき作業の山ができます。

システムの設計

上で指摘したように、設計システムの維持は大変な作業です。最善のアドバイスは、可能な限り最初から物事を行わないようにすることです。便利な場所でコミュニティリソースを使用してください。そうすることで、システムの特定のポイントを維持する時間が短縮され、システムの特定のチャンクに既に精通している場合は、エンジニアや設計者のオンボーディングに役立ちます。

入ってくるのはバックライトです。これは、一連のツールを独創的でありながら柔軟な方法でまとめて、このアーキテクチャ全体のセットアップを高速化するサービスとしてのプラットフォームです。最初から開始することも、プロジェクトに最適なスターターテンプレートを選択することもできます。完全に必要でない場合でもホイールは再発明されません。すべてのスターターでコミュニティリソースを使用し（私が試したもの、YogiはChakraUIに基づいています）、メンテナンスが少なく、消費者はロックインされる心配がありません。さらに、コードはバージョニングプラットフォームにプッシュされるため、必要に応じて移動するのはシェルコマンドのほんの一部です。

そこで、バージョン管理プラットフォーム（GitlabとGitHubがサポートされています）、Storybookベースのサンドボックス、VSCodeベースのIDE、単体テスト、さらにはNPMレジストリへの公開との統合を手配します（これは、それらを使用する計画によって異なります。あなたのアカウントまたは彼らのアカウントにすることができます）。

複数の出力

以前にマッピングしたのは、ほとんどの設計システムが必要とする少なくとも3つの異なる出力（ドキュメント、コード、ユーザーインターフェイス）です。アーキテクチャがそれらのそれぞれを出力する準備ができたら、チームは通常、それらを同期させるという別の課題を見つけます。開発者は常にアトミックな変更を熱心に行っています。1つの場所に触れると、その情報を消費するすべての場所に広がります。設計システム内では、それを達成する方法が常に明確であるとは限りません。

Hot Potatoプロセスに従わない場合、開発者がどのUIアップデートにすでに対応しているかを見失いがちです。そして、あなたがそうするとしても、ドキュメントがあります。バックライトは、すべてをまとめることでこの問題に対処します。

UIプレビューの横にあるコードを更新すると、ストーリーブックのストーリーが自動的に作成されます。（大プレビュー）

そして、プラットフォームのダッシュボードを離れることなく、変更が行われると。更新されたライブドキュメントを確認することができます。

ストーリーブックとフィグマのタイポグラフィドキュメントがタブに表示されます（大きなプレビュー）

そして、これはすべて、アーキテクチャを強化できるもののほんの一部にすぎません。また、次のようになります。

「ビジュアルレビュー」機能を使用したプルリクエストのスクリーンショットテスト
テスト駆動開発-単体テストが組み込まれた開発サポート
ライブプレビュー付きのサンドボックス

これは、設計システムの完全な開発環境です。また、スターターを使用しないことにした場合でも、これらすべての統合を取得できます。インフラストラクチャは、設計システムに最初からフィードするコンポーネントライブラリを構築するためにあります。

リアルタイムのリモートコラボレーション

前述のように、ホットポテトプロセスは、チームがリモートで非同期の作業方法を設定するのが面倒になる可能性があります。バックライトは、2つの機能の組み合わせでこれに対処します。

デザイン統合;
ライブリンクを共有します。

デザイン統合は、同じプラットフォーム内のデザインツールからデザインアーティファクトをもたらします。そのため、チームの他のメンバーは、同じダッシュボードから直接、作業を確認、コメント、および参照できます。

この機能を使用すると、チームの場所に関係なく、ホットポテトプロセスが製図板から開始されます。また、タブを切り替えることなく、リンク共有機能を使用してコーディングプロセスをスムーズに行うことができます。これは、私が自分でできることよりも、プロモーションGIFで説明されています。開発者は、どこにも物事を公開することなく、中間プロセスなしで、自分の作業のリアルタイムのリモートリンクを共有できます。これは、詳細な作業を迅速に繰り返す必要があるチームにとって大きな後押しとなります。

要点

まだの場合は、うまくいけば、設計システムの作成と維持に何が必要かが明確になります。一握りのCSSクラス、トークン定義、書体をはるかに超えています。それは、ツール、積極的なサポート、およびアドボカシーです。プロジェクトの有用性は、その出力の品質と、絶えず変化する要件にどれだけ迅速に適応できるかによって決まります。

したがって、他に何もないとしても、プロジェクトを作成するときは、生産的かつ効率的になるように準備してください。それでも問題が解決しない場合は、Backlightなどのツールを使用すると、実用的なデフォルトと優れたユーザーエクスペリエンスをすぐに利用できます。すでに特定のアーキテクチャで熟練している場合は、戦闘を賢く選び、コミュニティを使用して残りを処理します。