デザイナーとデベロッパーのためのより良いエクスペリエンスを創造するには？
デザインハンドオフは、どんなプロジェクトにも不可欠な部分です。どちらかのチームが何かを見逃すと、製品の欠陥や遅れにつながる可能性があることから、多くのデザイナーやエンジニアにとってデザインの引き継ぎは、ストレスのたまる作業です。
プロトタイプやアセット、ドキュメントの制作は主にUXチームが担当しますが、デザインハンドオフプロセスは、デザインの初期段階から共同作業で行われます。
デザインハンドオフを成功させるには、3つの段階があります。
- ハンドオフ前（デザイン中）
- ハンドオフ時
- ハンドオフ後
UXPinは、デザインと開発の間のギャップを埋めるコラボレーションデザインツールです。デザインチームは、UXPinの自動化されたデザインスペック、CSS、スタイルガイドによりドキュメント作成の時間の短縮を実現でき、スペックモード機能でハンドオフの効率化や、Mergeテクノロジーでコードコンポーネントのパワーをデザインに活用することもできます。
ハンドオフ前（デザイン中）
デザインハンドオフは、デジタル製品のデザイン・開発における1つの出来事ではなく、むしろ、デザインの初期段階から始まり、デザイナーが最終製品を完成させた後に終了するプロセスです。
デザイナーとエンジニアは、デザインハンドオフプロセスを合理化し、コストのかかるエラーを軽減するために、連携・連絡が必須です。
発見
競争優位を築くにはイノベーションが不可欠ですが、デザイナーは会社のリソースと技術的制約の中で仕事をしなければならないことから、デザイナーとエンジニアは、デザインアイデアに関する技術的な制約について初期の段階で話し合うべきです。
開発チームの代表者は、ユーザー調査に参加して、デザイン決定の背景にある「なぜ」を学ぶ必要があり、そうすることで、デベロッパーはユーザーのニーズとUXデザイナーが解決しようとしている問題をより理解できるようになります。
企画
デベロッパーをデザインスプリントに参加させることも、技術とデザインを一致させる方法の一つです。デベロッパーは、スプリント中にデザイナーと協力して、技術的な制約に沿ったユーザーの問題に対する解決策を見つけることができます。
同時に、デベロッパーは新しい機能を作るのに必要なツールやパッケージを調べるために、メモ取りを始めることができます。
プロトタイプ
デベロッパーはプロトタイプの段階で、異なるブラウザ、デバイス、ビューポートでのデザインの見え方や機能など、貴重なフィードバックやインサイトを提供できます。
プロトタイプの段階でデベロッパーにデザインや機能について終了してもらうことで、最終的なデザインハンドオフにかかる時間とストレスを大幅に軽減できます。UXチームのビジョンと技術的な現実が一致しないために、「振り出しに戻る」ことほどつらいことはありませんからね。
また、開発チームの担当者が後期のユーザビリティテストに参加し、ユーザーが最終製品をどのように操作しているかを可視化するのも有効です。
ユーザーインターフェースデザイン
デジタル製品にとって、よく文書化されたデザインシステムは欠かせない要素です。コンポーネントベースのデザインシステムを構築することで、エンジニアは再利用可能な「ウィジェット」をコード化し、最終製品を効率的に開発できます。
デザイナーとデベロッパーが協力することで、デザインシステムの一貫性が確保され、サイズの規約を効果的にコードに反映させることができます。
また、デベロッパーはアセットのフォーマットやサイズに関する技術的な仕様を提供できるため、UXチームは製品やウェブの制約に合わせてコンテンツを最適化することができます。
ハンドオフ時
デザインプロセスにおいて、デザインチームと開発チームが効率よく連絡・連携すれば、ハンドオフはダブルチェックと整理調整を行うスムーズなプロセスとなるはずです。
デザイナーがデザインハンドオフをどのように見せるかは、ドキュメントやファイル、アセットそのものと同じくらい重要です
まずUXチームは、混乱を避けるために、使用されていないレイヤーとガイドの削除が必要です。また、コンポーネントを正しくグループ化し、ラベル付けしていることの再確認が必要です。
BEM表記などの一貫した命名規則を使うことで、デベロッパーはファイル、アセット、コンポーネント、エレメントをぱっと見つけることができるようになります。そしてエンジニアは、効率的な開発ワークフローに沿った推奨ファイル構造についてアドバイスをくれる場合もあります。
デベロッパーがモックアップやインタラクティブなプロトタイプを理解するには、コンテキストの提供や、デザインツールの能力を超えている可能性のある機能の説明といった、はっきりと明示されたアノテーションが不可欠です。
最後に、デザイナーは、デベロッパーが包括的なデザインハンドオフを受けられるように、ドキュメントを一通りチェックする必要があります。
ハンドオフ後
UXチームは、インタラクティブなプロトタイプやモックアップに対して最終製品をテストする、実装の品質保証（QA）において重要な役割を担っています。
最終製品が完成したら、デザイナーとエンジニアは、今後の製品や機能のためのデザインハンドオフプロセスを改善するための話し合いが必要になります。
デザインハンドオフチェックリスト47項目
以下の47項目のチェックリストは、次回のデザインハンドオフのためのガイドとして作成されたものです。
ハンドオフ前（デザイン中）
発見：
- 可能であれば、デベロッパーをユーザーインタビューに呼ぶ
- ユーザーインタビューから得たインサイトを箇条書きにしてデベロッパーにまわす
- 30分から1時間のステークホルダーインタビューを少なくとも1人のデベロッパーと実施する。キム・グッドウィン氏の素晴らしい質問を使う
- デベロッパーとともに無駄のないペルソナを作成し、さっとレビューする
- デザインブリーフの技術的制約について、デベロッパーの意見を聞いて調整する
企画：
- デベロッパー（または最低でも開発リーダー）がキックオフに必ず参加するようにする
- デベロッパーとともにユーザーストーリーマッピングを行い、エピックとスプリントを計画する
- プランニングポーカーなどの手法で、デベロッパーとともにユーザーストーリーの構築時間を見積もる
- 開発プロセスの1、２個先のデザインスプリントまで計画する
- デザインに使うフレームワーク（ブートストラップ、ファンデーション、カスタムなど）を確認し、それに応じてグリッドやエレメントを調整する
- ブラウザの対応状況をデベロッパーに確認する
- 各スタンドアップミーティングの後、デベロッパーとバックログをすぐ見直す
プロトタイプ：
- ユーザーフローとLo−Fiプロトタイプをひと通りチェックして、デベロッパーから実現可能性に関するフィードバックを得る
- コンテンツの正確な「ブラケット」のために、極端なビューポート（最小と最大）のデザインを始める。想定より少し小さい、または大きい画面サイズに対して、デザインがどのように反応するかを検討する。
- 最初の2回のイテレーションで、プロトタイプにLorem Ipsumではないラフなコンテンツを組み入れる。
- 最低1回のユーザーテストに参加するようデベロッパーを呼ぶ
- プロトタイプがすべての相互作用状態、エラー状態、およびステート間の遷移を説明している
- プロトタイプが、短い/長い名字、電話番号の形式、米国以外の郵便番号などの極端なデータを考慮している
- ユーザーテストの記録はすべて、インサイトの箇条書きの要約とともにデベロッパーにまわす
- プロトタイプのイテレーションごとに、デベロッパーからのフィードバックと承認を集める
UIデザイン：
- 繰り返しのたびに、v.1、v.2、などにデザインファイルの名前を変更する。ただし、「最新版」や 「New 」は名前の変更をせず、新バージョンはすべて共有レポジトリにアップロードする
- メニュー、リンク、ボタン、パネルなどの再利用可能なパターンをできるだけ多く作成し、デベロッパーがコンポーネントベースのシステムを持てるようにする
- ユーザーエクスペリエンスとコードベースの一貫性を生み出すUIの決定を行う
- 画像フォーマットとサイズに関するデベロッパーの賛同を得る
- ガイド/オーバーレイを使ったグリッドシステムで、すべての重要なブレイクポイントにデザインを作成する
- タイポグラフィの整合性を保つため、例えば15.75ではなく15のように、フォント全体の値およびリーディングの値を使う
- 可能な限りウェブセーフフォントを使用し、カスタムフォントは複数使わない
- すべての写真とタイポグラフィの権利を所有していることを確認する
- 最終的に承認されたモックアップをプロトタイプと一緒に30分から1時間程度レビューする：プロジェクトの目標、ユーザーストーリー、インタラクション、ステート、失敗の状態をひと通り確認する
ハンドオフ中
視覚衛生：
- 使わないレイヤーをすべて「削除」する。デベロッパーを混乱させる可能性があるため、ただ隠すだけでなく削除する
- 未使用のガイドをすべて削除する
- ナビゲーション、フッターなどのUIモジュールに基づき、レイヤーを適切にグループ化し、名前を付ける
- 例えば、「ウィジェット」と「モジュール」は同じではないというように、デベロッパーと共通の命名規則に従う。BEM記法の使用を検討する。
- アートボードに「FINAL」や「LATEST」といった名前を付けるのではなく、v.1、v.2などの標準的なバージョン管理プロトコルに従う
- ナビゲーションをしやすくするために、デザインの送信前にすべてのレイヤーを折りたたむ
アセット：
- メインプロジェクト内にサブフォルダを作成し、関連するアイコン、フォント、画像をすべて格納する
- 可能な限りSVGを含める。ラスターファイルの場合、2倍速のバージョンを含める
ドキュメント作成：
- プロトタイプにユースケース、障害状態、インタラクションのニュアンスなどの注釈を付ける
- 各要素の横に、完全なコードスニペット（フレームワークではクラス）を注釈として記述する
- 検査ツールを使って、カラーコード、寸法、フォントサイズ、マージン、パディングなどの視覚的な仕様を自動生成する。朱入れはできるだけ避ける。
- すべてのドキュメントが、最終的なシステムの進化を反映するように更新されるようにする。デベロッパーは、最終プロトタイプを許容される動作の参考として、システムの深さと広さを理解するためにドキュメントを参照する
ハンドオフ後
ビルドの精度：
- デザイナーは、最終プロトタイプに対するQAプロセスで、各ビルドの「実装監査」を実施する
- デザイナーはPMと一緒にスプリントデモに参加する
- 受入テストには、最終プロトタイプに基づくUXの基準が含まれる
デザインシステム：
- アクセシビリティの要件と、開発プロセスへの影響について説明する。（例：Salesforce Lightning：「当社のフォームは、<fieldset>タグと<legend>タグの適切な使用と、入力コントロールの適切なラベリングを提供します。」）
- メニュー、ボタンなどのすべてのUIコンポーネントのコードスニペットと、ユースケースの具体的な説明を含める
- ダウンロード可能なUIキット、色見本、Githubなどのコードレポジトリへのリンクを掲載する
UXPinによるデザインハンドオフ
UXPinで多くの日常的なタスクが自動化されると、デザインハンドオフ時のUXチームの貴重な時間の節約になります。他のデザインツールとは異なり、UXPinは、ハンドオフドキュメントやアノテーションの作成のためのプラグインやサードパーティアプリケーションは必要ありません。
UXPinはツール内でデザイン仕様を生成するため、外部のドキュメントを必要とせず、誤解を回避することができます。デベロッパーはUXPinのスタイルガイドから直接アセットをダウンロードすることができ、DropboxやGoogle Driveのようなクラウドストレージでの共有は必要ありません。
デザイン、開発、プロダクトの各チームは、UXPinのコメントを使ってデザインハンドオフプロセスを通じての連携ができ、チームメンバーは互いにタグ付けし、タスクを割り当て、コメントをチームまたは一般公開のどちらで表示するかを選択できます。
デザインハンドオフを次のレベルに進め、製品のズレをなくしたいなら、Mergeテクノロジーはまさにピッタリでしょう。デザイナーは完全にインタラクティブなコンポーネントでプロトタイプを作成し、デベロッパーはそれを使って最終製品を作ることができます。デザイナーとデベロッパーが、レポジトリやStorybookに保存されている同じコード化されたデザインシステムから同じコンポーネントを使用するおかげで、同じページにいることができ、デザインハンドオフプロセスで出てくるすべてのエラーを回避することができるのです。
製品のズレを排除し、デザインシステムを最大限に活用するUXPin Merge の仕組みをぜひご覧ください。
