Storybook連携を試してみましょう

Storybookではデザイナーと開発者がプロトタイプを構築する際に、コードコンポーネントを使用することで、サイロ化を解消しUIの一貫性を向上させることができます。（詳しくは「画期的なStorybookの魅力」に関するこちらのブログをご覧ください）

当社のMergeテクノロジーをベースにしたこの連携により、コードの力を利用して高度なプロトタイプを迅速に構築し、デザイナーも開発者も同じコンポーネントを使って製品を作ることが可能になりました。これにより、ハンドオフプロセスの複雑さを大幅に軽減することができます。

 Product Hunt にもStorybook 連携に関して載せておりますので、ぜひご覧ください！

製品チームが信頼できる唯一の情報源を必要とする理由

製品開発における信頼できる唯一の情報源 とは、製品を設計・製造するために必要なすべてのドキュメントや要素を保管する1つの場所のことです。理想では、信頼できる唯一の情報源 は簡単に共有、常に最新の状態、プロセスに関わるすべての人が使用できることです。

 デザインシステムは、製品チーム間で情報がバラバラになってしまうという問題を解決するはずでした。デザインシステムはUIやドキュメントをシステム化するための素晴らしい第一歩ではありますが、それだけではデザインと開発の作業において完璧には解決できないこともあります。

そこで、Mergeという革新的なテクノロジーが誕生しました。製品チームは、GitリポジトリやStorybookなどの開発ツールを活用して、DesignOpsプロセスを改善し、デザインとコードの同等性を維持することができます。その結果、デザイナーも開発者も同じUI要素、ドキュメント、コードを1つのソースから使用することができます。

開発ライブラリからコードベースの完全なインタラクティブコンポーネントを取り出し、キャンバスにドラッグ＆ドロップするだけで、デザインエディタで使用できることを想像してみてください。これが非常にエキサイティングな理由です:

もう 「あのコンポーネントはどこだっけ？」と悩むことはありません。

パズルのピースが散らばっているのと同じように、製品開発に必要なピースを探して作り上げることは、かなりの時間がかかります。コンポーネントやドキュメントを常に最新の状態に保つのは本当に大変なことです。しかし、すべての情報を１つに保管する場所があれば、正しいバージョンのコンポーネントやそのコードを探す必要はありません。

開発者用のライブラリからデザインエディタにUI要素を持ってくると、1つの場所でメンテナンスするだけでよく、ライブラリも自動的に同期されます。

デザイナーと開発者が共通のテクノロジーを使用

デザイナーが作成・開発者が作成したものの間で起こる問題の原因はそれぞれが異なるテクノロジーを使って仕事をしているということです。デザインツールは一般的にベクターやピクセルを使っているのに対し、アプリやウェブサイトは特定のプログラミング言語やフレームワークを使っています。

ベクトルやピクセルを使った手法は非常に限られたもので、最終製品を単純にイメージにしたものに過ぎません。例えば、プロトタイプに実際に動いたりなどの高度なインタラクションを追加したい場合、ベクターやピクセルでは変数や条件付きロジック、あるいは単純な入力フィールドを扱うことができないため、必ずしもそれが作れるとは限りません。しかし、開発者がUIコンポーネントにコードを使用すると、これらの障害はなくなります。

もし、デザイナーがコードに反映されるようなコードパワーのあるテクノロジーを使ってプロトタイプを作ることができれば、デザイナーと開発者は共通の言語でコミュニケーション、作業ができるのです。つまり、2つの異なる環境でUI要素を作成するのではなく、まったく同じ環境を使用することで、製品制作をスムーズにさせます。

10倍の成果

製品をデザインする際には、ユーザーがクリックしたときに何が起きてどのように動くのかを開発者に説明する必要があります。また、すべてのインタラクションを使用して製品の動きをより上手く説明するために、高再現性なプロトタイプを作成することもできます。通常だと、高度なプロトタイプの作成には多くの時間がかかり、詳細を正確に把握するためには、インタラクションやプロトタイプの機能性についてコメントで長い会話をする必要があります。

