デザイナーとデベロッパーの連携をダメにする5つの間違い
これまで、デザイナーとデベロッパーの連携をしやすくする方法について見てきました。では、その連携をダメにする障壁やワークフローは何でしょうか？
筆者たちは、デザインチームやプロダクトマネージャーがソフトウェアエンジニアと仕事をする際に陥りがちな間違いや、どうすればもっといい連携ができるかを調べ、摩擦や障害を減らすことで、よりスムーズな製品開発プロセスが実現し、デザインの価値も上がることがわかりました。
UXPin Mergeで連携を強化し、デザインと開発の間のギャップを埋めませんか。この技術によって、コンポーネントライブラリの要素のUXPinへの取込や、機能的なプロトタイプの作成、デザイン通りの開発が実現します。詳しくは Mergeのページをぜひご覧ください。
間違い１： 画像ベースのプロトタイプの使用
初期段階のスタートアップ企業であれ、企業のソフトウェア開発チームであれ、デザインハンドオフはデザイナーとエンジニアの間でよく摩擦が起こりますが、この緊張の最大の原因の1つは、「プロトタイプの忠実度」にあります。
画像ベースのデザインツールだと、忠実度や機能性に欠けたお粗末なプロトタイプができ、それによってエンジニアやステークホルダー、ユーザビリティ担当者は解釈や理解がし辛くなります。
そこでデザインチームには2つの解決策があります：
- フロントエンドデザイナーやUXエンジニアと連携し、もっといいプロトタイプを構築する。
- コードベースのデザインツールに変更する
後者は、よりスムーズなデザインのハンドオフのためにエンジニアリングチームへの依存の解消やプロトタイプの能力の大幅な向上、テストの改善、デザイナーとデベロッパーの連携の促進を実現することから、こちらの方が解決策です。
コードベースのデザインツールを使うメリット
UXPinのコードベースのデザインツールで、デザイナーは最終的な製品体験を正確に再現するプロトタイプを作成することができます。
UXPinの完全にインタラクティブなプロトタイプは、コードに匹敵する体験を提供するため、エンジニアやステークホルダーは、何かをすることを「想像」する必要がありません。
以下に、プロトタイプを強化するUXPinの機能を４つご紹介します：
- ステート：1つの要素やコンポーネントに複数のステートを適用し、それぞれに異なるプロパティ、インタラクション、アニメーションを設定できる。
- インタラクション：高度なアニメーションと条件付きフォーマットを使って複雑なインタラクションを作成し、ダイナミックなユーザー体験を実現。
- 変数：ユーザーの入力を取得・保存し、その情報を使ってアクションを起こしたり、製品フローを個別化する。
- エクスプレッション：Javascriptのような機能で、フォームの作成、パスワードの検証、ショッピングカートの更新などを行うことができる。
無料トライアルにサインアップして、このような機能やその他のUXPinの高度な機能をぜひご確認ください。
間違い２：デザイン上の意思決定が明確でない
デザイナーがやりがちな最大の間違いのひとつは、デザイン決定の背景にある「なぜ」を明確にしないことです。あなたが解決しようとしているユーザーの問題を知らずに、エンジニアはどうやって理解や共感ができるのでしょうか？
デザイン上の決定を明確にする鍵は、積極的な行動です。デザインプロセスを通じてデベロッパーを呼び込み関わらせて、不意なデザインハンドオフを防ぐのです。
デザイナーでありビジネスリーダーでもあるアントニア・ホルヴァス氏は、連携の改善や、エンジニアをデザインの決定に参加させるための素晴らしいアドバイスを以下のようにしています：
- デザインと開発の組合せ：デザイナーは、デザインハンドオフ後に、プロセスを理解してエンジニアリングの課題を観察すべく、エンジニアが機能を構築するのを見ます。理想としては、このプロセスは、両方のチームメンバーが同じ画面の前でライブで質問したり回答したりしながら、直接行うのが最も効果的です。
- 一緒にアイデアを出す：アイデア出しのセッションにエンジニアを参加させることで、デザイン決定の裏にある思考プロセスを理解し、技術的なノウハウを活かしてアイデアを改善することができます。
- デザイン評論：従来はデザインチームの”儀式”でしたが、この一風変わった評論にエンジニアを参加させることで、新鮮な視点からの新しいアイデアを得ることができ、また、意思決定の背景にあるデザイン思考のプロセスを理解することで、エンジニアにもメリットがあります。
- デザイナー／エンジニアの振返り：アジャイルソフトウェア開発のプラクティスで、各イテレーションの成果を振り返り、改善点を議論するものです。デザイナーとエンジニアは、毎回のリリース終了時に振り返りを実施し、デザインハンドオフのペインポイントと解決策を特定するといいでしょう。
間違い３：UXについてエンジニアを教育していない
一般に信じられていることとは異なり、UXチームは製品のUX（ユーザーエクスペリエンス）に単独で責任を負うのではなく、組織全体で責任を負うのですが、UXデザイナーによる効果的なデザイン提唱がなければ、誰もUXについて進んで学ぼうとはしないでしょう。 PayPalのUX Lead EPXであるエリカ・ライダー氏は２０２２年のデザインバリュー会議で、「企業には以下のような多大な”コントロールと管理責任の不均衡”がある 。」と指摘しました。
- UXデザイナーは、ユーザーに提供するUXに関するコントロールは皆無なのに、管理責任を１００％負う。
- エンジニアは、ユーザーに提供するUXに対する管理責任は皆無なのに、１００％のコントロールを担う。
UXチームの役割は、エンジニアにUXを教育し、両部門で責任を分担することです。
そこでエリカは、「UXチームはエンジニアと協力してPayPalの優れたユーザー体験を提供するが、最終的な製品についてはエンジニアが責任を負う」ことを保証するためのシステムを開発しました。
最大のハードルのひとつは、意識改革です。UX以外の誰もが、デザイナーの役割は見た目とUIのデザインだと考えていますからね。
エリカの教育方法は、エンジニアのUXに対する考え方を、「美的感覚に優れたUI（ユーザーインターフェース）」から、「エンジニアが絶対的にコントロールできるボトルネックやロードブロックを引き起こす問題」へとシフトさせることでした。その例として、以下のようなものがあります：
- レイテンシー：ボタンをクリックしても読み込みに時間がかかるようでは、お粗末なUXである。
- 可用性：URLが読み込まれないのは、お粗末なUXである。
- セキュリティ：もし誰かが自分のアカウントをハッキングしたら、それは最悪なUXである！
- 「人間が読める」ものではない、あるいはユーザーが解決する術のないエラーメッセージ：【エラーコード1578-B1273 – 失敗！】のように、その意味も解決方法も告げずにメッセージをユーザーに見せるのもまた、お粗末UXである。
組織全体で、まずはエンジニアからUXの考え方を身につけていくことで、ユーザーへの共感を高めつつ、責任を分担することができます。
間違い４：ユーザー調査の結果を共有しない
UXツールの記事で、テイラー・パーマー氏がエンジニアへのインタビューから得た 「ユーザー調査でより良いエクスペリエンスを生み出す方法 」についてのインサイトが紹介されています。
エンジニアがユーザー調査を重視するのは、デザイン上の意思決定を理解し、あるデベロッパーが言うように「正しいものを確実に作っているようにするため」です。
デベロッパーは、デザインチームのユーザー調査のアーカイブにアクセスする必要はありませんし、ユーザーインタビューに同席する時間もありません。彼らにとっては、要約やメモ、録音されたインタビューなどの方がいいです。
ユーザー調査をエンジニアリングチームと共有する方法
テイラー・パーマー氏は、UXリサーチをエンジニアと共有するためのアイデアを以下のようにまとめました：
- 研究プロジェクトやインサイトを共有するためのミーティング
- エンジニアが “なぜ “を理解できるように、デザインファイルと研究概要をリンクさせる
- インタビューやユーザビリティスタディのためのオープンなポリシー作成
- ワイヤーフレーム、モックアップ、プロトタイプ（低再現性と高再現性）を含むどのUXアーティファクトにも対するフィードバックの取得
- 社内調査のレポジトリの作成と共有 – 必要に応じてエンジニアがリサーチを深く掘り下げられるよう、サマリー以上の情報を提供
- デザインミーティングやアイデア出しのメモの共有
- 定期的なユーザー体験のニュースレターの作成
間違い５：信頼できる唯一の情報源（Single source of truth）がない
製品開発チームにとって最も大きな課題の1つは、デザイナーとエンジニアの間のバラバラな”連携”を解決することです。
デザイナーとエンジニアは、完全に統合されたデザインシステムからの「信頼できる唯一の情報源（Single source of truth）」なしで、異なる言語を話します。するとどうなるでしょう？
弱い連携、デザインドリフト、摩擦などが起きUXや製品品質に悪影響を及ぼしてしまいます。
信頼できる唯一の情報源（Single source of truth）を作るには
デザインシステムを構築しても、信頼できる唯一の情報源（Single source of truth）が1つになるとは限りません。従来のデザインシステム構築の方法では、以下のようにデザイナーとエンジニアがそれぞれ別の【真実】を使うことになります。
- デザイナーはUIキットや画像ベースのデザインシステムを使用
- エンジニアはコードのコンポーネントライブラリを使用
デザインシステムの成熟度を示す4つのステージのうち、このステージは3番目であり、4番目に行くには、デザイナーとエンジニアが同じコンポーネントライブラリを使うような、デザインと開発のギャップを埋めるツールが必要です。
Iress社のデザインシステムプロダクトオーナー兼プロダクトデザイン地域責任者のニック・エリオット氏は、以下のような第4段階を「完全統合」と呼んでいます：
- コード（又はノーコード）でデザイン: デザイナーはレポジトリにあるコードコンポーネントを使って、ドラッグ＆ドロップでUIを構築。– ゼロからのデザインは不要
- デザインドリフトがない：UXチーム、プロダクトデザイナー、エンジニアが全く同じコンポーネントを使うため、デザインドリフトがなくなり、UX/フロントエンドの負債は少なくなる。
- 一貫したデザイン：コンポーネントにはデザインシステムで確定されたプロパティとインタラクティビティが含まれているので、デザイナーは色、タイポグラフィー、ステートなどをの検討は不要。
- シームレスな引き継ぎ（又は引き継ぎなし）：エンジニアはすでにプロトタイプに使うすべてのコンポーネントの正確なコピーを持っており、フロントエンドの開発では、リポジトリからコピー＆ペーストするだけでよく、それによってコードを書く必要性が軽減される。
そこでIressは、UXPin Mergeを使ってデザインと開発を同期させました。MergeはIressのコンポーネントライブラリをレポジトリからUXPinに取り込み、デザイナーはコードを見ることも書くこともなく、最終製品のような外観と感触のコードベースのプロトタイプを作成できるのです！
この共有された「信頼できる唯一の情報源（Single source of truth）」は、デザイナーとエンジニアが同じ言語を話し、同じ技術的制約の中で作業するということであり、その結果、摩擦の減少やワークフローの効率化が実現するのです。詳細とアクセスのリクエスト方法については、Mergeのページをぜひご覧ください。
UXPin Mergeがデザインと開発を同期させてより良い連携を実現する方法
結論を聞いたことはあると思いますが、UXPin Mergeはどのように機能するのでしょうか？Mergeを使うと、組織はレポジトリからUXPinのデザインエディタにデザインシステムを同期させることができます。
組織は、React、Angular、Vue、Ember、HTMLなど、他のフロントエンド技術用のGit 統合またはStorybookを使って、ReactデザインシステムをUXPinに直接接続することができます。
コンポーネントライブラリはUXPinの左サイドバーに表示され、デザイナーがキャンバス上に要素をドラッグしてプロトタイプを始められるようになっており、各UIコンポーネントには、色、サイズ、タイポグラフィ、ステートなど、デザインシステムで確定されたプロパティが含まれています。
デザイナーは、プロパティパネルでドロップダウンとセレクタを使って、これを切り替えることができ、変更はJSXとしてレンダリングされるので、エンジニアはコピー＆ペーストで簡単に開発プロセスを始められます。
製品開発チーム全体が同じ言語で会話できるように、UXPin Merge のコードベースのデザイン ソリューションを使いませんか。詳細およびこの革新的なテクノロジーへのアクセス要求方法については、Mergeのページをぜひご覧ください。
