キャリー・カズンズ
デザインのハンドオフプロセスに関わったことがある方なら、イメージをより良いものに仕上げる難しさをご存知でしょう。詳細な注釈やドキュメントが添付された完璧なプロトタイプを作成しても、デザイナーとエンジニアの間に大きな隔たりが生じることがあります。
Figma、Adobe XD、Sketch などの人気の画像ベースのデザイン ツールでは、忠実度と機能性に関して課題があります。
入力検証、ショッピング カートの更新、日付の選択、サインアップ フロー、ページ区切りなどのシンプルな製品機能は、最終的な製品とは異なり、画像ベースのツールでは機能しません。そのため、調査やユーザビリティ テスト用のプロトタイプの価値が制限され、設計者と開発者の間に不協和が生じます。
デザイナーはフラットなモデルを作成し、それをエンジニアに渡して複雑な製品を開発させるべきだという考え方を変える時が来ました。誰も責められません。古い設計習慣を打破するのは難しいものです。しかし、もっと良い方法があります。
画像ベースのデザインツールは開発者に優しくない
従来の画像ベースの設計ツールをまだ使用している場合、製品開発に支障が生じます。
つまり、設計チームと開発チームは同じ製品設計を2度作成していることになります。これは全く非効率的で、一貫性のないビジネス手法です。
チームはコードベースの製品を設計しますが、ビジュアルフレームワークはベクターベースやピクセルベースのプロトタイプを使って作成します。これは意味がありません。
製品をスケールさせる上での最大の課題の一つは、画像ベースのツールでデザインされたものをコーディングしながら、信頼できる唯一の情報源を維持することです。コードとデザインシステムのベクターコンポーネントは異なる言語で記述されているため、直接同期させる方法はありません。
ほとんどの組織では、さまざまな製品チームや設計チームが、同じだが統一されていないコンポーネントのさまざまなバリエーションに取り組んでいます。これは、設計の引き継ぎに関してはまさに悪夢です。
一貫性はどうでしょうか？多くの組織にとって、同じコンポーネントの類似しているものの同一ではないバリエーションが本番環境に蓄積されていくことは、常に課題となっています。メンテナンスとリファクタリングのコストを考えてみてください。
製品のドリフト
デザイナーと開発者がしばしば誤解し合うのは、両者が異なる制約の中で作業しているためです。Nathan Gitterが「なぜアプリはSketchでより良く見えるのか」で示しているように、デザインと最終製品の間には乖離があります。ベクターベースのデザインツールの限界により、デザイナーは最終製品のピクセルパーフェクトな表現を作成できますが、実際の製品は現実世界ではそのような外観になりません。なぜなら、デザイナーはコードやブラウザの制約を正確に考慮できないからです。
デザイナーはコードとブラウザの制約を模倣する方法を見つけようとしており、エンジニアはそれらを克服しようとしています。
これは調和のとれた陰陽効果ではなく、設計チームと開発チームの間に緊張と本質的な断絶を生み出します。
デザインの進化
画像ベースの設計ツールの問題の 1 つは、今日の製品設計チームの目標を満たすように進化していないことです。
1970年代の登場以来、画像ベースのデザインツールは大きく進化してきましたが、デザインと開発を一つの統合システムに統合する能力が欠けています。画像ベースのデザインツールが当初どのように使われていたかを考えてみてください。印刷されるフラットで静的なデザインでした。
インタラクションは、現代のデザインプロセスにおいて不可欠な要素です。設計と開発の過程でプロジェクトのコンセプトが具体化していく過程を真に伝えるには、この要素が不可欠です。
設計プロセスへの影響
イメージベースのデザインでは、各チームが異なる課題を克服するために取り組んでいるため、UX、製品、エンジニアリング間のサイロが強調されます。
その結果、ユーザー エクスペリエンスと収益機会に重点を置くのではなく、設計と開発の不一致を解決するために、市場投入までの時間が長くなり、スプリントが増え、反復作業が増えることになります。
デザイン ツールがコードベースであっても、デザイナーが使い慣れたエディター ユーザー インターフェイスを使用できるとしたら、もっと合理的ではないでしょうか。
コードベースのデザイン革命
設計および開発ツールの新しい波が近づいています。
コードベースの設計ツールは、チームの作業を迅速化し、製品開発チームと企業が競合他社よりも機敏に拡張できるようにするため、プロトタイピングの未来です。
メリットは3つあります。
- より優れた、よりインタラクティブなプロトタイピング機能
- より一貫性があり、エラーのない製品設計
- より速い構築と市場投入までの時間の短縮
仕組みは以下のとおりです。
デザイナーはベクター要素の代わりに、プロトタイピングエディタで最終製品と同じように動作するコードベースのコンポーネントを使用します。コードベースのデザインツールでは、チーム全体が全く同じコンポーネントを使用するため、デザインとコード間の変換は不要です。
デザインと機能は、最初から最後まで創造的なプロセスの一部です。
これらのコードベースのツールは、状態、コードベースのインタラクション、条件付き書式、変数、データのキャプチャと検証などにより、プロトタイプの忠実度を高めます。
さらに、チームの作業効率が向上し、制作時間が節約され、修正をあまり行わずにプロジェクトを目標通りに完了できるようになります。
UXPinは、デザインツール革命をリードする企業の一つです。コードベースのアプローチはDesignOpsワークフローに適合しており、優れたプロトタイピング、エラーの削減、市場投入までの時間の短縮を実現します。
開発とデザインの融合
UXPinの登場です。独自のMergeテクノロジーを搭載したコードベースのデザインツールで、デザインと開発のギャップを埋めます。
UXPin Merge を使用すると、すべてのチームメンバーがリポジトリに保存されているまったく同じデザイン システムで作業するため、真実の単一ソースのジレンマが解決されます。
UXPinのコンポーネントは、ベクターグラフィックではなく、HTML、CSS、JavaScriptで作成されています。その結果、JavaScriptの力によって強化されたインタラクティブ性を備えた、高忠実度のプロトタイプが実現します。
UXPin Mergeプロトタイプの特徴は何でしょうか？インタラクティブなUIブロックを使用すれば、同じものを何度も再設計する必要がなくなります。これらのブロックはコード化されたコンポーネントなので、開発者はデザインからコードをそのままコピーするだけで済みます。このようなコンポーネントを使用することで、画像ベースのツールでは実現できないレベルのインタラクティブ性が向上するだけでなく、プロトタイピングプロセスも高速化されます。つまり、関係者全員がより大きな課題に集中できる時間が増えるということです。
デザイナーにとって、インターフェースは機能面で馴染み深いため、ユーザビリティは問題になりません。デザイナーは、コンポーネントと設定（プロパティ）のコレクションを使用することで、デザインチームと開発チームが同じ制約の下で作業できるようにし、よりスムーズで効率的なデザインプロセスを実現します。
設計から開発へのツール切り替えのハードルがなくなり、チーム全員が最初から関わり、ビジュアルデザインが形作られていく様子を見ることができます。これだけで、よりリアルでインタラクティブなプロトタイプを作成し、完成品に近い外観と感触を実現することで、製品開発を統合することができます。
真実の単一ソース
UXPin Merge を使用すると、エディターをリポジトリ ( GitまたはStorybook経由) のデザイン システムと同期できるため、デザイナー、プロダクト マネージャーなどが開発者と同じコンポーネントを操作できるようになります。
デザイナーは、コンポーネントをコードで編集するか、プロパティパネルから編集するかを選択できます。これにより、デザイナーはビジュアルデザインを作成しながら、インタラクティブなコンポーネントを操作できる新たな次元が開かれます。
チームは単一の真実の情報源を使って作業するだけでなく、同じ言語を話します。
このツールにより、デザイナーは描画して他の人に引き渡してコードを書かせるのではなく、実際にデザイン プロセスを促進できるようになるため、コラボレーションはプロセスのより統合された部分になります。
その結果、全員が同じコンポーネントを使用するため、デザインの受け渡しがスムーズなワークフローが実現しました。編集や変更が発生すると、UXPinがチームメンバーに通知し、デザインシステムライブラリを自動的に更新します。これにより、組織全体がすべてのコンポーネントの一貫性を完全に管理できるようになり、デザインオペレーションの負担が大幅に軽減されます。
このタイプの設計と開発により、何度も開始したり停止したりすることなく、より早期に、より洞察に富んだユーザビリティ テストと製品の進化が可能になります。
最も優れている点は、デザイナーがコードを知らなくても使用できることと、小規模チームのワークフローを迅速化できることです。
PayPalがUXPin Mergeでデザインプロセスをスケールアップした方法
Erica Rider が PayPal に開発者ツールおよびプラットフォーム エクスペリエンスの UX マネージャーとして入社したとき、彼女の主な仕事は社内製品の統一性を高めることでした。
課題：PayPalは、ユーザビリティとデザインの一貫性に関して様々な問題を抱えていました。社内製品はどれも同じに見えませんでした。さらに、チームは1,000人以上の開発者と60以上の製品を抱え、デザイナーは3人（Ericaを含む）しかいませんでした。そのため、部門全体にわたる継続的な製品開発プロセスを持続可能な方法でサポートする必要がありました。
Merge と UXPin を発見したことで、デザインと開発のギャップを埋める方法を理解することができました – PayPal で開発者ツールとプラットフォームの経験を積んだ UX 担当シニア マネージャー、Erica Rider 氏。
Mergeにより、PayPalはGitリポジトリ（Microsoft Fluent）に保存されているデザインシステムをUXPinのデザインツールと同期させることができました。コンポーネントは本番環境とUXPinで同じようにレンダリングされ、高いインタラクティブ性とすべてのデザイン基準を維持しました。すぐに使える要素を使ったプロトタイピングの高速化と容易さにより、製品チームは独自にプロトタイプを構築し、デザインプロセスを拡張することができました。
PayPal のマネージャー (UXPin を使用する前は UI/UX の経験がなかった) は、今ではわずか数分でビジネス ニーズを表現するために完全に機能するプロトタイプ(ローファイ モックアップではない) を構築しています。
Erica 氏は、UXPin はマネージャー、デザイナー、開発者間のスムーズなコラボレーションを促進し、PayPal の製品ドリフトを解消し、サイロを解体し、引き継ぎプロセスのボトルネックを解消するのに役立っていると述べています。
以前は、プロジェクトはデザインだけで2～3ヶ月かかっていました。今では、製品の設計と提供を同じ期間で行うことができます。Mergeの最も大きな効果の一つは、おそらく市場投入までの時間です。 – Erica Rider、UX担当シニアマネージャー（PayPalで開発ツールとプラットフォームを担当）
UXPinとは誰ですか？
UXPin はポーランドで設立されたデザインツール会社であり、 「デザインとエンジニアリングを融合し、より優れた、より迅速な製品開発の世界にすることで、最高のユーザーエクスペリエンスを実現する」 ことを使命としています。
同社は今年設立11周年を迎え、ポーランド、日本、米国にオフィスを構えています。PayPal、ジョンソン・エンド・ジョンソン、T. Rowe Price、T-Mobileなど、UXPinのコードベースエディターを使用している大手国際ブランドは数多くあります。
UXPin は過去 3 年間に、デザインと開発のギャップを埋める革新的なテクノロジーである Merge など、いくつかの重要な製品アップデートをリリースし、その過程で多くの DesignOps の課題を解決してきました。
「今後、デザインチームと開発チームはより緊密に連携していくと考えています。UXPinは、私たちの使命に基づき、製品開発プロセスにおけるコードベースのデザインの普及に努めています。コードを活用したデザインを加速させたいチームを支援するため、Mergeテクノロジーに注力しています。」 – UXPin CEO 幸田 悠雅
