デザインハンドオフ ーUXPin Mergeで実現することー
プロトタイプが完成するとデザイナーは開発者にプロトタイプを渡します。このようなプロセスは、両方にとって大変な作業になってしまいます。デザインハンドオフを手助けするデザインツールは数多くありますが、プロトタイプを開発者へ渡す流れでそれぞれのツールにどのような違いがあるのでしょうか。
よく使われるデザインツールにおいて大きな違いのひとつは、デザイナーの仕事の最終成果物である製品のプロトタイプに対するアプローチ方法です。プロトタイプをベクタグラフィックスにレンダリングするものもあれば、コードにレンダリングするものもあります。
UXPin Mergeを使用すると、デザイナーは最終製品で使用される正しいコンポーネントを完全に機能するインタラクティブなプロトタイプで構築することができます。
GitHubリポジトリやStorybookからUXPinのエディタに完全にコード化されたコンポーネントを同期させることも可能です。Mergeを使い、実際どのように最終製品との完全な一貫性を実現できるか体験してみてください。
ベクターベースのデザインツール ハンドオフの限界
デザイナーから開発者に引き継がれるプロトタイプを例に考えてみましょう。それをベクターベースのデザインツールで作成したとします。つまり、すべてのコンポーネントがベクターベースでありながらも、インタラクションはコードを模倣しているだけということです。
コンポーネントの開発
まず、コンポーネントに着目してみましょう。その中には、開発者がゼロから作らなければならない新しいものもあり、既存のコンポーネントに手を加える場合もあります。
インタラクションの作成
ベクターベースのデザインツールでプロトタイプを作る場合、インタラクションがコード上に存在しないこともあり、開発者が作成するか、デザイナーと開発者のミーティングを重ねて何が必要かを正確に理解した上でデザイナーの期待に応えなければなりません。
デザインシステムの準備
デザイナーと開発者が、デザインシステムの信頼できる唯一の情報源を作るシステムです。再利用可能なマスターコンポーネントや、インタラクションがどのように機能すべきかのドキュメントを作成するのは
このデザインハンドオフは効率的か？
この方法はうまくいくが、少しイライラさせられ、時間がかかり、退屈かもしれない。誰もが壊れていることに気づき、それを直したいという衝動に駆られるわけではありません。彼らはそんなことをする必要はないのです。しかし、これは物事を動かすのに最適な方法なのでしょうか？
デザイナーと開発者の双方にとって、より良いものにするためにもっと何ができるのかという視点で見れば、議論できることはたくさんあると思います。この方法は、ベクターベースのドキュメントと開発者に渡されるものという、真実のソースがどこから来ているのかに基づく問題があります。
UXPin Mergeではデザインハンドオフはどうなるのか？
コードコンポーネントで作成したプロトタイプ
UXPin Mergeを作成する際に、開発者のハンドオフの際にもっと良いことができないか、このような視点を持ちました。
もはや、ベクターベースのコンポーネントや模倣されたコードインタラクションでデザインすることはありません。実際の設計は、生きたReactコンポーネントで行うのです。コンポーネントのコードをコピーして、アプリケーションに貼り付けることができます。
もし、デザイナーとデベロッパーが共同でドキュメントを作成し、コンポーネントのデザインとインタラクションのための唯一の真実のソースが実際のコンポーネントコードそのものであったとしたらどうだろう。つまり、デザイナーがプロトタイプを作成するとき、彼らはすでにコード化されたコンポーネントを、実際のコンポーネントが存在する本番さながらの環境で使用しているのです。
コンポーネントには、すべてのデザイントークン、インタラクション、編集可能なプロパティがすでに定義されています。最終的に、プロトタイプが出来上がると、コンポーネントのコード自体をハンドオフすることができます。
UXPin Mergeは開発者にどのように役立つのか？
デザイナーがどんなコンポーネントを使い、どんなインタラクションをデザインしたのか、想像したり打ち合わせたりする必要がなくなれば、どれだけ時間が短縮されるか想像してみてください。
開発者のハンドオフはシンプルで、プロトタイプを渡され、ソースコードにすでに存在するコンポーネント、コンポーネントのプロパティとそのコード化されたインタラクションを含むJSXコードをコピー＆ペーストするだけです。
これは、真実の源がコードそのもの、つまりソースコードであるために可能なのです。
デザイナーが編集できるコンポーネントプロパティとその編集方法は、開発者がソースコードで指定したものだけなので、予期せぬデザインが手渡されることはない。
デザイナーは、新しいインタラクションの追加、新しいプロパティの追加、スタイリングの変更などが必要な場合、開発者に説明し、ソースコードを変更することができます。推測や無駄なミーティングに時間を費やすことはもうありません。
デザイナーへの貢献度は？
開発者にとってはありがたい話ですが、デザイナーにとっては、限られたプロパティのコンポーネントを与えられてデザインすることは、創造性を制限することになると感じることが多いのではないでしょうか？私はそうは思いませんので、説明しましょう。
昔、友達と、あるいは今は一人で、レゴでクールな宇宙船やお城をデザインして遊んだことを想像してください。レゴは何歳になってもカッコイイのです。みんな同じようにあらかじめ積み木が与えられていて、その積み木がどうつながっていて、どう使うかはすでに決まっているのに、一人ひとりが他の人とはまったく違う、すばらしい宇宙船を作ることができるのです。
積み木を作ることと、その使い方を考えることに創造性を集中させるのではなく、純粋に後者に集中するのです。まずレゴブロックを作り、それがどのように機能するかを考え、それから宇宙船を作ると想像してみてください。
そんなことはあり得ないのに、それが現在のプロトタイプ設計の常識なのです。
デザイナーが最初にベクターコンポーネントを両方作らなければならないのは分かりますが、開発者はもっと大変なんです。一方、コードベースのコンポーネントであれば、双方が一度だけ作ればいいので、みんなハッピーなんです。
デザイナーは、開発者と調整会議をし続ける代わりに、他の超クールなタスクに時間を割くことができます。
Mergeを使用した開発者ハンドオフのプロトタイプ
UXPin Mergeでのハンドオフ
先ほどのプロトタイプでは、デザイナーが作成したMergeHeaderコンポーネントのJSXコードをReactアプリケーションにコピーするところから始め、開発者のハンドオフを正確に行う方法を説明します。
ソースコードそのものが真実なので、コピー＆ペーストするだけで、オブジェクトへのデータ追加やコンポーネントのインポートなど、いくつかの調整を行えば、ブラウザでアプリを表示する準備ができます。
あとは、プロトタイプの残りの部分と同じようにすれば、VOILÀ! デザイナーが作成したものと全く同じ、数分で完全に動作する本番用 React アプリが完成します。
では、結局のところ、どちらのデザインプロセスが優れていると思いますか？
UXPin Mergeでデザインハンドオフを改善する
UXPin Mergeは、ハンドオフプロセスだけでなく、多くのことを改善するのに役立ちます。統合プロセスを開始するためにもMerge ページに飛び、コードでデザインすることの利点をご覧いただけますと幸いです。ドキュメントで、Merge のデザインシステムコンポーネントをMergeについての詳細をご覧ください。
