このブログは「Design Handoff to Developers: How to Stay True to Your Original Vision」の抄訳です。
デザインのハンドオフプロセス、つまりデザイナーから開発者へデザインのビジョンを引き継ぐ工程は、プロダクト開発において最も重要である一方、最も難しいフェーズの一つです。これが適切に行われないと、期待値のズレ、一貫性のない UI 実装、チームのフラストレーション、そして非常に質の低い顧客体験につながります。本ガイドでは、オリジナルのデザインビジョンを維持しながら、デザインを効果的に開発者へ引き渡す方法について解説します。
デザイナーはお気に入りのツールでアイデアをスケッチし、それを Figma でワイヤーフレームに落とし込みます。時間が経つにつれて、そのワイヤーフレームには色やタイポグラフィ、レイアウトの洗練が加えられていきます。時には、インタラクションやアニメーションをデモするために、クリック可能なプロトタイプを作ることもあります。
そして、開発へのデザインハンドオフという重要な瞬間が訪れます。ここでビジョンが実装と向き合います。エンジニアのチームがこれらのデザインを受け取り、コードとして再現していきます。
2週間後、デザイナーがビルドされたものを見て、愕然とします。フォントが変わっている。色味が違う。すべての矩形を囲んでいた完璧な 16px のボーダーが不揃いになっている。誰かの判断で、ボタンの角丸が少し大きくされている。
個人的な感情として、これはデザイナーの自尊心を傷つけます。しかも多くの場合、これらのスタイル要件はクライアントから直接指定されたものです。あの青は、デザイナーが適当に選んだ 16 進数の色コードではありません。それはダーク・コーンフラワー・ブルー、#194390 なのです。
デザイナーと開発者は、それぞれ異なる考え方や優先事項を持っています。それでも両者は、実際に動くプロダクトを世に出すために、一緒に取り組まなければなりません。
UI プロジェクトが始まる前に、チームは通常、要件の一覧について合意します。画面の解像度やサイズ、対象プラットフォーム、機能、Web かモバイルかといった点です。これらが決まった後に、デザイン作業が始まります。
ここで登場するのが「単一の信頼できる情報源（Single Source of Truth）」という考え方です。これは、デザインハンドオフを成功させるために不可欠な原則です。この用語は、データ管理における不整合を防ぐ必要性から生まれたものですが、デザインのハンドオフや実装にも同様に当てはまります。
初期の頃、UI デザインは Photoshop のようなツールで行われることが一般的でした。Illustrator ではなく Photoshop が多用されていたのは、個人的にはいつも不思議に感じていました。UI を扱うのであれば、ベクター素材の方が適していると私は思うからです。いずれにせよ、これらのツールは UI 作業に特化していない、静的なアセットを生成するものでした。
デザインのハンドオフプロセスも非常に不格好でした。Photoshop からレイヤーコンプを一括書き出しし、それらを PDF にまとめ、開発向けに注釈を付ける――そんなやり方が一般的だったのです。当時は、UI や UX に特化したツールが必要だという認識自体が、業界全体にまだ浸透していませんでした。
それから時代は進み、Sketch や Adobe XD、そして現在もっとも広く使われている Figma のようなツールが登場しました。これらのツールによって、デザイナーは UI をデザインするだけでなく、プロトタイプを作成するところまで、ほぼすべてを一貫して行えるようになりました。
また、業界全体としては、デザインシステム(design systems)を標準とする流れが急速に進んでいます。デザインチームは、プロジェクトを横断して再利用できるコンポーネントやスタイルのライブラリを管理しています。その結果、多くの場合、デザイナーはすべてを一から作るのではなく、デザインシステムから必要な要素を組み合わせてデザインするようになっています。
Figma のようなツールは、デザインハンドオフのためのプラットフォームとして不可欠な存在となり、最終的なプロダクトがどのように見えるべきかを示す参照点を提供しています。しかし多くの場合、開発者はデザイナーが作成した Figma ファイルをそのまま利用することはできません。あくまで参考資料として用い、それを基にフロントエンドをコードで再実装します。
高度なアニメーションや、完全に機能するコントロールは、Figma 上で本当に実装されているわけではありません。それでも、そうしたインタラクションを設計すること自体は、デザイナーの重要な役割であり続けています。これこそが仕事における「UX」の部分です。
デザインから開発へ移行する過程では、どうしても情報が失われてしまいます。デザイン仕様書や参照ドキュメントはその橋渡しの役割を果たしますが、それでもなお、両者の間にはギャップが残ります。
開発の世界には、よくこんな言葉があります。「まずは動くものを作れ。見た目を整えるのはその後でいい。」機能するものを期限内にリリースする責任を担っている立場からすれば、この考え方はとても理にかなっています。
一方で、デザイナーの仕事はその正反対のところから始まります。最優先されるのは、視覚的に分かりやすく、魅力的で、ユーザーを惹きつけ、支えるものを作ることです。
デザイナーは、比較的厳密なプロセスに沿って作業を進めることが多いです。私が教わった流れは、次のようなものでした。
アイデア出し ⇒ サムネイル ⇒ キーフレーム ⇒ ストーリーボード ⇒ ワイヤーフレーム ⇒ クリエイティブ表現
ここで重要なのは、アイデアから完成形に至るまでには、どうしても時間がかかるという点です。
アートやデザインは、急かされるとうまく機能しないプロセスなのです。
開発者が制御構造やデータ型について一つひとつ意識的に判断するのと同じように、デザイナーもタイポグラフィ、色、レイアウトについて明確な意図をもって選択を行います。
また、多くの場合、デザイナーは厳格なブランドガイドラインの中で作業しています。大企業では、ロゴやカラーパレットを気軽に変更することは許されません。こうした制約は偶然や好みで決められたものではなく、すべて意図をもって定められたものなのです。
デザイナーは、使用するツールによって表現の幅が制限されます。コードであれば、ある程度は自由に何でも書くことができますが、デザイナーはツールが表現できる範囲の中でデザインを行う必要があります。
さらに、マイコン（MCU）のようなローエンドなハードウェア向けにデザインする場合、表示できる内容には明確な制限があります。Qt for MCUs のようなフレームワークは、デザイナーと開発者の協業を支援してくれますが、デザイナーは必ずしもハードウェアの専門家ではありません。そのため、創作の初期段階では、こうした制約が十分に意識されていないことも少なくありません。
ここで触れておくべき重要な点として、デザインと開発の間にはパワーバランスの偏りがあります。開発者は、デザイナーがいなくても、機能するプロジェクト全体を作り上げることができます。実際、長い間、そして多くの業界で、それが当たり前でした。
医療、航空宇宙、防衛といった特定の分野では、UI が「どう見えるか」よりも、「どれだけ安全で確実に動作するか」が重視されることが少なくありません。そのような環境では、デザインは「あれば望ましいもの」程度に扱われることもあります。
一方で、多くのデザイナーは、プロジェクト全体を一人で完成させることはできません。自分たちの仕事を現実のものにするためには、開発者の力に依存しています。
現在、ユーザーインターフェースは至る所に存在しています。本来スクリーンを持つ必要がなさそうなデバイスにまで、画面が搭載される時代です。「モダンな」インターフェースへの需要は、かつてないほど高まっています。デザイナーはこれまで以上に必要とされている一方で、最終的に何が製品として出荷されるかの決定権は、依然として開発者が握っています。この不均衡こそが、デザインと開発の間に生じる多くの衝突の根底にあります。
2025年において、AIの話題を避けて通ることはできません。この記事を書き始める直前にも、私は Figma Make を触ってみて、わずか数分でクリエイティブな表現を含む動作するプロトタイプを生成できました。最近では、一緒に仕事をしている開発者たちも、必ずしも私に「簡単なモックを作ってほしい」と頼むわけではなく、自分たちで AI を試すようになっています。
私は、AIとは共存していけるものだと考えています。ただし、それがバランスを変えつつあるのも事実です。もし AI が説得力のあるデザインを生成できるのであれば、「では、デザイナーは何のために必要なのか？」という問いが自然と生まれてきます。
美術大学で最初に学ぶことのひとつが、「正しい講評（クリティーク）のやり方」です。そこでは「私はこう思う」「あなたはこうだ」といった主観を中心にした言い方を避け、できるだけ客観的にフィードバックするよう教えられます。デザイナーは、自分自身と自分の作品を切り離して考えなければなりません。
とはいえ、それは簡単なことではありません。アートやデザインは情熱に満ちた分野です。感情を完全にオフにすることはできません。しかし、どこかの段階で、すべてのデザイナーは「kill your babies（自分の作品への執着を手放す）」ことを学ぶ必要があります。ひとつの表現に固執しすぎると、改善ができなくなってしまうからです。
ここで、冒頭に出てきた「開発者がボタンの角丸を変えてしまった」という場面に戻ってみましょう。もし、その新しい角丸のほうが、UI内の他のコンポーネントの丸みとよりよく合っていたとしたらどうでしょうか。デザイナーだからといって常に正しいとは限りませんし、開発者の意見がデザインをより良くすることもあります。
多くの場合、こうした問題の根本原因は、コミュニケーションやコラボレーションの不足にあります。
これまでに挙げてきたツールは、デザイナーと開発者の双方が同じファイルにアクセスし、コメントを残せるという点で非常に有用です。しかし、逆方向はどうでしょうか。フロントエンドがどのように変化しているのかを確認するために、Git リポジトリを常に追いかけているデザイナーは、そう多くはないのではないでしょうか。
デザイナーの立場から言えば――もちろん、最終決定権はデザイナーにある、と思いたいところです。
しかし現実には、実際に動くものを世に出すためには、常にコラボレーションと妥協が必要になります。開発とデザインの間には、必ず行き来や調整が発生します。Figma に「開発モード」といった機能が用意されているのも、そのためです。
プロジェクトが開発者の手に渡ったあとでも、デザインに関する変更は起こり得ます。開発とデザインの間でやり取りが続くことは、プロセスの失敗ではありません。
それこそが、まさにプロセスそのものなのです。
デザインを開発者にうまく引き渡すには、単にファイルを渡すだけでは不十分です。必要なのは、適切なツール、明確なコミュニケーション、そして確立されたプロセスです。
AIブームが起こる以前から、「ローコード」や「ノーコード」と呼ばれるツールには注目が集まっていました。これらは、プログラミング経験のない人でも、動作するコードを生成できるツールです。
まだ完璧な形には至っていませんが、Unreal、Blender、Unity におけるノードグラフエディタや、Figma におけるフローや遷移を視覚的に定義する仕組みなどが存在します。こうしたシステムは、ロジックや状態、処理の流れを、非プログラマーにとっても理解しやすい形で可視化してくれます。
その意味では、従来の「デザイナー」と「開発者」という役割の境界は、少しずつ曖昧になりつつあります。
Qt も独自のワークフローを提供しており、Figma からアセットを取り込み、QML でフロントエンドを生成することができます。 Figma to Qt を使えば、Figma 上の GUI デザインを QML コードに変換でき、開発者が一から書き直す手間を省くことができます。一方、Qt Design Studio では、グラフィカルなユーザーインターフェース上でフロントエンドのインタラクションを構築することが可能です。
一般的に、多くのデザイナーはプログラミングを学ぶことに抵抗感を持っています。私たちの多くが美術系の学校に進んだのには理由があります。絵を描き、デザインをしたかったのであって、数学をやりたかったわけではありません。
とはいえ、ほんの少しコードを学ぶだけでも、その効果は大きいものです。状態（state）、イベント、制約（constraints）といった基本的な概念を理解することで、実装可能性を踏まえたインターフェース設計がしやすくなります。また、開発者が日々直面している制約に対する共感も生まれます。
ときどき、人々は神話的な存在である「ユニコーン」について語ります。これは、デザインもコーディングも両方できる人のことを指します。
デザイナーは、Figma のような UI ツールを使って、インターフェースのための静的、あるいは半インタラクティブなアセットを作成します。一方、フロントエンド開発者は、それらのアセットをもとに、HTML/CSS や JavaScript、QML などのコードとして再実装します。
ユニコーンとは、その両方ができる人です。デザインもでき、実装もできる存在です。
実際の現場で、私は多くの「真のユニコーン」を見たことはありません。確かに存在はしますが、非常に稀です。GUI ベースのツールがより強力になり、コーディング環境が初心者にも扱いやすくなるにつれて、この二つの歴史的な役割の境界は、今後ますます曖昧になっていくでしょう。
しかし、それでもなお、デザインと開発の両方の視点が必要であることに変わりはありません。
デザイナーと開発者のワークフローに、完璧な解決策はあるのでしょうか？
おそらく、ありません。
しかし、より苦痛の少ない、そして協力的なプロセスにするための実践方法は確かに存在します。そうした工夫によって、デザインハンドオフは「対立の場」ではなく、「共同作業の場」に変えることができます。
デザイナーと開発者の効果的なコラボレーションは、コミュニケーションから始まります。
人間関係と同じで、丁寧で明確なやり取りは、プロジェクトそのものを救うことがあります。
開発の世界では、コード内にコメントを書くのはごく普通のことです。
処理のかたまりの前に、「なぜこのロジックにしたのか」「どんな意図があるのか」を説明するコメントを残します。
同じ考え方が、いまや Figma のようなデザインツールにも広がっています。コメントや注釈を通じて、デザインの背景や考え方を共有できるようになりました。たとえば、次のような点です：
こうした意図を説明することで、開発者は判断の背景を理解できるようになります。
その結果、デザイン上の選択を尊重しやすくなり、同時に、開発者が技術的な理由で懸念を示すときも、デザイナー側が納得しやすくなります。共通の文脈を持つことが、健全な議論とより良い成果につながるのです。
誰しも一度は経験があるはずです。さっきまで作業していたファイルを探してマシンを開いたのに、どこにも見当たらない。ゴミ箱に入ってしまったのかもしれないし、何か別のことが起きたのかもしれません。いずれにせよ、ファイルは消えてしまった。
そのたびに得られる教訓は同じです。バックアップを取ること。
デザイナーは、次のような手段を使うべきです：
一方、開発の世界では、バージョン管理はすでに当たり前の存在です。
ローカルまたはリモートのリポジトリを管理することで、次のことが可能になります。
デザインのチームも、この考え方を取り入れることができます。
一貫したファイル命名ルール、バージョン付きの書き出し、あるいは専用のデザイン用バージョン管理ツールなど、形はどうであれ、冗長性と履歴管理は不可欠です。
開発者とデザイナーは、異なる世界から来ています。受けてきた教育も、重視するポイントも、使う言葉さえ違うことが多いでしょう。それでも最終的には、同じ一つのプロダクトを世に出す必要があります。
相互リスペクトとは、次のことを理解し、認めることです：
一行一行のコードは、バランスの取れたカラーパレットと同じくらい、洗練され、思慮深いものになり得ます。デザイナーは分かりやすさや心地よさを追求し、開発者はパフォーマンス、保守性、安定性を追求する。その方向性は違っても、どちらもプロダクトを良くするためのものです。
本当に優れたプロダクトは、「相手も善意で行動している」という前提に立ち、互いの専門性を尊重するところから生まれます。
私の考えは明確です。AIはプロセスを置き換えるものではなく、プロセスの隙間を埋める存在であるべきです。アートを生み出すのは人間であるべきだと、私は強く信じています。ただし、AIに有用な場面があることも否定できません。
たとえば、AIは次のようなことに役立ちます:
実際、私はこの文章のいくつかの段落構成を考える際に、NotionのAIを使いました。私は訓練されたクリエイティブライターではないので、代筆者としてではなく補助としてAIを使ったのです。
AIは面倒な作業をスピードアップし、アイデアを可視化する助けになります。しかし、デザイナーや開発者としてあなたが持っているもの――センス、判断力、そして実体験――を置き換えるべきではありません。
UIデザインは一つのクラフトです。情熱そのものです。そして確かに、そこにはエゴも伴います。
私が手がけるデザインは、最終的なプロダクトがどうなるかを示す設計図のようなものだと考えています。変更が入ることは常にありますが、全体のビジョンやコンセプトは、誰が見ても分かる形で残るべきです。建築家が構造エンジニアのために家を設計するのと同じように、デザイナーと開発者は互いに支え合い、依存し合っています。