Design System Ops（デザインシステムOps）とは？

キーポイント

Design System Opsは、デザインシステムとその構成要素を運用し、標準化するための方法である
チームの非効率な作業を減らし、ワークフローを最適化し、デザインシステムを普及させ、システムの拡張を簡単にすることができる
Design System Opsは、ただユーザーを特定し、取り除きたいDesign System Opsの問題を定め、解決策を実行し、その効果を測定するもので、誰でも始められる
UXPin MergeはデザインシステムからUIコンポーネントをインポートし、そのコンポーネントを使ってデザインエディターでプロトタイプを作成しやすくするツールであり、Design System Opsに最適

企業や部署が効率性を追求し、運用コストを削減するにつれて、より多くのOpsの役割が見出されています。DesignOpsという言葉は聞いたことがあると思いますが、Design System Opsについてはご存知でしょうか？

本記事は、2017年にUXPinが開催した、当時Shopifyのデザインシステム「Polaris」を担当していたカエリグ・ドゥルモー・プリジェント氏によるウェビナー「Design System Operations」の講演をもとに構成されています。

Design System Opsが何をするのか、企業でどのように始めればいいのかを見出すには、DesignOpsの基本を網羅した無料のeBook「DesignOps 101: Guide to Design Operations」を強くお勧めします。

世界最先端のエンドツーエンドデザインツールUXPinで、デザインシステムを最適化しましょう。1チームのスタートアップ企業でも、世界中に数千人の従業員を抱える多国籍企業でも、UXPinはそのニーズに対応するソリューションを搭載しています。無料トライアルにサインアップして、UXPinの機能をご体験ください。

デザインシステムの目的

デザインシステムは、デザイナーやエンジニアに、製品を迅速かつ一貫性をもって構築し、拡張するためのツールを提供しなければなりません。デザインシステムは単なるコンポーネントの集まりというだけではなく、チームメンバーがブランドとユーザビリティの要件を満たす製品を確実に出荷できるよう、ユーザーにドキュメンテーション、ベストプラクティス、原則、ガイドラインを提供するものです。

Design System Opsとは

Design System Opsは、新しいデザインシステムのコンポーネントやテンプレートをデザインからリリースまで持っていくためのプロセスと基準を最適化することを目指しています。ツールやプロトコルによる摩擦のないデリバリープロセスで、「決断疲れ」の軽減を目指し、この最適化により、デザインシステムチームは、操作方法や意思決定よりも、創造性、革新性、迅速な納品により時間をかけることができるようになります。

Design System Opsの必要性

UXとデザインシステムの専門家であるネイサン・カーティスは、2016年のMediumの投稿で「デザインシステムはプロジェクトではなく、製品であり、サービスである。」という名言を残しています。 Design System Ops は、デザインと開発のギャップを埋めながら、ユーザーと製品に貢献するために、ワークフローの非効率性を削減しなければいけません。よって、新しいリリースがオリジナルのデザインの忠実度、機能性、使いやすさを反映するように、ツールとプロセスを導入することを目標としています。

Design System Opsの責任者

Design System Opsのマネージャーは、デザイン・開発両方のプロセスを理解し、効果的に問題を特定し、解決しなければならないため、デザインと開発両方の経験がないといけません。また、Opsのマネージャーは、デザインシステムの構築、管理、拡張に関する基本的な理解なしに運用を最適化することはできないので、デザインシステムに関する知識と経験も不可欠です。

デザインに特化した従来のDesignOpsや開発に特化したDevOpsとは異なり、Design System Opsは、この2つの分野にまたがってデザイナーとエンジニアをサポートします。

Design System Opsがデベロッパーをサポートする仕組み

design and development collaboration process product communication

リリースが設計仕様を確実に満たせるように、Design System Opsは多くの時間をかけてデベロッパーをサポートするツールを作成しています。オペレーションは、エンドツーエンドの開発プロセスに目を見て非効率な部分を見つけ、解決策を提供します。

ここでは、Opsのデベロッパーサポート事例を紹介します。

デザインハンドオフ – パフォーマンスのためのデザインの最適化

デザインから開発まで、画像やアセットに何が起こるのかを、Opsが定める必要があります。例えばアセットをPNGからWebpに変換する必要がある場合、どのように行うのでしょうか。変換ツールがありますか、それとも手動でしますか？
エンジニアがアセットをロードするのに最適な方法は？
エンジニアが使用するアセットのフォーマット（PNG、JPG、SVGなど）は？
デベロッパーはビルド時に画像を最適化しますか、それともCDNを使いますか？
最高の出来を出すのに、アセットのHTMLやCSSマークアップを標準化・最適化します
Web、iOS、Androidなど、さまざまなプラットフォームで、エンジニアはどのようにフォントを使いこなしていますか。

