デザイナーから開発者への「引継ぎ」の問題点 | アドビ UX 道場 #UXDojo

Web サイト、サービス、あるいはアプリの開発プロセスにおいて最も重要で、しばしば苛立たしい段階のひとつは、開発者が実装できる状態にデザインが達した場面で発生します。

従来のワークフローでは、デザイナーは他のチームから切り離されて、仕様が決まった後から開発が始まるまでの間、ピクセルパーフェクトなデザインを作成します。そしてクライアントから承認されたら、それを開発者に引き継ぎます。フィードバックを求めるためにステークホルダーとデザインを共有する機会は少なく、承認の段階でデザイン変更が発生した場合は、困難な対応を強いられることがあります。

最近では、こうした問題に対処するため、デザイナーはプロジェクトを通して他のチームと協業し、ビジョンの実現に取り組むことが多くなっています。しかし、開発者がデザイナーの意図を正確に把握することは依然として困難です。一方、デザイナーは、しばしば開発された機能や製品が自分のデザインと異なることを不思議に感じています。残念ながら、デザイナーと開発者の引き継ぎは、常にスムーズというわけにはいきません。しかも、時間やコストがかかったり、製品自体の失敗の原因になることもあります。

この記事では、デザイナーから開発者への引き継ぎが問題になりやすい主要な理由と、両者の間の溝を埋めるためのベストプラクティスや戦略を掘り下げます。

デザイナーから開発者への引き継ぎによく見られる落とし穴

「デザイナーと開発者の引き継ぎにおける最大の課題は、期待される最終結果についてのコミュニケーションと整合性の確保です」 とアドビで製品マネージャーとして働く Harish Narayan は指摘します。「デザイナーも開発者も、ギャップを埋めるために途方もない時間と労力を費やしています」

引き継ぐのではなく協業する

実際には、用語それ自体が問題の一部かもしれません。「引き継ぎという言葉は、デザインが開発者に手渡され、その後の作業は開発者の責任であることを示唆します。しかし、ユーザーが実際に使用するまで、デザインは完成していないというのが私の考えです。つまり、デザイナーと開発者は、デザインと開発の両方の段階を通じて、コミュニケーションを取り続けなければならないということです」と Harish は説明します。

EY wavespace でイノベーション & ストラテジーのリーダーを務める Bermon Painter は、引き継ぎという言葉が持つ問題に同意して、いったん引き渡された仕事が、明確化や改善のために戻されることがほとんどなかったと振り返ります。彼が大規模な金融サービス会社で働いていたときは、ビジネスチームが要件を定義して、それを渡されたマーケティングチームがコンテンツ仕様を作成していました。その後、資料を渡された情報アーキテクチャチームがワイヤーフレームを作成し、次に UX チームがワイヤーフレームから高忠実度のモックアップを作成した後、開発チームに引き継ぐという段取りです。

「このレベルで行われる一方通行のコミュニケーションは、伝言ゲームを思い出させます」 と Bermon はため息をつきました。「すべての引き継ぎにおいて、コンテキストと情報の一部が失われ、最後のチームに到達する頃には、オリジナルとは異なるものになってしまいます。同質の問題が、デザイナーと開発者の引き継ぎという考え方に存在します。開発チームにさまざまな資料が提供されるとき、メッセージには欠落があり、開発者は受け取った仕様を解釈しなければなりません。コンテキストが失われていたり、意図が誤って解釈された結果、本来の目的を十分に果たせない一連の機能が並ぶことは決して珍しくありません」

デザインを過剰に説明しない、弁護しない

また、デザイナーと開発者は、本質的に異なる視点から物事にアプローチしていると Harish は考えています。つまり、仕様を明確にし、差異を吸収し、ギャップを減らすには、多くのやり取りが発生するというわけです。たとえば、デザイナーは、再利用が意図されている既存のコンポーネントやトークンを常に認識してデザインしているわけではありません。従って、デザインシステムが存在しない場合、開発チームは多くの冗長な作業を行って一貫性のないコンポーネントをつくり出し、ｓ哀愁的には、完成までの時間が遅れることになるかもしれません。

製品戦略コンサルタントの Gretchen Anderson は「潜在的な例外事象や制限の検討を行うことなく、過剰に仕様を指定することに拘っているデザイナーは不満を感じることが多いようです」と付け加えました。彼女は、一緒に働く際の苦痛を軽減し生産性を高めることについて記した本「Mastering Collaboration」の著者です。

Gretchen Anderson は、人、プロセス、製品に関わる人のためのハンドブックを書いた

その他にも、スムーズな引き継ぎにするために留意するべき項目として、デザインについて弁護しないこと、開発者がデザインされたとおり実現できると仮定しないこと、ユーザー体験を犠牲にするような開発者からのフィードバックに過度に影響されないことなどがあります。

デザインのすべての状態を考慮する

デザイン業務の専門家である Ben Buchanan は、繰り返される過ちとして、デザインのすべての状態を考慮しないことを挙げています。

「ボタンのフォーカスやホバーのような基本的なことだけを意味しているのではありません。操作の成功と失敗の状態のようなものも含まれます。これらはすべて、デザインと言葉による簡単な説明を必要とします。それらが提供されない場合、開発者は何かをでっち上げなければ作業を継続できません」

コラボレーション改善のための戦略

つまるところ、コラボレーションを向上させるために、デザイナーは常に開発について考える必要があります。一方、開発者は、デザインとエンドユーザーのニーズを常に念頭に置いて作業する必要があります。より具体的に言えば、デザイナーはデザイン対象のメディアに関して、効果的にデザインするのに十分な技術的素養を持たなければなりません。また、開発者は、効果的に共同作業を行うのに十分なデザイン理論を知らなければなりません。

