デザインシステムテストとは？定義、メリット、プロセス紹介
デザインシステムが、高品質な製品を効率的に提供するのに必要なツール、ガイダンス、コンポーネント、サポートを確実に提供できるようにする上で、「テスト」は不可欠です。組織の基準や期待に確実に応えるために、コンポーネントライブラリ、ドキュメント、シンタックス、アクセシビリティなどのあらゆる側面を査定するものとして「デザインシステムテスト」というがあります。
本記事では、デザインシステムテスト、実施するタイミング、役割と責任、手順、使用できるツールについて見ていきます。
UXPin MergeのCode-to-Design（コードからデザイン）のワークフローによって、デザインシステムで「信頼できる唯一の情報源（Single source of truth）」を構築し、運用負荷を軽減してエラーを最小限に抑えましょう。詳しくは、Merge のページをぜひご覧ください。
デザインシステムテストとは
デザインシステムテスト（またはデザインシステム監査）はデザインシステムの機能性、使いやすさ、ドキュメント、品質、および一貫性を評価します。この評価によって、デザインシステムがユーザーやステークホルダーの要請や期待を満たしているかの確認を目的としています。
一般的なデザインシステムテストプロセスには、以下のようなものがあります：
- コンポーネントテスト： 個々の部品についての、視覚的な整合性や期待通りの機能であるかの評価。
- パターンテスト： UI（ユーザーインターフェース）やユースケースにおいて、パターンが一貫性があるかの確認。
- デザインファイルテスト： デザインファイルとレポジトリのコンポーネントの比較による、デザイナーとエンジニアが同じUIエレメントやパターンを共有しているかの確認。
- アクセシビリティテスト： コンポーネント、パターン、テンプレートがデザインシステムのアクセシビリティ の標準とガイドラインに適合しているかの検証。
- クロスプラットフォームおよびクロスブラウザテスト： 様々なデバイス、プラットフォーム、OS、ブラウザ間で、デザインシステムとコンポーネントが一貫して動作するかの確認。
- 性能テスト： 読み込み時間や応答性など、デザインシステムが製品全体の性能に与える影響の測定。
- ユーザビリティテスト： ユーザーリサーチの分析やインタビューの実施による、デザインシステムがポジティブなUX（ユーザーエクスペリエンス）に対応しているかの確認。
- ドキュメントのテスト： ブランド、コンテンツ、コード、デザインなどのガイドラインを含めたデザインシステムのドキュメントをレビューすることによる、それが包括的でユーザーに適切なサポートを提供するかの確認。
デザインシステムテストが重要な理由
デザインシステムテストは、UIライブラリと製品の整合性を保つうえで不可欠です。エラーや矛盾を放置しておくと、製品チームやエンドユーザーにとってすぐに大きな問題に発展してしまいますからね。
また、デザインシステムは「信頼できる唯一の情報源（Single source of truth)」として機能することを主な目的としています。デザインシステムが侵害されると、製品の一貫性と整合性を保つための信頼できるソースとしての役割を果たせなくなってしまいます。
デザインシステムテストを行う頻度
デザインシステムテストの頻度は、以下のような要因次第です：
- デザインシステムの規模や複雑さ
- デザインシステムの成熟度
- 人材、時間、資金などの利用可能なリソース
- 製品エコシステム
- アップデート頻度
ここでは、組織がデザインシステムテストを検討する場面とその間隔をご紹介します。
定期的な間隔でのテスト
デザインシステム（DS）チームは、毎月、四半期、隔年など、定期的なテストのスケジュールを作成するでしょう。そして、固定されたテストプログラムにより、DSチームはステークホルダーやユーザーの期待を考慮して計画を立てることができます。
大幅なアップデートや追加を行った後
デザインシステムチームは、大きなアップデートの後や新しいコンポーネント、パターン、ガイドラインを導入する際に、デザインシステムを監査するのが一般的です。この監査により、UIの一貫性と整合性の高い基準を維持しながら、変更点が確実に期待通りに機能するようにします。
ユーザビリティ、アクセシビリティ、性能に関する問題への対応
製品チームがユーザビリティ、アクセシビリティ、または性能の問題を発見した場合、デザインシステム全体を監査することが極めて重要です。監査によって、問題の深さと適切な是正措置が査定されます。
問題が発生するまで待つのは、デザインシステムテストにとって良い戦略ではないので注意しましょう。テストを定期的または随時で行うなど、より予防的なアプローチを採用する方が問題の早期発見や修正においても有効的です。
アジャイル開発
アジャイル開発を実践している組織では、開発プロセスに定期的なテストを組み込んでいる場合があります。このアジャイルアプローチは、テストがより頻繁に行われ、場合によってはスプリントやリリースサイクルに統合される可能性があるということです。
デザインシステム監査の責任者
全体的なデザインシステム監査には、さまざまな専門知識を備えた部門を超えたチームが必要である一方、小規模なテストより特定のテストの場合、１人または２人の専門家だけで済む場合もあります。
規模や範囲にもよりますが、デザインシステムテストで必要な役割リストをご紹介します。また、企業によっては、以下に挙げる複数の仕事を一人で担っている場合もあります。例えば、UXデザイナーはデザイン、アクセシビリティ、コンテンツを評価し、エンジニアはコンポーネントとQAを担当することがあります。
- UX/UIデザイナー：コンポーネントやパターンの視覚的な一貫性、使いやすさ、全体的な UXを評価する。デザイン関連のドキュメンテーションやツール、UIキットをチェックする。
- デベロッパー：フロントエンドとバックエンドのデベロッパーは、コンポーネントの機能、シンタックス、性能、実装を評価する。プラットフォームやブラウザを問わず、ライブラリのテストも行う。
- アクセシビリティの専門家：アクセシビリティの基準やガイドラインに関する最新の専門知識を持つチームメンバーであり、デザインシステムを組織や地域のアクセシビリティ要件に適合させるためのテストを行う。
- QA（品質保証）エンジニア： デザインシステムの品質基準に従ってテストを作成し、実行する。
- プロダクト/プロジェクト マネージャー：多くの企業では、テストをプロジェクトのように扱い、タイムラインの設定、リソースの配分、目的・優先順位の確認など、プロセスの調整と監督を行うチームメンバーを必要としている。また、このポジションは調査結果をまとめ、次のステップを含む最終報告書を作成することもある。
- コンテンツデザイナー/コピーライター：デザインシステムのドキュメント、コンテンツガイドライン、メッセージング、トーン、ボイスなどをレビューし、コンポーネントやパターン間の一貫性と正確さを確認する。
デザインシステムテストのワークフロー
ここでは、デザインシステム監査を実行するために推奨する手順をご紹介します。
- 目的・目標の設定： 矛盾の特定、アクセシビリティの評価、性能の査定など、デザインシステムテストの目的と目標を設定する。
- プランの作成： テスト計画は、監査の範囲、方法、リソース、スケジュール、成功基準を概説するものであり、効果的なテスト計画には、テストの指針、役割分担、チームメンバーの連携が必要。
- テストケースとシナリオの特定： デザインシステムのさまざまな部分を評価するために、チームメンバーが使わないといけない具体的なテストケースとシナリオを決定する。それは、KPI（重要業績評価指標）と性能を長期的に測定できるようにするために、各テストに対して一貫性がないといけない。
- ツールやリソースの準備：テストフレームワーク、アクセシビリティチェッカー、性能分析ツール、ユーザビリティテスト手法など、チームメンバーが作業を完了するのに必要なツールやリソースを収集する。
- テストの実行： 計画に従ってテストを実施し、その結果や問題点を文書化する。
- テスト結果の分析： テストをレビューし、パターン、傾向、懸念事項を特定する。問題の重大性を判断して修正に優先順位をつけ、UXまたは技術バックログに追加する。
- 報告書の所見および推奨事項： デザインシステムのユーザーやステークホルダー向けに、テスト結果、所見、推奨事項を記載した包括的な報告書を作成する。
- 問題の修正および改善の実施： デザインシステムチームは、報告書に従って、コンポーネント、パターン、ガイドライン、ドキュメントを必要に応じて更新や変更を実施しないといけない。
- モニタリング、再テスト、反復の実施： 問題を適切に解決していることを確認すべくリリースをテストする。変更をモニタリングして効果を評価し、望ましい結果が得られるまでテストと反復を繰り返す。
デザインシステムテストのためのツール
デザインシステムのさまざまな側面をテストするのに利用できるツールはたくさんあります。ここでは、UXPinが推奨するツールをカテゴリー別でご紹介します。
視覚的整合性のテスト
- Percy： コンポーネントやレイアウト間の視覚的な変化や不整合を検出できる、視覚的なテストのツール。
- Chromatic： UIのフィードバック収集、ビジュアルテスト、ドキュメントの作成を自動化する。
- SauceLabs Sauce Visual Testing：開発ライフサイクルの早い段階で、全ブラウザと解像度で視覚的なエラーや不整合を発見および修正する。
機能テストと統合テスト
- Jest：React、Vue、Angular などのJavaScriptライブラリやフレームワークのコンポーネントテストや統合テストに対応する JavaScriptのテストフレームワーク。
- Cypress：ブラウザベースの Webアプリケーションをテストするためのエンドツーエンドのテストツール。
アクセシビリティテスト
- axe：Webアプリケーションのアクセシビリティ問題の特定および解決のためのアクセシビリティテストのツール。
- Lighthouse：Google が提供するオープンソースツールで、アクセシビリティ、性能、その他のベストプラクティスの自動監査を提供する。
- WAVE：アクセシビリティの問題を特定し、解決するための Web アクセシビリティ評価ツール。
- UXPin：カラーコントラストチェッカーや色覚異常シミュレーターが内蔵されており、デザイナーはその場で UI をテスト行うことができる。
クロスプラットフォーム および クロスブラウザテスト
- BrowserStack：Web アプリケーションをさまざまな環境でテストするために、さまざまなブラウザやデバイスへのアクセスを提供するプラットフォーム。
- Sauce Labs：ブラウザ、プラットフォーム、デバイスにまたがる自動テストと手動テストのための、クラウドベースのプラットフォーム。
性能テスト
- WebPageTest：読み込み時間、レンダリング速度、最適化の推奨など、Webページの性能を測るためのオープンソースツール。
- Google PageSpeed Insights（グーグル・ページスピード・インサイト）： Web ページの性能を分析し、改善のための提案を行う無料ツール。
- Digital.ai Continuous Testing：様々なメーカーの OS を搭載したデバイスやブラウザで、機能、性能、アクセシビリティのシナリオを継続的にテストする。
ユーザビリティテスト
- UserTesting：リモートでユーザビリティテストを実際のユーザーと実施し、そのフィードバックやインタラクションを取得するためのプラットフォーム。
- Ethnio:：インターセプトを使って、製品や機能を使用する参加者をスカウトするためのリサーチオプスプラットフォーム。特定のコンポーネントやパターンと相互作用するユーザーからのフィードバックを得るのに有効。
- Optimal Workshop：カードソーティング、ツリーテスト、ファーストクリックテストなどの、ユーザビリティテストツール群。
- UXPin Merge：正確な高忠実度ユーザビリティテストのために、デザインシステムのコンポーネントを使ってプロトタイプを構築するためのツール
デザインシステムのドキュメントと連携
- Storybook：UIコンポーネントを構築・整理するためのオープンソースツールで、これによってデザインシステムテストが協調的かつ身近なものになる。また、Storybookは UXPinと統合され、デザインと開発のギャップを埋めることができる。
- UXPinデザインシステム：ドキュメント、アセット、スタイルガイドを共有したデザインシステムを構築、管理、拡張するためのツール。
UXPin Mergeによる「信頼できる唯一の情報源」
特にデザインと開発の間に「信頼できる唯一の情報源」がない場合、メンテナンスとガバナンスはデザインシステムで最大の課題になります。
UXPin Mergeでは、デザインシステムのレポジトリとUXPinのデザインエディタを同期させ、デザインとエンジニアリングチームが同じコンポーネントライブラリを使用することで、デザインと開発のギャップを埋め、組織全体で「信頼できる唯一の情報源」を作成します。
UXPin Mergeのコードからデザインワークフローについての詳細と、メンテナンス、連携、ガバナンスの向上など、デザインシステムにどのようなメリットをもたらすかについてぜひご体験下さい。詳しくはMergeのページをご覧ください。
