Figmaで承認したのに実装後の指摘が増える理由｜制作会社の防ぎ方
Contents
Figmaでは「これでお願いします」と進めたのに、ステージングを開いたとたん指摘が増える。
制作会社だと、一度は経験があると思います。
クライアントが気が変わった、というより、見ていたものが違っていたことが多いです。
誰かが悪い、という話にはしたくないので、ここでは現場で起きやすいズレと、無理のない防ぎ方を整理します。
現場でよくある、あの空気
デザイン確認のあと、制作側は実装に集中します。
クライアント側も「承認したから大丈夫」と思っている。
なのに実ページを見て、「ここ、前と違う」「スマホだと気になる」が出てくる。
制作側は戸惑います。
「Figmaで見ていただきましたよね」と言いたくなる気持ちも分かります。
ただ、相手も意地悪で言っているわけではなく、実物を見て初めて気づいた、というケースがほとんどです。
なぜ指摘が増えるのか
デザインデータと実ページでは、見るものが違う
Figmaでは、構成やトーン、コンポーネントの意図を見ることが多いです。
実装後は、実データの長さ、折り返し、フォントの見え方、ブラウザ差、フォームの動きが加わります。
同じ「確認」でも、論点が増えるのは自然です。
ここを最初に共有できると、「手戻り」より「次の確認」に聞こえやすくなります。
見た範囲が、お互いに曖昧なまま進む
忙しい確認では、PCの主要画面だけ見て終わることもあります。
スマホ幅や、空の状態、エラー表示までは見きれていない。
実装後にそこを見て指摘が出るのは、ある意味で健全です。
問題は、その前提が共有されていないことです。
文言や画像が、いつの間にか実データになっている
承認時はダミー文言だったのに、実装後は本番の文章や写真が入る。
印象が変わって「なんか違う」になるのはよくあります。
これはデザインの否定ではなく、データが入ったあとの確認だと伝えると、関係がこじれにくいです。
無理なく効く、二段の確認
「デザインの方向」と「実ページの確認」を分けて話す
キックオフやデザイン提出のときに、次のように分けるだけで空気が変わります。
- Figmaでの確認: 方向性・レイアウトの合意
- ステージングでの確認: 実表示・実データ・端末での見え方
「一度OKなら追加は受けません」と硬く言う必要はありません。
段階が違う、と伝えるだけで十分です。
実装後に出やすいことを、先に一言添える
依頼や引き継ぎに、短い予告を入れます。
実装後は、実データや端末での見え方も確認お願いします。Figmaで進めた内容でも、表示の調整が出ることがあります。
予告があると、後からの指摘が「やり直し」ではなく「予定どおりの確認」に寄りやすくなります。
実装に入ってからの小さな工夫
承認時に、見たとこ／まだ見てないとこを残す
完璧な議事録でなくて構いません。
「PC幅は確認済み」「スマホは実装後」など、一行でも残ると助かります。
持ち越し分が、そのままステージング確認のアジェンダになります。
実データで一度だけ、崩れやすい部品を見る
全部は難しくても、長い見出しや料金表など、崩れやすいところだけ先に見ると安心です。
実装後の指摘は、実ページ側を正にする
Figmaの古いコメントと実ページがずれると、どちらを直すか迷います。
実装フェーズに入ったら、実ページの指摘を正本にすると迷いが減ります。
書き方の型は、指摘テンプレートと同じで大丈夫です。
よくあるつまずき（責めないためのメモ）
Figmaのスレッドを、ずっとタスク一覧代わりにする
便利なうちはよいのですが、実装が進むほど古くなります。
どこかで「実ページ側へ移す」タイミングを決めておくと楽です。
追加指摘を、全部同じ温度で受ける
中には仕様追加に近いものもあります。
公開前必須と、あとでよいものを分けると、制作もクライアントも息がしやすくなります。
調整の話は、難しい修正依頼の進め方も近いテーマです。
実装レビュー開始時に送れる一言
Figmaでの方向性は共有済みです。ここからはステージング上の実表示・実データでの確認に移ります。追加の指摘は実ページ側を正にさせてください。
長く説明するより、この切り替えの一文があるだけで進みやすいです。
制作側の気持ちと、クライアント側の気持ち
制作側は、せっかく合意したデザインが揺らいだように感じて疲れます。
クライアント側は、実物を見て初めて気づいたことに素直になっているだけ、ということもあります。
ここを「約束破り」と受け取ると、会話が一気に硬くなります。
たとえば次のように言うと、少しやわらかくなります。
Figmaでは方向性まで確認いただきました。実ページでは、データや端末の見え方が加わるので、その差分だけ追加で見ていただけますか。
正しさを主張するより、差分の確認に言い換える。
これだけで、同じ指摘でも受け取り方が変わりやすいです。
実装が忙しい時期ほど、この一言を先に置いておく価値があります。
小さく始めるなら、ここから
全部の運用を変えなくても、次の案件のデザイン提出時に一言足すだけで始められます。
今回のFigma確認は方向性の合意です。実ページでの見え方は、実装後にあらためてお願いします。
これだけでも、承認の意味が共有されやすくなります。
実装後に指摘が増えても、「想定内の確認」として受け止められる余地が残ります。
大きなツール変更の前に、言葉の置き方から整えるのが現実的です。
まとめ
Figma承認後に指摘が増えても、関係が壊れたとは限りません。
見ていた対象が変わっただけ、ということが多いです。
制作会社としては、デザイン確認と実装確認を分けて伝え、実装後は実ページを正本にする。
それだけで、同じ指摘でも受け取り方が柔らかくなります。
Revoolなら、実装後の実ページ指摘をそのまま残せます
ステージング上の見え方を、場所が分かる形で残したいときに使えます。
レビューキャンバスでは、実画面のキャプチャに指示を付けてタスク化できます。
残件の見通しは、タスクテーブルのステータス一覧があると安心です。
デザイン確認と実装確認のつなぎ方として、Revoolトップも参考にしてみてください。