「相互理解と相手への敬意があれば、調整が対抗合戦ではなく協力になります」と Ben は説明します。「現実的な制約の中で、ユーザーの問題を解決するために協力しているのです。どちらかが現実的になれなかった場合、全員が不満を抱える結果になります」

デザイナーが開発者に対して、デザインのどの部分が最も重要であるかを説明すること、また、どの部分を構築するのが難しいか、あるいは時間がかかるかを説明するように依頼することで、開発者を支援できることを Ben は学びました。「この 2 つの視点を組み合わせると、デザインの質を犠牲にせず納期を守る方法を考えられるようになります。またこれは、デザインをわかりやすく説明し、開発者からの関与を促す手段でもあります」

Harish も同様の見解を示しています。「デザイナーと開発者は、早い段階から頻繁にコミュニケーションを取り、互いの仕事を共有するべきです。開発者からできるだけ多くのフィードバックを引き出し、プラットフォームの制約をできるだけ早期に検討し、誤解や理解不足を減らすことが良い結果につながります」

Gretchen は次のように付け加えました。「デザインが決定された背後にある理由を理解せずに、開発者がデザインを適切に扱うことは期待できません。文書化の時間を惜しまず、さらに重要なのは、デザインの判断の理論的な根拠について議論することです。それが、単純にスペックを満たすだけでなく、ユーザーの役に立つ成果を生み出す対価になるでしょう」

要件を仮定として見直す

Bermon が提案するコラボレーション改善のための別の方法は、要件を仮定と捉えることです。すなわち、要件は構築すべきものの最終的な記述ではなくて、完全に実装される前に検証が必要なものと考えるわけです。

「検証されていない仮定には多くのリスクがつきものです」と彼は説明します。「エンドユーザーが望んでもいない機能であるリスク。技術的に実現不可能な方法でデザインされているリスク。時間、予算、リソースの超過が起きるリスク。検証されていない仮定を伴う機能は、こうしたリスクや答えられていない疑問に満ちています。そして、予算の超過や精彩を欠くユーザー体験の主要な要因になります」

Bermon は、各々の分野に最適な方法論 (例えば、デザイナーはユーザー中心設計、開発者はアジャイル開発によるスプリント) を選択することを推奨します。そして、2 つの別々ではあるものの、連携した活動としてバックログを管理するよう提案します。

デザインシステムを作成する

チームは、効率を向上させ、一貫した体験を提供するために、標準的な命名規則を定め、プロセスを定義し、デザインシステムを作成するべきです。

「非常に迅速に出荷する必要がある場合、既存コンポーネントの組み合わせによる問題解決方法を開発者に尋ねてみるとよいでしょう」 と Ben は提案します。「彼らがとても素早くモックアップを組み立てられることに驚くかもしれません」

ただし、むやみにデザインシステムから逸脱しないよう注意が必要です。これは、Ben が最近のデザインチームで見かけるよくあるミスです。

彼は、「開発者と話す前に、標準のデザインを変更したいのか、新しいバリエーションを増やすのか、それとも標準コンポーネントを使うべきなのか」と自問することを勧めます。「そもそも、視覚的には意味があるが、技術的には互換性のない要素を組み合わせている場合もあります。デザインと実際のコードのギャップを縮めようとするデザインツールが増えている背景のひとつはこれだと思います」

コラボレーションを向上させるツールを使用する

単純なように聞こえるかもしれませんが、一緒に座っているだけで、コラボレーションに驚く程の効果があります。「何年も一緒に仕事をしてきたデザイナーと開発者が、一緒に座って仕事を始めた途端、わずか数分の間に、相手がどのように働くかについて啓発される姿を数多く見てきました」 とクリエイティブディレクターでアドバイザーの Dan Mall は、協業へのアプローチについての記事で述べています。彼と Brad Frost が 「ホットポテトプロセス」 と呼ぶアプローチでは、開発プロセス全体を通じて、デザイナーと開発者の間でアイデアがすばやくやり取りされます。

Dan Mall のホットポテトプロセス　出典: Dan Mall

一緒に座って作業できない場合は、ビデオチャットや他の同期ツールを使用します。Harish は、Slack のような専用のコミュニケーションチャネルを使い、 Google Drive や Dropbox で画像やスクリーンショットを共有することを推奨します。

また、定期的な確認とグループミーティングを設定し、結果が予想と大きく異なっていないことを確認するようにします。

障壁を取り払う

ですから、「引き継ぎ」という考え方は忘れて、デザイナーと開発者が別々に仕事をするのはもうやめましょう。一緒に座って、より多くのコミュニケーションをとり、共に問題を解決し、互いの強みを活かし、デザインシステムなどのツールを使用して、効率的な作業を目指すべきなのです。

Gretchen は次のように結論付けています。「デザイナーと開発者がペアとなり、それぞれが大局的な問題やより詳細な UI ウィジェットへの異なるアプローチを模索することで、信頼と共通理解が育ちます。それにより、迅速に行動し、それぞれのエゴを脇に置いて、ユーザーのために働くことができるようになります」

この記事がデザイナーと開発者のより良いコラボレーションを実現する助けになることを願っています。結局のところ、それこそが強力なアプリやサイトを構築するための基盤なのですから。

この記事は Best Practices for a Smoother Designer-Developer Handoff（著者: Oliver Lindberg）の抄訳です