デベロッパーのエクスペリエンス

ローカル開発環境は、エンジニアがすぐに構築を開始できるように、素早くセットアップできなければいけません。例えば、新しいプロジェクトの作成は、yarn start や npm start など、技術スタックが使う方法で簡単に始められるはずです。
コードを書くための標準と実践であるリンターの構成です。
Opsは、「新しいコンポーネントをどのように構築するか？」という質問に答えなければなりません。最大限の一貫性と効率を確保するために、デベロッパーはどのようなステップを踏まないといけませんか？
アップデートのリリースは、ボタン1つで簡単に行えることが望ましいのですが、Opsはこのようなプロセスをどのように実行しているのでしょうか？

テスト

Opsは、デベロッパーがローカルでどのようにテストを実行し、そのプロセスにどれくらいの時間がかかっているかの査定が必要です。エンジニアがテストの実行を無駄に待たなくていいように、必要であればテストを効率化するためのツールや方法を探します。
視覚的回帰テスト：コンポーネントの変更はデザインシステムにどのような影響を与え、そしてデベロッパーはどのようにテストしますか？
例えば、ALTタグのコードを検査するためのツールを使用するなど、Opsはどのようにしてアクセシビリティ・テストを最適化・自動化しますか？

上記は、エンジニアをサポートするDesign System Opsのアプローチの一例です。総合的なテーマは、「エンジニアがより早くリリースを出せるように、いかにして意思決定を減らすか」です。

デザインシステムチームとそのユーザーは、「これはどうすればいいですか？」、「これはどこにありますか？ 」といったことを聞かないようにならなければなりません。このことから、Opsはデザインシステムの効率を最大化し、リリースの市場投入までの時間を短縮することを目指します。

Design System Opsに入る前に

1. ユーザーは誰ですか？

Design System Opsを実行するには、ユーザー調査から始める必要があります。まずは、「チームメンバーがどんなツールや言語を使っているのか？」

デベロッパー向け：現在の技術スタックと、エンジニアが使っているIDは何ですか？
デザイナー向け： UXデザイナーはどのようにワイヤーフレーム、モックアップ、プロトタイプを作成しますか？

Design System Opsがチームの仕組みを理解することで、非効率な部分を発見し、修正することに繋がります。ここではデザインシステムのリリースプロセスにおけるネックになっているものと障害物を見つけることを目指します。

2. 問題の把握

Opsが問題を突き止めたら、正しい解決策を実施するために問題をきちんと特定することがとても大切です。例えば、それはプロセスに問題がありますか、それともトレーニングが必要ですか？

3. 発見事項の実施

Opsは、特定の問題に対する解決策を見出したら、それを実行に移さなければいけません。実行には、トレーニングの提供、利用促進のためのワークショップ、ドキュメントの更新などが含まれる場合があります。

4. 成果の測定と経過観察

Design System Opsは、デザインシステムとそのユーザーを監視・測定するために、様々なツールや指標を使用しています。例えばデザインシステムのウェブサイトがある場合、Google Analyticsなどのツールでクリック数、ダウンロード数、その他の指標を追跡し、人々がどのように利用しているかを確認できます。またOpsは、以下のような重要な指標を監視して、問題やネックになっているものの特定も考えられます。

ビルドタイム：デザインからリリースまで、デベロッパーが新しいコンポーネントを作るのにかかる時間
平均復旧時間（MTTR）：デザインシステムの問題を解決するのにかかる時間。
品質：エラーや手戻りの発生率。ユーザビリティやアクセシビリティに関する問題の発生頻度。

UXPinのDesign System Opsのウェビナーでカエリグ・ドゥルモー・プリジェント氏が言及しているように、「成功は、配置したツールではなく、解決した問題によって測られるべき 」なのです。つまり、壊れていないものをすぐに直そうとしないことです。Design System Opsは、ツールを導入することではなく、非効率な部分を発見して修正することです。

UXPin Mergeでデザインシステムを最適化する

デザインと開発の間のギャップを埋めるのに、UXPin Mergeは、これ以上ないほど簡単なツールです。 MergeでレポジトリにホストされているデザインシステムをUXPinのエディタに同期させることができるので、デザイナーは完全に機能するコードコンポーネントでプロトタイプを構築することができます。

14日間のトライアルにサインアップして、MUI統合によるUXPin Mergeを体験してみてください。