「デザインカンプを見せてもらったときは、社内でも評判が良くて、これは良いものができるぞと思っていたんです。ところが本番のサイトに実際のデータを入れた途端、なんだか別物に見えて、正直ガッカリしてしまって」——Web サイトのリニューアルを終えたばかりの経営者から、こんな打ち明け話を聞くことが少なくありません。デザインそのものが悪かったわけではない。制作会社が手を抜いたわけでもない。それでも、承認したときの「これだ」という手応えと、公開後の現物との間に、埋めがたい段差ができてしまう。
この段差は、多くの場合「追加費用で揉めた」という別のトラブルとセットでやってきます。本番で崩れている箇所を直してほしいと頼むと、「それは当初の仕様にありませんでした」と返ってくる。発注者からすれば承認したデザインの通りに作ってもらいたいだけなのに、制作側からすれば想定外の作業に見える。なぜこんなすれ違いが起きるのか。結論から言えば、原因は誰かの怠慢ではなく、承認したプロトタイプが「都合のいい完成形」しか映していなかったという構造にあります。本記事では、この乖離の正体を発注者の目線でほどき、次の発注で何を確認すれば防げるのかを整理します。
プロトタイプは「いちばんキレイな一瞬」を切り取ったものでしかない
まず押さえておきたいのは、デザインカンプやモックアップは、サイトが取りうる無数の状態のうち、たった一場面を切り取ったスナップショットでしかない、ということです。そしてその一場面は、たいてい「いちばん見栄えのする状態」が選ばれています。
デザイナーがカンプを作るとき、商品名は文字数のちょうどいいダミーが入り、ニュース欄には新着が三件きれいに並び、お客様の声には改行の収まりがいい短文が入っています。写真は高解像度で構図も整っている。これは作為というより、デザインを評価しやすくするための自然な配慮です。けれど発注者は、この「お膳立てされた一瞬」を見て、サイト全体を承認した気持ちになります。ここに最初のズレの芽があります。
本番が立ち上がると、何が起きるか。商品名は想定より長く、二行に折り返してボタンを押し出す。新着ニュースはまだ一件もなく、ぽっかり空いた欄が間延びして見える。お客様の声には熱のこもった長文が届き、カードの高さがバラバラになる。写真は現場でスマホ撮影したもので、構図も明るさも揃わない。一つひとつは小さな差ですが、積み重なると「カンプとは別物」という印象になります。承認したのは理想的な一瞬で、運用するのは雑多な現実だった——これが乖離の土台です。
食い違いは「忠実度」の三つの層で起きている
なぜカンプが現実を映せないのかを、もう少し分解しておきます。プロトタイプの「本物らしさ」、いわゆる忠実度には、見た目・データ・挙動という三つの層があり、カンプはこのうち見た目しかカバーしていないことが多いからです。
一つめは見た目の忠実度。色・余白・フォント・装飾といった、静止画として整っているかどうかです。カンプが得意とするのはここで、発注者が承認するのも基本的にこの層です。二つめはデータの忠実度。実際に入る文字量・件数・空欄・極端に長い名前や住所などを、本番相当で流し込んだときに崩れないか。三つめは挙動の忠実度。クリックしたら何が起きるか、読み込みが遅い回線でどう見えるか、入力を間違えたときにエラーがどう出るか、スマホの細い画面でレイアウトがどう変わるか、です。
海外のデザイン専門誌 Smashing Magazine は、プロトタイプがユーザーに対して「正直でない」と表現しています。本物そっくりに見えるのに、肝心の挙動が作り込まれていないと、利用者はどこかで違和感を覚えて本気で使ってくれない、という指摘です。発注者の承認も同じで、見た目の層だけで「これでいい」と判断すると、データと挙動の層は誰も確認しないまま本番へ流れ込みます。後から「ここが崩れている」と言われても、制作側は「合意したのは見た目だけのはず」と感じる。揉めごとの根はここにあります。顧客の実態をどこまで解像度高くつかむかという観点は、顧客理解の4段階 でも扱っていますが、データと挙動の忠実度はまさに「実態をどこまで見たか」の問題です。
| 忠実度の層 | 何を見るか | カンプでの扱われ方 |
|---|---|---|
| 見た目 | 色・余白・フォント・装飾 | しっかり作り込まれ、承認の対象になる |
| データ | 実際の文字量・件数・空欄・長文 | ダミーで済まされ、確認されにくい |
| 挙動 | エラー・読み込み・スマホ表示 | 静止画では再現されず、抜け落ちる |
承認プロセスそのものに落とし穴がある
乖離は忠実度だけの問題ではありません。承認のやり方にも、すれ違いを生む落とし穴が潜んでいます。
よくあるのは、PC の大画面で、整ったダミーデータの入ったカンプを、会議室のプロジェクターで眺めて「いいですね、これで進めてください」と決めてしまうパターンです。このとき確認されていないものを並べると、その多さに驚きます。スマホでの見え方、データが空のときの状態、入力エラーの出方、本文が長い記事ページ、画像が差し替わったときの収まり——いずれも実際の利用者がいちばん多く出会う場面なのに、承認の場では一度も俎上に載っていません。
さらに厄介なのが、口頭やチャットでふんわり合意してしまうことです。「全体的にいい感じですね」で進めると、では何をもって「カンプ通り」とするのか、どこからが追加なのか、という線引きが誰の頭の中にもありません。仕様変更による追加費用は、要件定義書に書かれていたかどうかで判断されるのが実務の原則です。逆に言えば、書かれていないことはすべて解釈の余地になり、揉めごとに化けます。「承認したつもり」と「合意した仕様」の間にあるこの空白こそ、追加費用トラブルの温床なのです。
事例: 採用サイトで「応募ゼロの初日」が崩壊した話
具体的な例を一つ挙げます。従業員四十名ほどの建設業の会社から、採用強化のためのリニューアル相談を受けたときの話です。
前の制作会社で作った採用サイトに、社長が強い不満を持っていました。デザインカンプの段階では、社員インタビューが六本ずらりと並び、募集職種が五つ、応募者の声まで載った、活気あるページに見えた。社内の承認もすんなり通った。ところが公開初日、現実は違いました。インタビューはまだ二本しか用意できず、三本目以降の枠が空のカードになって不格好に並ぶ。募集は一職種だけで、ほかの枠は「準備中」の文字が浮く。応募はまだ一件もないので、応募者の声の欄はまるごと空白。「カンプではあんなに賑やかだったのに、開けてみたら閑古鳥が鳴いているように見えた」と社長は表現していました。修正を頼むと「空のときの表示はご指定がなかった」と追加見積もりを出され、関係がこじれて、結局そのまま当社へ相談が来たのです。
当社で作り直す際に変えたのは、進め方そのものでした。デザイン段階で、インタビューが六本そろった理想形だけでなく、二本しかないとき・一本のとき・ゼロのときの三パターンを実データ相当で作り、社長に並べて見せました。空のときは「インタビューを順次公開予定です」と次の動きを促す文言が出るようにし、募集ゼロでも採用への本気度が伝わる作りにした。承認の場には経営陣だけでなく、実際に原稿を入れる総務担当にも入ってもらい、本物の社員名・実際の職種名を流し込んだ状態で確認しました。結果、公開後に「カンプと違う」という声はゼロ。コンテンツが少ない立ち上げ初期から見栄えが保て、公開から三か月で応募が前年同期の二倍強に増えました。理想形ではなく、いちばん貧弱な状態を先に承認する——これが効いた事例です。
次の発注で確認すべきこと
では、発注者として次に何をすればこの事故を防げるのか。むずかしい専門知識は要りません。承認の前に、制作会社へ次の問いを投げるだけで、乖離の大半は防げます。
最初の問いは「実際のデータを入れた状態を見せてください」です。ダミーではなく、自社の本物の商品名・社員名・想定される長い文章で崩れないかを確認します。次に「情報が空のとき・少ないときはどう見えますか」。立ち上げ直後やニュースが途切れた時期に、ページが間延びしないか、次の行動を促す表示が出るかを確かめます。三つめが「スマホとエラーの状態を見せてください」。利用者の多くはスマホで訪れ、入力を間違えます。その二つが整っているサイトは、それだけで信頼を落としにくい。
そして最後に、口頭の「いいですね」で終わらせず、何をもって「カンプ通り」とし、どこからが追加なのかを書面で握っておくこと。検収の基準を曖昧にしないだけで、後の追加費用トラブルは大きく減ります。良い制作会社ほど、こうした問いを歓迎し、むしろ向こうから空状態やエラー状態の確認を提案してきます。逆に「本番に入れてみないと分かりません」で押し切る相手は、乖離のリスクを発注者へ丸投げしているサインだと考えていいでしょう。実データを前提に運用まで見据えて設計する考え方は、AI-Readyなデザインシステム や、情報の正確さがブランドを左右する点を論じた AI検索の誤情報とブランド とも地続きです。
当社では、Web 制作・リニューアルのご相談をいただいた際、理想形のカンプだけでなく、データが空のとき・少ないとき・崩れやすいときの状態をデザイン段階でお見せし、本物の原稿を流し込んだ状態で一緒に確認しながら進めています。「デザインは良かったのに出来上がりにガッカリした」という経験をお持ちの方、これから発注を控えていて同じ轍を踏みたくない方は、現状のサイトやお手元のカンプを拝見しながら、どこに乖離の芽があるかを一度ご相談ください。承認のしかたを少し変えるだけで、公開後の「思っていたのと違う」は確実に減らせます。
Sources
- Your Prototype Is Not Being Honest With Your Users (And Here’s How To Fix It) — Smashing Magazine
- The Role Of Empty States In User Onboarding — Smashing Magazine
- How To Design Error States For Mobile Apps — Smashing Magazine
- レスポンシブデザインに見るデザインカンプと実装との溝 — シフトブレイン
- システム開発の仕様変更で追加費用が発生する原因と、発注者が取れる具体的な防止策 — 秋霜堂株式会社