この流れはデザインオペレーションの観点から言うと、決して効率的なワークフローとは言えません。しかし、コード化されたUIコンポーネントをデザインエディターで使用することにした場合、デザインプロセス全体が決定的にスピードアップします。

完全にインタラクティブで、すべての制作基準に沿った要素を使って作業すると、従来の方法でプロトタイプを作るのに比べて、10倍以上のデザインにおいての成果が得られます。  節約できた時間をユーザーテストなど他の重要なことに回して、費やすことができます。

ユーザーテストの特典：最終製品と同じように動作するプロトタイプ

すべてのUIパーツが完全にインタラクティブでない場合、どうやってプロトタイプをテストする方法としてユーザーテストがあります。しかし、ユーザーテストでは、ユーザーが自身でクリックし、プロジェクトを進めることができなければ十分な信頼性が得られません。アコーディオンをクリックしたり、メニューにマウスを置いたりすると何が起こるかを説明しても、それを見せるのと同じ品質のフィードバックは得られません。

コードで作られたプロトタイプが最終製品とまったく同じように動作するようになれば、ユーザビリティテストで完全に没入感のある体験を提供して、リサーチチームをサポートすることができます。

コードでデザインする  Storybookの連携を試す

Storybook は、開発者がUIコンポーネントを構築し、保存するための唯一の場所です。また、要素をテストしたり、明確なドキュメントを作成するのにも最適なツールです。Storybookは、React、Angular、Vueなどの人気の高いフレームワークを含む多くのフレームワークをサポートしています。

UXPinで Storybook連携 

Storybook は、Merge 技術を使用してコード化されたコンポーネントをデザインツール UXPin と同期させる 2 つの連携のうちの 1 つです（Git repo が最初の連携です）。Storybookとの連携は約1分で完了し、コード化されたコンポーネントを使ってすぐにデザインすることができます。

プライベートまたはパブリック？

あなたのStorybookライブラリは、プライベート（あなたのサーバーにホストされ、選ばれたユーザーだけがアクセスできる）と、URLを知っている人が自由にアクセスできるパブリックのいずれかにすることができます。私たちの統合は両方のタイプをサポートしているので、どちらを使用するかは問題ではありません。

パブリックのライブラリでは、ストーリーブックのURLをコピー＆ペーストするだけで簡単に利用できます。プライベートライブラリでは、開発者は2つの簡単なコマンドを実行するだけです。プライベートライブラリをお試しになりたい場合は、ガイドツアーをご利用ください。

既にお持ちで、他社のパブリックライブラリを使用されたい場合は、オープンソースのStorybookのサンプルをお楽しみください。

コードで自由にデザイン

同期されたコンポーネントはコード化されているので、デザイナーは開発者の手を借りずに、UXPinエディタ内でプロパティ、入力、スタイルを自由に変更することができます。また、コードに埋め込まれた制約は、スタイルにミスマッチがないようにガイドしてくれます。

ノンデザイナーに権限を与え、より良いDesignOpsを実現する

コードを使ってデザインすることで、DesignOpsプロセスを再定義することができます。PayPalは、製品開発のデザインフェーズを変革することで、デザイナー以外の役割を持つ人々がUXPinのコード・コンポーネントを使ってアイデアを視覚化できるようにした素晴らしい例です。PayPalのErica様と彼女のチームはMergeとGit の連携を使用していますが、Storybookを活用しても同様の結果を得ることができます。

デザイナー以外の人は、コンポーネントをキャンバスにドラッグ＆ドロップして、必要に応じてコントロールを操作するだけなので簡単です。その後、デザインドラフトをもとにUIの専門家がプロジェクトを仕上げ、ユーザビリティに焦点を当てることができます。

コードの力を味わう

登録して、Storybookから直接コンポーネントが提供されている内蔵のマテリアルUIライブラリを試してみたり、ご自身で新しいライブラリを同期させたりすることができます。コードの力を実感し、信頼できる唯一の情報源を使用することで、製品チーム全体がどのようなメリットを得られるかをご覧ください。