「前に決めましたよね」と言わずに、修正のズレを確認する方法
「この説明、少し長いので削ってもらえますか？」
前の打ち合わせでは、必要だと考えて入れた説明。それを削りたいと言われたとき、「前に決めましたよね」と返すのは、少し言いづらいものです。
たとえば、こんな聞き方ができます。
「短くしたい意図は分かりました。この説明は、相談前の不安に答えるために置いていました。必要な情報を短く残すか、別の見せ方にするか、一緒に確認できますか？」
※この記事の相談サービスのサイトと文例は、説明用の架空の例です。実際の案件や改善実績を紹介するものではありません。
この聞き方では、相手が変えたい理由を受け止めたうえで、もとの設計意図を共有しています。そして、変更後にどうするかを一緒に確認します。
今回は、この言い方を自分の案件でも使えるように、確認する順番と、その準備の仕方を整理します。
まずは、この順番で確認する
確認したいのは、次の3つです。
1．今回、何を良くしたくて変えるのか
2．もとの内容は、何のために決めたのか
3．変更後、その目的をどう満たすのか
先ほどの例なら、「画面を短くして読みやすくしたい」が今回の意図。「相談前の不安を減らす」がもとの目的です。
どちらも大事にするなら、説明を短くまとめる、見せ方を変える、といった案を検討できます。方針自体を変える必要があるなら、その理由から確認します。
自分の案件で使うときは、次の文に当てはめてみてください。
「［今回の変更意図］ということですね。
当初は［利用者の迷いや不安・達成したい目的］のために、［決めていた内容］としていました。
今回の変更後は、その目的を［どう満たすか］、一緒に確認できますか？」
相手の意図がまだ分からないときは、先に「今回、どの点を良くしたいとお考えですか？」と聞きます。こちらの推測で埋めないことも大切です。
設計意図は、利用者の迷いから説明する
僕は、ユーザーの心理からサイトを設計することを大切にしています。何を見せれば動くかを考える前に、どこで迷うのか、何が分からないと先へ進めないのかを考える。
そのうえで、情報の順番や説明の量、ボタンを置く場所を決めていきます。
たとえば、相談サービスのサイトなら、申し込む前に「何を話せばいいのか」「まだ内容がまとまっていなくても相談してよいのか」と迷う人を想定します。
その不安に答えるため、申し込みボタンの手前に、準備する内容、当日の流れ、相談後にどうなるかを置く。
ここまで共有できていれば、「前に入れると決めたから残したい」だけでなく、「この説明には、相談する前の不安に答える役割がある」と話せます。
ただし、想定した不安が、実際の利用者にも当てはまるとは限りません。新しく分かった反応があるなら、最初の設計も見直します。
修正を重ねるうちに、最初の理由が抜け落ちる
初期設計で意図を共有していても、納品まで保たれるとは限りません。
デザインが形になると、「画面が縦に長い」「文字が多い」「ボタンまで遠い」といった、目の前の画面についての話が増えます。
長さが気になるという意見は、もっともです。ただ、説明を全部削ると、最初に考えた「相談前の不安に答える」という役割まで消えるかもしれません。
確認したいのは、その説明で解消しようとしていた不安を、変更後はどこで受け止めるか、ということです。
議事録を残していても、修正のたびに読み返されるとは限りません。誰かが違いに気づき、該当する記録を探し、今の修正との関係を説明する必要があります。
制作側が言い出しにくいのは、相手を責めたいわけではないからです。良くしようとしていることは分かる。それでも、そのまま進めると最初の目的から離れるかもしれない。
だから、言い方と一緒に、もとの理由を確かめる準備が必要になります。
話す前に、もとの合意と今回の修正を並べる
確認するときは、次の情報を手元に揃えます。
・今回の修正がある画面と箇所
・もとの方針を決めた議事録や資料
・変更によって影響を受ける目的や範囲
・まだ分かっていないこと
この確認を補助するために、PageAtlasにはAIチェック機能を用意しています。
今回の修正指示と、登録してあるコンセプトや議事録を照らし合わせて、違いがありそうな点を示す。担当者が一から探して整理する前に、確認すべき箇所が見えるようにする。
先ほどの架空のサイトなら、確認したい点はこうです。
「当初は、相談前の不安を減らすために説明を置く方針でした。今回の削除で、その情報を別の場所に移すのか、方針自体を変えるのか、確認が必要です」
これは仕組みを説明するための文例で、実際のAI出力や動作検証の結果ではありません。
担当者は、示された内容をもとの議事録で確かめます。そのうえで、冒頭のように、今の修正意図と当初の目的を並べて話します。
同じ記録と画面があれば、「誰がどう覚えているか」に終始せず、どの情報を残し、何を変えるかを具体的に相談しやすくなります。
方針を変えるなら、新しい理由も残す
前に決めた内容を、変える必要があることもあります。新しく分かった利用者の反応や、サービス内容の変更によって、最初の設計が合わなくなることもあります。
その場合は、変更の理由を確認して、必要な範囲で合意し直します。説明の置き方が悪かったのなら、制作側も見直す必要があります。
AIにも、読み違いや見落としがあります。古い議事録や、十分に記録されていない前提を参照することも考えられます。「AIが違うと言っているので、この修正はできません」と相手を押し切る使い方はしたくありません。
もとの合意と今の事情を確認し、最後は人が決める。そして、変更した理由も残しておく。
この考え方は、受注前にもつながります。誰に、何を伝えるサイトなのか。何をもって良いと判断するのか。方針が変わったら誰が決めるのか。その前提を、見積もりや進め方の相談の段階から言葉にしておく。
最初に共有した判断基準を制作中にも参照し、変更時には更新する。そうして初めて、初期設計が納品まで活きるのだと思います。
画面と記録を、毎日の確認に使う
PageAtlasは、TOPページのURLを入口に、サイト内の複数ページを自動巡回してフルキャプチャするツールです。取得した画面の該当箇所に修正指示を残し、共有できます。登録したコンセプトや議事録と、修正内容を照らし合わせるAIチェック機能も用意しています。
ユーザー心理を自動で解析するものでも、顧客への説明を自動送信するものでもありません。人が考えた設計と合意を、毎日の確認で使いやすくするための道具です。
まずは、次の修正で「今回の意図」「当初の目的」「変更後の満たし方」を並べてみてください。普段のチャットやドキュメントでも始められます。
その確認を画面や議事録と結びつけて進めたい方は、PageAtlasの機能とプランをご覧ください。
この記事と文例は無料です。PageAtlasのツール利用は月額2,200円（税込）／社です。
PageAtlasの機能とプランを見る
https://pageatlas.site/lp/?utm_source=note&utm_medium=organic_social&utm_campaign=pa_2026q4&utm_content=agreement_stress
修正指示そのものの書き方は、こちらの記事に記入例とテンプレートをまとめています。
修正指示を出す前に確認したい5項目【記入例つき】
https://note.com/design_idea/n/n3aabe65034aa
