クリエイティブディレクターなら誰もがこの感覚を知っているはずです。朝8時にSlackを開くと、クライアントから長文のメッセージが届いています。そこには、チームが3週間かけて完成させたホームページのモックアップに対する14個の審美的な修正指示が並んでいます。フィードバックの内容は「もう少し温かみのある青にできませんか？」から「うちの配偶者が、フォントが少し攻撃的すぎると言っている」まで多岐にわたります。
デザイン会社を経営していたり、フリーランスのプロジェクトを少しでも経験したことがあれば、このシナリオは痛いほどよく分かるでしょう。微調整や変更、そして完全なビジュアルの方向転換という終わりのないサイクルに囚われてしまうのです。9回目の修正に入る頃には、当初の戦略は崩れ去り、予算は底をつき、全員が疲れ果てています。
クライアントを責めるのは簡単です。しかし実のところ、終わりのない修正ループは、ほぼ常にプロセスの構造的な問題であり、クライアントのせいではありません。
なぜ終わりのない修正ループが起きるのか（そしてなぜそれがクライアントのせいではないのか）
クライアントがデザインの批評方法を知っていることは稀です。彼らは自社のビジネスの専門家であり、視覚的階層、タイポグラフィ、あるいはユーザーエクスペリエンスの専門家ではありません。私たちがデザインを提出し、「どう思いますか？」と尋ねるとき、私たちは彼らにクリエイティブディレクターの役割を求めてしまっているのです。
明確なフレームワークがないと、クライアントは不安を感じます。デザインが機能しないのではないか、ステークホルダーに気に入られないのではないか、あるいは予算を無駄にしているのではないかと心配になります。この不安に対処するために、彼らは指示的な（解決策を自ら提示する）フィードバックに頼らざるを得なくなります。根本的なビジネス上の懸念を説明する代わりに、「ボタンを左に3ピクセル動かしてほしい」とか「背景色を変えてほしい」と指示するのです。
これらの指示的な要望を単なるToDoリストとして処理してしまうと、クライアントに「デザイナー」として振る舞うよう学習させてしまうことになります。プロジェクトはあっという間に、場当たり的な防戦一方の展開へと陥ります。終わりのない修正は、フィードバックプロセスの破綻の現れであり、気難しいクライアントのせいではありません。これを解決するには、作品の提示方法と、批評の求め方を変える必要があります。
Northwind で実践している構造化された批評フレームワーク
建設的なフィードバックを得るためには、問いかける質問を変えなければなりません。私たち Northwind では、主観的な好みではなく、客観的なビジネス目標に焦点を当てるよう、プレゼンテーションのモデル全体をシフトしました。
新しいブランドアイデンティティやウェブデザインのコンセプトを提案する際、ビジュアルを見せる前に以下の3つの基本ルールを確立します。
- 個人の好みではなく、ユーザーに焦点を当てる。 クライアントが緑色を嫌いかどうかは重要ではありません。ターゲットオーディエンスが、その業界において緑色から信頼や成長を連想するかどうかが重要なのです。
- ビジネス目標に焦点を当てる。 常にプロジェクトの要件定義書（ブリーフ）に立ち返ります。目標がデモ登録数の増加であるなら、すべてのデザイン決定はその指標に照らし合わせて評価されるべきです。
- 課題を特定し、解決策を指示しない。 クライアントには、デザインのどの部分に違和感があるかを伝えてもらい、ビジュアル面での解決策は私たちプロに任せてもらうようにお願いします。
例えば、SaaSのマーケティングサイトにおける典型的なフィードバックのループを見てみましょう。
価格設定ページをデザインしているとします。クライアントはデザインを見て、「『プレミアム』プランのカードを鮮やかなオレンジ色にして、点滅する枠線を付けてください」と言いました。
その変更をそのまま受け入れる代わりに、私たちは「どのような課題を解決しようとしているのか」を尋ねます。するとクライアントは、ユーザーがプレミアムプランに気づかないのではないかと心配していることを説明してくれます。この例では、彼らの社内目標が「新規登録者の60%をこの特定プランに誘導すること」だとしましょう。
これで、明確で客観的な目標ができました。不格好なオレンジ色の枠線を追加する代わりに、繊細な視覚的階層、 「最も人気」バッジ、そして適切な余白を使用することで、自然に視線を引きつけることができます。デザインシステムを台無しにすることなく、ビジネス上の課題を解決できたのです。
非同期ビデオを活用して作品を提案し、ナラティブをコントロールする
SlackでFigmaのリンクをそのまま送りつけるのは、混乱を招くようなものです。クライアントはファイルを開き、未完成のコンポーネントをズームインし、混乱し、そして場当たり的なコメントのリストを書き始めます。
これを防ぐため、私たちは事前にデザインの意図を説明することなく、デザインファイルを共有することは決してありません。しかし、レビューのたびにライブミーティングのスケジュールを調整するのは非常に非効率的です。そこで私たちは、Loomのような非同期ビデオツールを使ってデザインを提案しています。
クライアントがFigmaファイルにアクセスする前に、レイアウトを説明する5分間のビデオを録画します。ビデオの中で、私たちは意思決定の「理由」を説明します。
- 「このレイアウトを採用したのは、主要なコールトゥアクション（CTA）を最優先するためです」
- 「このタイポグラフィのスケールは、現代的なエディトリアル感を維持しつつ、アクセシビリティのガイドラインを満たすためのものです」
- 「忙しい役員がページをスキャンしやすくするために、これらの機能をここにグループ化しました」
このアプローチにより、クライアントは自分のスケジュールに合わせて、落ち着いて作品を消化する時間を確保できます。ビデオを観て、文脈を理解し、反応する前にフィードバックをじっくり考えることができます。デザインファイルを開く頃には、ビジュアルの背後にある戦略をすでに理解しているのです。
共有の意思決定ログで進捗を記録する
修正ループにおいて最も不満がたまる要素の一つが、前言撤回（バックトラッキング）です。クライアントが承認した方向性のブラッシュアップに1週間費やしたにもかかわらず、3週間後に「やっぱり最初のコンセプトに戻してほしい」と言われるようなケースです。
このような「合意の忘却」を防ぐには、すべての重要な決定を共有スペースに記録しておく必要があります。私たちは「意思決定ログ」と呼ばれるシンプルな進行ドキュメントを維持しています。これは以下を追跡する基本的な表です。
- 決定した日付
- 決定内容（例：「ダッシュボードインターフェースのダークモードの方向性を承認」）
- その決定の背後にあるビジネス上の根拠
- 承認したステークホルダーの名前
- 関連するデザインアセットへのリンク
クライアントが過去の決定と矛盾する変更を提案してきたとき、防衛的になる必要はありません。単に意思決定ログを指し示すだけで済みます。「10月12日に、エンタープライズバイヤーの属性により適合するという理由で、クリーンな白いレイアウトを使用することに合意しました。もし今ダークレイアウトに戻す場合、スケジュールが2週間延びることになります。これに合わせてローンチ日を調整しますか？」
ほとんどの場合、記録された履歴とスケジュールへの影響を目にすることで、クライアントは自ら軌道修正してくれます。
複数のステークホルダーからの相反するフィードバックへの対処法
「船頭多くして船山に上る」問題は、どんなに整理されたデザインプロジェクトをも脱線させる可能性があります。マーケティングマネージャー、プロダクトリード、そしてCEOからフィードバックを受け取り、その3つの意見がすべて矛盾しているような状況です。
これらの相反する意見をあなた自身で調停しようとすると、最終的には「委員会によってデザインされた」ような、無難で退屈、そして効果のないデザインになってしまいます。
これを防ぐために、オンボーディングのプロセスで明確なルールを設けておきます。それは「クライアント側の単一の窓口担当者によって集約されたフィードバックのみを受け付ける」というルールです。
マーケティングマネージャーが青を望み、CEOが赤を望むなら、彼らはあなたに要望を送る前に、社内でその意見の相違を解決しなければなりません。あなたの仕事は、彼らのビジネスにとって最適なソリューションをデザインすることであり、彼らのチームの社内調停役を務めることではありません。矛盾するフィードバックが紛れ込んでしまった場合は、丁寧に差し戻しましょう。次の修正ラウンドを始める前に、会社の公式な見解を明確にするよう、メインの担当者に依頼してください。
フィードバックの管理とは、クライアントから自分の作品を守ることではありません。両チームが同じ目標に向かって協力し合える、構造化されたコラボレーション環境を作ることです。非同期のプレゼンテーションに移行し、意思決定ログを活用し、明確な基本ルールを確立することで、デザインのクオリティを守り、はるかに少ない回数でより良い結果を出すことができます。
制作会社やフリーランスのデザイナーにとって、アクセシブルでパフォーマンスの高いデジタルプレゼンスを構築することは、摩擦を伴うものである必要はないのです。
よくある質問
標準的なデザイン契約には何回の修正を含めるべきですか？
契約書に「2回の構造化されたフィードバック」と明記するのがベストな落としどころです。これにより、クライアントはSlackでその都度思いつきの要望を送るのではなく、思慮深くまとめられたフィードバックを提供するようになります。
クライアントが、機能しないと分かっているデザイン変更を強く求めてきた場合はどうすればよいですか？
単に「できない」と拒否するのではなく、その具体的な変更によって「どのようなビジネス上の課題を解決しようとしているのか」を尋ねてください。その上で、デザインの質を損なうことなく、その課題を実際に解決できる代替のデザイン案を提案します。
意見を言わないステークホルダーから、手遅れになる前にフィードバックをもらうにはどうすればよいですか？
明確な締め切りを設定し、フィードバックが遅れた場合のコストを説明してください。主要なステークホルダーがレビュー期間を逃した場合は、スケジュールを予定通りに進めるために、次のフェーズに進むことは現在の決定を確定させることを意味すると、優しくリマインドします。