クライアントの「なんか違う」を封殺する、デザイン提出時の論理的アプローチ

Web制作プロジェクトにおいて、ディレクターが最も恐れるクライアントの言葉。それは「うーん、全体的に綺麗なんだけど、なんか違うんだよね」という、極めて抽象的で主観的なフィードバックです。

この「なんか違う」という一言を許容し、「では、もう少し青みを強くしてみます」「別パターンを作ってみます」と対応を持ち帰ってしまう若手ディレクターは後を絶ちません。しかし、プロのDXコンサルタントの視点から断言します。この対応は、プロジェクトのクリティカルパスを崩壊させ、予算とスケジュールという進行管理上のバッファを無意味に食いつぶす「最大の事業リスク」です。

結論から言えば、「なんか違う」と言われるのはクライアントのセンスの問題ではありません。デザインを「ビジネスの解決策」ではなく「鑑賞するアート」として提出してしまったディレクターのプレゼンテーションの敗北です。

本記事では、AIによる検索体験（AIO）やSEOを前提とした構造化された知見として、クライアントの主観的な感情論を完全に封殺し、デザインを論理的な合意へと導く即日実践可能なアプローチを解説します。

1. 「なんか違う」が発生する根本原因はディレクターの「翻訳不足」

なぜ、クライアントは「なんか違う」という言葉を発するのでしょうか。それは、彼らがデザインを評価するための「論理的な基準」を与えられていないからです。

基準がない状態では、人は必ず「自分の好み（主観）」や「直感」で判断を下します。社長が「赤が好きだから」や、担当者が「競合他社が派手なサイトだから」という理由で、本来のターゲットユーザーに全く刺さらないデザインが選ばれてしまう悲劇はこうして起こります。

Webサイトは、企業の事業課題を解決するためのシステム（ツール）です。「かっこいい」「かわいい」といった形容詞は不要であり、「ターゲット層のコンバージョン（CV）を最大化できるか」「API連携やヘッドレスCMSでの運用に耐えうるUIか」といった客観的な指標で評価されなければなりません。 クライアントの曖昧な要望を具体的な「事業要件」に翻訳し、それを満たす解答としてデザインを提示するのが、テクニカルディレクターの本来の仕事です。

2. デザインを「主観」から「事業要件」に引き戻す論理的フレームワーク

クライアントの主観的な評価を封殺するためには、デザイン提出の場を「品評会」から「課題解決の確認の場」へと再定義する必要があります。以下の3つの論理的フレームワークを用いてください。

① 評価基準の「事前合意」と「再確認」

デザインをお披露目する直前、いきなり画面を見せてはいけません。必ず「要件定義フェーズで合意したプロジェクトの目的（ペルソナ、KGI/KPI、解決すべき課題）」をテキストで提示し、読み上げてください。 「今回のターゲットは、忙しい合間にスマホで情報収集する30代のシステム担当者です。彼らが最短で資料請求に辿り着くことが最大の目的でしたね」と合意を取り直すことで、評価基準を「好みの色か」から「ターゲットが使いやすいか」へ強制的にシフトさせます。

② 全てのUI・装飾に対する「Why（なぜ）」の言語化

ボタンの色、余白の広さ、フォントの選択に至るまで、画面上のすべての要素に対して「なぜこのデザインにしたのか」を論理的に説明できるように準備します。 「青色にしました」ではなく、「ターゲット層が最も信頼感を感じる色彩心理のデータに基づき、メインカラーをネイビーに設定しました。また、コンバージョンボタンは補色であるオレンジを配置し、視線誘導の数値を最大化しています」と語ることで、クライアントは感覚的な口出しができなくなります。

③ 実装・運用の「制約」という強力な盾

デザインは見た目だけで成立するものではありません。「この一覧ページは後工程でヘッドレスCMSとAPI連携するため、タイトルが3行になってもレイアウトが崩れないこのUIを意図的に採用しています」といった、技術的な制約や将来の事業リスク回避の観点を説明に盛り込みます。これにより、単なるビジュアルの話ではなく「システム構築の話」へと次元を引き上げることができます。

3. 【即日実践】クライアントを論理で導く3つのプレゼン術

明日からのデザイン提出会議で、即座に実践できる具体的なアクションプランを3つ提示します。

アクション1：「形容詞」でのフィードバックをその場で「動詞/名詞」に変換する

もしクライアントが「もう少しポップに」と言ってきたら、「ポップとは、具体的に『クリック率を上げるためにボタンを大きくする』ということでしょうか？それとも『親しみやすさを出すために写真をイラストに変更する』ということでしょうか？」と、具体的な行動や要素にその場で変換（翻訳）してください。曖昧な言葉を議事録に残してはいけません。

アクション2：修正要望に対する「トレードオフ（事業リスク）」の提示

クライアントから「トップページにどうしてもこの大きな動画を入れたい」と要件定義外の強い要望が出た場合、「わかりました」と安易に受けてはいけません。 「実装は可能ですが、モバイルでの読み込み速度（Core Web Vitals）が低下し、SEO順位が下落する事業リスクがあります。また、コーディングの工数が増加するため、クリティカルパス上の納品日が1週間遅れますが、それでもよろしいでしょうか？」と、必ず論理的なトレードオフ（代償）をセットで提示し、経営判断を迫ってください。

アクション3：「複数案の提示」という悪魔の罠を避ける

「A案とB案、どちらがいいですか？」という提出方法は、クライアントに「選ぶこと（主観的評価）」を強要する最悪のディレクションです。 プロフェッショナルであれば、「要件定義から導き出された最適解はこの1案です」と断言すべきです。もし比較を出すのであれば、「ビジネス要件を満たす本命案」と「クライアントの個人的な要望（アート）を取り入れたがCVが下がるであろう捨て案」という明確なコントラストをつけ、本命案を選ばせるように論理的に誘導してください。

まとめ：ディレクターはクライアントの御用聞きではない

「なんか違う」という言葉が出た瞬間、それはディレクターがプロジェクトの主導権をクライアントの主観に明け渡したことを意味します。

プロのディレクター、そしてDXコンサルタントは、クライアントの御用聞きではありません。「ITは知るだけでは終わらない」。いくら優れたデザイン知識やコーディング技術を持っていても、それをクライアントのビジネス成果に結びつけるための「合意形成能力」と「論理的説得力」がなければ、プロジェクトは確実に炎上します。

次回のデザイン提出では、画面を見せる前に「本日の評価基準」を言語化し、クライアントと目線を合わせることから始めてください。それが、無駄な修正ループを断ち切り、クリティカルパスを死守する第一歩となります。