Storybook をデザインシステム開発で活用するには？
デザインシステムの開発および維持のための「DevOpsツール」といえば Storybookですね。優れたドキュメントや直感的なUI、さらに内蔵されたテスト、コラボレーション機能は、コンポーネントの構築や市場投入するために最適なツールです。
Storybookの仕組みを理解することで、デザイナーとフロントエンドの連携強化や、プロトタイプやテストへのデザインフロー改善のために内蔵された機能を最大限に活用することができます。
Mergeはドラッグ＆ドロップによってプロトタイプが作成可能な環境を提供します。レポジトリにあるコンポーネントを使ってインタラクティブなプロトタイプを作ってみましょう！詳しくはUXPinのStorybookページをご覧ください。
エンジニアがデザインシステムで Storybook を選ぶ理由
Storybook がデザインシステムの管理に最適なDevOpsツールであるのには、以下のような理由があります。
コンポーネントを切り離して開発およびテストをする
Storybookで、エンジニアは UIコンポーネントを分離して開発できるようになります。この開発ワークフローは、デザインシステムや多くの組織でコンポーネントライブラリに使われているReactのようなコンポーネント駆動型のフロントエンドフレームワークに最適です。
Storybook以前では、エンジニアは CodePenやCodeSandboxのようなサンドボックス（プログラムがシステムの他の部分に悪影響を及ぼすことのないように設計された環境）のプラットフォームを使って、コンポーネントを分離して構築やテストをしていました。Storybookは、このサンドボックス型の開発環境を、エンジニアやステークホルダーが UI 要素を閲覧、テスト、承認するための直感的なユーザーインターフェースで提供します。また、コンポーネントを組み合わせたり、テスト用の小さなプロトタイプパターンの作成もできます。
QA（品質保証）
分離して開発することは、デザインシステムの QA（品質保証）においても多くのメリットがあります。エンジニアは、リリース前にデザイナー、プロダクトマネージャー、その他のステークホルダーに新しい UI要素のテストやフィードバックを依頼することができます。
ドキュメント作成
コンポーネントライブラリにとってドキュメント作成は非常に重要ですが、時間を要するので、誰でも後回しにしたいと考えてしまいますよね。
StorybookのDocsPage は、基本的なドキュメント作成を自動化するzero-config（設定不要）でのデフォルトドキュメントであり、プロダクトチームやエンジニアリングチームは、このドキュメントを活用して、使い方やガイドラインの情報を作成することができます。
信頼できる唯一の情報源（Single source of truth）
クロスプラットフォームアプリケーションのコードベース管理は大変ですが、Storybook だと、一元化された環境から各プラットフォームのコンポーネントやパターンをテストするための「信頼できる唯一の情報源（Single source of truth）」が提供されます。
エンジニアはコンポーネントやパターンを並べて見ることができ、iOS、Web、Androidなど各プラットフォームを担当するエンジニアと連携できるため、一元管理された環境はデザインの一貫性を高めます。
アクセシビリティ
Storybook の A11y Accessibilityアドオンで、エンジニアはアクセシビリティテストを自動化することができます。このアドオンでは、各要素に新しいアクセシビリティタブが作成され、以下の３つのカテゴリーで WCAG （Webコンテンツのアクセシビリティに関するガイドライン）規格が表示されます：
- 違反：解決すべきアクセシビリティの問題がある
- 合格：基準を満たしている
- 未完成： アクセシビリティの ToDoチェックリストに追加
Storybook デザインシステムの活用方法
Storybookのドキュメントには、デザインシステムにおける5ステップのワークフローを紹介します：：
- ビルド
- ドキュメント作成
- レビュー
- テスト
- 分配
１．ビルド
エンジニアは Storybookをセットアップし、GitHubレポジトリに接続すると、各コンポーネントとそのバリエーションの開発を始めます。例えば、ボタンにはステートやサイズ、タイプなどいくつかありますね。
ビルドプロセスにおいて、エンジニアは Storybookのアドオンをインストールすることで、ワークフローの自動化、他のツールとの統合、Storybook 環境の拡張ができます。
２．ドキュメント作成
エンジニアは、ビルドプロセス中にコンポーネントにコメントを追加して、自動生成されるドキュメントを充実させることができます。Storybookのドキュメントにあるこの例では、このようなコメントが StorybookのUIにどのように表示されるかが示されています。
このドキュメントは、フロントエンドエンジニアがデザインをどのように解釈し、それぞれのプロップが何を表しているかをステークホルダーに示すことから、次のステップで非常に重要になります。
３．レビュー
これでコンポーネントはステージングされ、デザインシステムにする準備は整いました。エンジニアは、デザイナー、プロダクトマネージャー、その他のステークホルダーに聞いて、要素のデザインやインタラクティブ性を確認するといいでしょう。
従来は、エンジニアがステージング環境を作ったり、ステークホルダーと会ってコンポーネントをプレゼンする必要がありましたが、Storybook では、Webサイトにアクセスするのと同じくらい簡単に、レビュープロセスをより身近なものにすることができます。
そしてステークホルダーは、好きなタイミングでログインし、コンポーネントに触れ、ドキュメントを読み、フィードバックを残すことができます。
変更点があれば、エンジニアは新しいコンポーネントがステークホルダーの要望に応えるまで、ステップ１から３を繰り返すこともできます。
４．テスト
JestとPlaywright は、Storybook の「フレームワークにとらわれないテスト」を実現します。エンジニアがコンポーネントを作成すると、Storybook は、以下のようなプログラミングエラーが確実にないようにするために、コードをテストします：
- ビジュアルテスト（視覚的回帰テスト）：各コミットのスクリーンショットを作成し、それを比較することで UIの不整合を検出する。
- アクセシビリティテスト：WCAG（Webコンテンツのアクセシビリティに関するガイドライン） 基準に照らしてコードを実行し、問題があれば報告する。
- インタラクションテスト：リンクや機能に問題がないか、インタラクティビティやステートをチェックする。
- テストカバレッジ：条件、論理分岐、関数、変数など、業界標準に照らし合わせてコードを検査する。
- スナップショットテスト：レンダリングされたコードをベースラインと比較することで、マークアップの変更を特定する。
５．分配
最後は、GitHub でのデザインシステムのパッケージの更新です。完了すると、変更内容が自動的に npm に同期され、エンジニアはその更新されたnpmパッケージをインストールすることで、新しいコンポーネントを使えるようになります。
UXPin Mergeでデザインを Storybook と同期させる
デザインチームが UXPin Mergeを使っている場合、このような技術的変更はUXPinのエディター上で最新のデザインシステムのリリース内容がチームメンバーに通知されます。
バージョン管理は、デザイナーがいつでも変更でき、以前のバージョンのデザインシステムに切り替えることもできます。
UXPin Merge とは
UXPin Mergeは、デザインと開発のギャップを埋める（Mergeする）技術です。組織は、デザイナーがエンジニアと同じコンポーネントライブラリを使って、完全に機能するプロトタイプを構築することができるように、レポジトリにホストされているデザインシステムをUXPinのデザインエディターに同期させることができます。
Mergeコンポーネントは完全にインタラクティブであり、色、タイポグラフィ、ステート、サイズなど、デザインシステムで確定された Reactプロップ (StorybookではArgs) を含みます。そのプロップは、デザイナーが絶対的な一貫性と摩擦がない状態を維持しながら、プロトタイプの要件を満たすようにコンポーネントを調整することができるように、UXPinのPropaties Panel（プロパティパネル）に表示されます。
テストとステークホルダーからのフィードバックの強化
Mergeのプロトタイプには、同じコンポーネントが使われるため、最終製品のような見栄えと機能が備わっています。たとえば、Storybookのボタンは、UXPinでもインタラクティブ性やスタイリングを含めてまったく同じようにレンダリングされます。
ユーザビリティテスト参加者やステークホルダーは、このような UI要素やMergeプロトタイプを最終製品と同じように操作することができ、それによってデザインチームに正確で実用的なテストインサイトがもたらされます。
「UXPinを使うことで忠実度の高いプロトタイプを作成できるのでとても助かっています。高忠実度のプロトタイプをより早く作成・修正できて、すぐにフィードバックを得ることができます。」Erica Rider – UX Lead EPX, PayPal「PayPalがUXPin Mergeでデザインプロセスを拡張した方法」
UXPin Patterns（パターン）によるコンポーネントライブラリの拡張
デザインシステムは、製品の成長や規模に合わせて進化していき、デザインシステムチームは常に新しい変更を加え、新しいUI要素やパターンを推進しています。
Patterns機能で、デザインチームがデザインシステムに対して新しいパターンを作成できます。デザイナーは、分子や原子単位でUI要素を組み合わせて新しいパターンを作成できます。現在のライブラリがニーズに対応していない場合は、npm統合を使用して、オープンソースライブラリからコンポーネントをインポートすることができます。
デザイナーは，このようなパターンを保存して組織全体で共有することができるため、チームは、デザインシステムチームがガバナンスの手順に従って新しいコンポーネントを開発しリリースするのを待つ間、プロトタイプを作成し続けることができます。 上で説明した５つのステップのStorybook開発プロセスに沿った作成ですね。
UXPin Mergeによる第４段階のデザインシステム成熟度
Iress は２０１７年に第３段階のデザインシステム成熟度を達成しました。その後数年間、デザインシステムチームは、最終成熟度である第４段階 – 完全統合に到達するためのデザインツールを探しました：
- コード又はノーコードでデザインする
- デザインドリフトがない
- 一貫性のあるデザイン
- シームレスなハンドオフ
Mergeは、この４つのデザインシステムの課題を以下で解決します。
- デザイナーは、スタイリングやインタラクティブなプロパティを備えた既製のコンポーネントを使うため、ゼロからデザインする必要がない。UI要素をドラッグ＆ドロップして、新しい製品をデザインすることができる。
- コードでの開発なし。エンジニアはパッケージをインストールし、まったく同じUI ライブラリを使ったプロトタイプをコピーする。UXPinは各コンポーネントのJSX をレンダリングするので、エンジニアはコピー＆ペーストでスタイリングやインタラクティビティを適用できる。
- 全員が同じ制約のもとで同じコンポーネントライブラリ（デザインチームとエンジニアリングチーム）を使用すれば、ドリフトは存在しない。
- 制約を組み込んだ同じコンポーネントを使うことで、デザインチーム間で一貫性を保つ。
- Mergeでは、デザイナーとエンジニアが同じ「信頼できる唯一の情報源」を使うので、シームレスなハンドオフが可能であり、デザイナーは UIを説明したり、プロトタイプを説明するドキュメントを延々と作成したりする必要がない。（すでに最終製品のような見た目と機能を備えているため）
UXPinは、デザインシステムの成熟度を示す４つの段階を、以下のようにわずか２つに短縮します。
- UXPinのデザインエディタを使ってライブラリをデザイン。
- デザインをコードコンポーネントに変換してレポジトリに追加し、Mergeを使って UXPinに同期させる。反復して拡張させていく。
デザインシステムに最適な２つのデザインとエンジニアリングツールを融合させることで、製品開発は次のレベルへ上がれます：
UXPin Merge + Storybook = 信頼できる唯一の情報源
ここまでお読みいただきありがとうございます。14日間の無料トライアルはこちらからご体験いただけます。詳細とリクエスト方法については、UXPin MergeでのStorybook連携ページをご覧ください。
