設計システムのリリース

相互接続された出力を経時的にアダプターに配信する

シリーズのリリースシステムの6分の1:
出力|ケイデンス|バージョン|壊す|依存関係|プロセス

企業は、顧客が使用するエクスペリエンスを作成および出荷するシステムを使用する製品を採用するときに、設計システムの価値を認識します。そのバリューチェーンの一部として、システムは時間の経過とともに機能をリリースします。これにより、システムが顧客の手に渡されます。デザイナーとエンジニアが仕事をします。

強力なシステムチームは、リリースを真剣に考えています。彼らは自分自身をコンポーネントライブラリコードだけをリリースしているとは考えていません。代わりに、設計トークン、ドキュメント、設計資産、その他のリソースなど、より多くの出力を提供します。

このシリーズでは、設計システムをリリースする多くの側面について説明します。まず、システムの多くの出力とそれらが配信される場所を定義します。後続の記事では、リズム、バージョン管理、重大な変更、依存関係、および段階的なアプローチのトピックについて説明します。

これらのストーリーは、Discovery Education、Morningstar、Target、REIなどのチームと連携してシステムをリリースすることで学んだことを反映しています。これらは、Salesforce、Adobe、Atlassian、Shopify、Financial Timesの同僚からの洞察によって高められています。あなたの時間と実践を丁寧に共有してくれてありがとう!

出力:何がリリースされますか?

設計システムプログラムは、コードだけでなく、多くの種類の出力をリリースします。その結果、システムはこのバージョンの出力を区別し、開発者、設計者、およびその他の顧客に伝える必要があります。

コード、真実の源

ほとんどのシステムは、プレゼンテーションレイヤーコードの単一の真実のソースを次のように提供します。

  • HTMLマークアップおよびCSSとしてのUIコンポーネントライブラリ。多くの場合「CSS」と呼ばれますが、このパッケージの消費は、HTMLスニペットの再利用と一貫した視覚スタイルベースラインとしてCSSを使用またはコンパイルすることにかかっています。

および/または…

  • JavascriptとしてのUIコンポーネントライブラリ:多くのシステムは、HTMLとCSSをJavaScriptでラップして、ロジックを強化し、スタイルをカプセル化し、選択したフレームワークでの統合と保守をより簡単にします。ほとんどのライブラリは特定のフレームワーク(React、Vue、Ember、Angularなど)を対象としていますが、業界のシグナルはすべてのフレームワークのWebコンポーネントを作成することへの移行を示唆しています。私の最後の6つのシステムの努力? 2017年後半:Vanilla HTML、Vanilla HTML。 2018年初頭:React、Vue。 2018年後半:Webコンポーネント、Webコンポーネント。

さらに、他の著名な出力が個別にリリースされる場合があります。

  • 意味的に意味のあるプロパティと値のペアを介して視覚スタイルを確立するトークンを設計します。トークンは、プラットフォーム(Web、iOS、Android)、プリプロセッサー(SassおよびLESS)、およびフレームワーク(Reactなど)で使用できるさまざまな形式の変数です。一部のシステムは、UIコンポーネントコードとは別にリポジトリでトークンを管理します。その結果、それらのライブラリは、他の実装とともに、パッケージとしてのトークンにも依存できます。
  • コンポーネントライブラリを使用して構築されたページの例を使用した環境としてのアプリ/サイトのデモ。デモは、デザイナーを含むチュートリアルやラピッドプロトタイピングにも使用できます。
  • iOS、Android、およびWindowsに適したクロスプラットフォームコンポーネント。

設計資産

ほとんどのチームは、リリースするものの理解を単純な「コードをリリースする」に限定しています。時間の経過とともに変化する他の多くのツールを公開していることに気付くのは目を見張るものです。以下が含まれます。

  • 設計ソフトウェアで提供されるテンプレートファイルおよびシンボルライブラリとしての設計ツールキット。今日、ほとんどの場合、スケッチです。明日、Figma、Invision Studio、その他の新興競合他社は?
  • フォント、アイコン、さらには折り紙の画像セットでさえ、そのようなライブラリの配布とバージョン管理におけるシステムの役割が期待されることが多いためです。
  • イラストやカラー見本ASE / CLRファイルなど、その他のデザインリソースは、特注のアートワークの踏み台として。これらのコレクションは、システムコアチームの一部ではないコミュニティメンバーによる貢献を介して、緩やかに変化します。しかし、顧客の視点とシステムのコミュニケーションから見ると、それはシステムの一部です。

ドキュメントサイト

設計システムには家が必要です。誰もが知っている場所であり、最新かつ最高のものになるすべてのものへの道を見つけることができます。覚えやすいURLに格納され、多くの場合、そのミッションに固有のUIコンポーネントで構築されます。

  • ドキュメントサイトでは、機能(ボタンなど)、新規ユーザーのオンボード、ヘルプの取得や貢献などのプロセスをトリガーします。チームは、静的サイトジェネレーターを使用してサイトを構築する頻度が高くなりますが、コンテンツ管理システムを使用してサイトを構築する頻度は低くなります。
  • ドキュメントコンポーネント– code-example-pair、do-dont、hex-code、component-explorer – UIコンポーネントライブラリに依存し、通常はdocサイトのみを提供します。このようなコンポーネントは、ドキュメントサイトでバージョン管理されるか、docとそれらが間に置かれるUIコンポーネントに関連する個別のバージョン管理された3番目のライブラリとしてバージョン管理されます。

目的地:どこに行きますか?

コードとデザインアセットを配布するときは、採用するエンジニアが最も使いやすい方法でコードを提供することが重要です。これは、いくつかのシステムは多くのオプションから選択できるようにしなければならないが、他のシステムは組織の標準として単一の選択に依存できることを意味します。

コード用

  • BEST:リリースされたコードパッケージへのアクセスと管理を提供するnpmjs(またはSonatypeのネクサスのような内部対応物)のようなレジストリ。その後、開発者はbower、npm、yarn、webpack、babelなどのツールを使用して、環境内でそのコードをスムーズに統合およびアップグレードします。
  • より良い:バージョン管理されたスタイルとスクリプト、およびよりゆっくりと変化するフォントとアイコンへの直接リンクのためのCDN上のホストされたアセット。
  • JOK OK:Github、Bitbucketなどへのリポジトリアクセスにより、クローン、フォーク、またはコンパイル、使用、そして最終的には貢献することができます。
  • 必要な場合:通常、ローカルで使用したり、別のリポジトリに手動で統合したりするための、ドキュメントサイトからのコンパイル済みまたは未コンパイルのシステム資産の「ZIPファイル」の直接コードダウンロード。

BootstrapおよびMaterial Design Liteは、2つ以上の宛先にリリースする例です。

設計ツールキット用

  • BEST:テンプレートから新しいインスタンスを作成するために、デザインツールのメニューに同期された埋め込みパスとして新規作成します。
  • より良い:AbstractやLingoなどの許可ベースの設計資産管理ソフトウェアを使用してバージョン管理および配布します。
  • 良い:ドキュメントサイトから直接ツールキットをダウンロードし、明確なバージョンが示され、関連する入門ドキュメントが近くにある。
  • JUST OK:よく公開され、おそらく簡略化された内部URL(http://system.uitoolkitなど)を介した共有ドライブ。
  • 十分ではない:多くの人が見つけることができないかろうじて組織されたwikiサイトの4番目のレベルのページに埋もれています。

次へ→#2。ケイデンス