目次
1. デザイン案件は「作る前」で8割決まる
進行が崩れる案件には共通点がある
進行が崩れる案件には、だいたい共通点があります。目的が曖昧、決裁者が見えていない、素材や情報が揃っていないのにスケジュールだけが先に決まっている。このどれか、あるいは複数が重なっていることが多いです。着手だけは早く、デザインも一見順調に見えるのに、終盤で急に差し戻しが増える案件は、ほぼこのパターンです。
たとえばLP案件で「今っぽくしてほしい」という依頼だけを受けて進めると、途中で「いや、もっと信頼感がほしい」「訴求が弱い」「営業から見ると違う」といった話が出てきます。つまり、見た目の話をしていたつもりが、実は誰向けに何を伝えるかが固まっていなかったわけです。進行が崩れる理由は、デザインが悪いからではなく、前提が定まっていないから、というケースが多いのです。
まず押さえるべきは、目的・制約・意思決定者の3点
案件の初期で最低限押さえたいのが、目的、制約、意思決定者です。
目的は、問い合わせを増やしたいのか、資料請求を増やしたいのか、採用応募を増やしたいのか。制約は、納期、予算、ブランドルール、実装体制、既存コンポーネントの有無などです。そして意思決定者は、誰が最終的にGOを出すのか。ここが見えていないと、レビューを何度も繰り返してしまいます。
特に注意したいのは、発注窓口と決裁者が別なケースです。窓口担当者の希望を満たしても、最後に上長や事業責任者から大きく差し戻されることは珍しくありません。だから初期の段階で、誰の観点がレビューに入るのかを確認しておくことが重要です。
2. 依頼受領〜キックオフで決めること
依頼時点で確認すべき基本情報
依頼を受けた段階で確認したいのは、以下の4点です。
- 何を作るのか
- なぜ必要なのか
- 誰向けなのか
- いつ必要なのか
シンプルですが、ここを曖昧にしたまま進めると、後々に影響します。Webサイト全体なのか、LPなのか、採用ページなのか、アプリの1機能なのかで、必要な情報も進め方も変わります。
たとえばアプリUIなら、既存フローとの整合やOSごとの差分、開発スプリントとの接続を見ないといけません。依頼物の種類によって確認項目が違うことを意識しておくと、質問の質が上がります。
ヒアリングでは“要望”ではなく“課題”を拾う
ヒアリングで気をつけたいのは、相手の要望だけ受け取って終わらないことです。
「もっとかっこよくしたい」「今っぽくしたい」「競合っぽくしたい」という要望は、あくまで表現のレイヤーです。その奥にあるのは、問い合わせが少ない、情報が探しにくい、ブランドの印象が古い、営業資料とトーンがずれている、といった課題であることが多いです。
ここで要望をそのまま持ち帰ると、見た目の話しかできなくなります。逆に、課題まで落とし込めていると、デザイン以外の打ち手も見えてきます。たとえば「かっこよくしたい」の裏が「採用候補者に古く見られている不安」なら、写真選定、コピー、社員紹介の見せ方も重要になります。ヒアリングは要望収集ではなく、課題の翻訳作業なのです。
キックオフで認識をそろえるべき項目
キックオフでは、認識を合わせるべき項目をあえて明文化したほうがいいです。目的、対象ユーザー、制作スコープ、レビュー回数、連絡手段、納品形式、スケジュール、誰がどこで確認するのか。このあたりが口頭だけで決められてしまうと、進行に大きく影響が出てきます。
特に複数部署が関わる案件では、キックオフ資料や議事メモを残しておくことが効果的です。デザインそのものより、この初期整理で後半の荒れ方が変わると言っても大げさではありません。
進行で揉めやすいのは、修正回数、素材支給の責任範囲、テキスト確定時期、実装範囲、公開後の対応です。ここを最初に言語化していないと、「そこも見てもらえると思っていた」と言われてしまう事態が発生します。この種の行き違いはデザインスキルでは解決できないものだからこそ、最初に言語化・明文化しておくことが重要なのです。
3. 要件整理・リサーチ工程で品質が決まる
情報収集は参考デザイン集めで終わらせない
リサーチと聞くと、ギャラリーサイトを見たり、Pinterestで雰囲気を集めたりする人が多いです。もちろんそれも悪くありません。ただ、それだけだと表層の模倣で終わります。本当に必要なのは、競合が何をどう見せているか、類似サービスがどんな情報設計をしているか、既存サイトのどこで離脱が起きていそうか、といった構造の理解です。
(→ 掲載1万件以上！BRIK GALLERYはこちら！https://brik.co.jp/gallery)
たとえばBtoBサービスのLPなら、機能説明の順番、導入事例の見せ方、ボタンの置き方を比較する。アプリUIなら、一覧→詳細→操作完了までの導線がどうなっているかを見る。
このように参考探しとは、見た目の好みを集める作業ではなく、判断材料を増やす作業です。そうすることで拾った”課題”に対して最適な改善案を出すことができるのです。
要件定義で決めるべきこと
要件定義では、必須要件、優先順位、制約条件を切り分けておくことが重要です。全部が大事と言われがちですが、現場ではそうはいきません。たとえば、公開日固定の案件なら、最低限必要な情報と後追いで改善できる要素を分ける必要があります。アプリなら、既存コンポーネントに寄せるべき画面と、新規検討が必要な画面を分けたいところです。
非機能要件も見落としがちです。レスポンシブ、アクセシビリティ、更新性、パフォーマンス、CMS運用、端末差分。見た目の仕様だけ固めても、ここが抜けると後で苦しくなります。デザイナーがここまで見ていると、案件全体の精度がかなり上がります。
成果物に直結する仮説を立てる
要件を並べるだけでは、良いアウトプットにはつながりません。そこで必要になるのが仮説です。たとえば「ファーストビューで価値が伝わっていないから離脱しているのでは」「入力負荷が高くてコンバージョンを落としているのでは」「情報が多すぎて比較しづらいのでは」といった仮説です。
仮説があると、デザインの判断に筋が通ります。逆に仮説がないと、すべてが好みの議論になってしまいます。デザインを提案するときも、「こう見せたい」ではなく「この課題に対して、この打ち手が効くと考えた」と言えるようになるのです。
ステークホルダーが多い案件ほど、決定事項を文書化する
関係者が多い案件では、決定事項を記録するだけでかなり事故が減ります。議事録、要件メモ、Notion、FigJam、スプレッドシート、何でもいいです。大切なのは、今何が決まり、何が未決で、誰が確認するのかが見える状態にすることです。口頭だけで進めると、後から「聞いていない」が必ず出てきます。
4. 情報設計・ワイヤーフレームで迷いを減らす
いきなりビジュアルに入らない理由
情報設計が固まる前にビジュアルを作り始めると、議論が見た目に引っ張られます。色味や雰囲気の話は盛り上がりやすいですが、構造が曖昧なままでは、後で大きな手戻りになります。特にLPや情報量の多いページでは、先に何をどの順番で見せるかを決めるほうが先です。
そこでまずはワイヤーフレームの制作から入ることが重要になってきます。
ワイヤーフレームは地味ですが、そこで意思決定を進めるとデザインの差し戻しが減り、後の進行がスムーズになります。逆にここを飛ばしてしまうと、完成に近いデザインが差し戻されたときのダメージが大きくなってしまいます。
ワイヤーフレームで固めるべき論点
ワイヤーフレームで見るべきなのは、情報の優先順位、ボタンの位置、コンテンツ量、画面遷移、スクロールの流れです。LPなら、最初に何を伝え、どこで不安を解消し、どこで行動を促すか。SaaS管理画面なら、一覧性、絞り込み、詳細導線、エラー時の戻り先などが論点になります。
ここでおすすめなのは、ワイヤーフレームのレビューを「好き嫌い」でやらないことです。「その順番で理解しやすいか」「行動につながるか」「ユーザーが迷わないか」という目的適合の観点で見ると、議論が建設的になります。
レビューでは“好き嫌い”ではなく“目的適合”で判断する
レビューが噛み合わない原因の多くは、評価軸が共有されていないことです。ここでも初期の課題や要件の明文化が活きてきます。「これは誰向けで、何を達成するページか」が共有されていれば、「なんとなくこっちが好き」という感覚論に陥らず、有効なワイヤーフレーム制作に繋がってきます。
レビュー依頼を出すときは、「今回は導線の妥当性を見てほしい」「情報量のバランスを確認したい」と観点を添えると、戻りの質が上がるでしょう。
合意形成の粒度が甘いと後工程で手戻りになる
ワイヤーフレームで合意したつもりでも、何に合意したのかが曖昧だと危険です。配置なのか、情報量なのか、文言まで含むのか。ここが曖昧だと、デザイン後に「想像と違った」が起きます。次工程に進む前に、合意の範囲を明確にしておくべきです。
5. デザイン制作工程の進め方とチェックポイント
トーン＆マナー設計は最初に方向性を絞る
ビジュアル制作で最初にやりたいのは、方向性を広げることではなく、むしろ絞ることです。競合との差別化、ブランドらしさ、ユーザーに与えたい印象。ここを整理したうえで、参考の出し方やムードボードを作ると、レビューの解像度が上がります。
トンマナが曖昧なまま画面を量産すると、後で全部修正することになります。最初にキーとなる画面で方向性を握るのが効率的です。
UIデザインでは、画面単体ではなくシステムとして設計する
UIデザインで陥りやすいのが、1画面ごとにその場で整えてしまうことです。これをやると、画面単体ではきれいでも、全体で見ると一貫性が崩れます。なので、ボタン、フォーム、モーダル、カード、一覧、空状態、エラー表示といった共通パーツを明らかにして、最初からコンポーネントとして考えるべきです。
デザインシステムがある組織なら、それに沿う。ない組織でも、最低限のルールは決める。余白、タイポグラフィ、状態差分、トークンの考え方まで揃うと、後の実装と運用がかなり楽になります。
デザインレビューで見るべき観点
デザインレビューでは、つい細部に目がいきます。もちろん余白や整列も大事です。ただ、そればかりになると、もっと重要な論点を見落とします。見るべきは、可読性、操作性、一貫性、ブランドらしさ、そして実装可能性です。
特に実装可能性をしっかりと意識することで、後の開発工程で効いてきます。アニメーションやレイアウトが魅力的でも、開発工数に見合わないなら別案を考える必要があります。レビューでは、理想だけでなく着地まで含めて見る視点が必要なのです。
バリエーションを出すべき場面、出しすぎないほうがいい場面
バリエーション提案は有効ですが、ただやみくもに提案することがいいわけではありません。ファーストビューや全体トーンのように方向性を左右する部分では比較案が役立ちます。一方で、下層ページの細部や共通UIまで毎回複数案を出すと、かえって迷いが増えます。比較が効く場所と、基準案を固めたほうがいい場所とを分ける感覚が大切です。
6. 実装連携・引き継ぎでデザイン品質が落ちやすい
エンジニア連携は“渡す”ではなく“すり合わせる”工程
デザインが完成したあと、Figmaを共有して終わり、という進め方は危険です。実装フェーズでは、hover、active、disabled、エラーステート、レスポンシブ時の崩れ方など、画面だけでは読み取りにくい情報がたくさんあります。ここを詰めないと、実装後に「思っていたのと違う」という事態が起きてしまいます。
理想は、引き継ぎの場を設けて、重要な意図や優先順位を共有することです。どこが絶対に守りたいポイントか、どこは実装都合で調整可能かなど。この線引きがあるだけで、連携がかなりスムーズになります。
実装観点で先に詰めておくと楽になるポイント
実装で揉めやすいのは、ブレークポイント、画像の扱い、フォント、アニメーション、レスポンシブ、CMS化範囲です。特にレスポンシブは、PC版だけ精密でスマホが後回しになると危険です。案件によってはむしろスマホのほうが重要なケースも多いです。
また、更新が入るサイトなら、どこをCMSにするのか、誰が更新するのかまで考えておく必要があります。デザインは公開時点の見た目だけでなく、更新後に崩れにくいことも品質のひとつと捉えましょう。
Design QAで確認すべきこと
実装後のDesign QAでは、余白、行間、コンポーネント崩れ、画像比率、リンク挙動、hover、フォームエラー、端末差分を確認します。ここは単に見た目を責める場ではなく、意図が正しく実装に落ちたかを見る工程です。
QAが弱いと、せっかく設計した体験が細部で壊れます。公開前に数分触るだけでも、案外大きな差が見つかるものです。
7. 公開・納品で終わりにしない運用と改善
公開前チェックは“見た目”以外も多い
公開前は、デザインの再確認だけでなく、文言、リンク、OGP、フォーム動作、速度、ブラウザ差分まで見たいところです。デザイン案件でも、公開時の品質は総合点で決まります。どれだけ見た目が整っていても、リンク切れや送信エラーがあれば評価は下がってしまうのです。
公開後に見るべき指標と改善の考え方
公開して終わりではなく、その後に何を見るかも大事です。LPならCVRやスクロール率、ヒートマップ。サイトなら回遊や離脱。プロダクトなら操作完了率やエラー率。数字が見えると、次の改善が具体的になります。
たとえばCTA文言の変更、ファーストビューの整理、フォーム入力負荷の削減など、小さな改善でも効果が出ることがあります。公開後に改善できる前提で設計しておくと、案件の価値は長く続きます。
納品後の振り返りが次案件の進行精度を上げる
案件が終わったら、何が詰まり、何がうまくいったかを振り返ると、次の進行がかなり良くなります。ヒアリング項目、レビューの出し方、引き継ぎ資料、チェックリスト。再利用できるものはテンプレート化しておくと、チームのアジリティも上がります。
8. 案件をスムーズに進めるための実務TIPS
レビュー依頼の出し方で戻りの質が変わる
レビュー依頼を出すときに「ご確認お願いします」だけにとどめてしまうと、コメントが散りやすいです。何を見てほしいのか、今回はどこまで固めたいのかを添えるだけで、戻りの質が変わります。進行がうまい人は、デザインを出すだけでなく、レビューの観点まで設計しています。
スケジュールは余白込みで引く
スケジュールは理想通りには進みません。素材待ち、文言確定待ち、フィードバック遅れ、追加要件。どれも普通に起きます。だからこそ、最初から少し余白を見込んで引くべきです。余白がないスケジュールは、最初はきれいでも、すぐに壊れます。
テンプレート化できるものは早めに型化する
ヒアリングシート、レビュー依頼文、引き継ぎチェックリスト、納品フォーマット。こうしたものを型化しておくと、案件ごとの差は残しつつ、基礎の精度を保てます。型がある人ほど、汎用性が高く案件に対して柔軟に高品質な進行を実現できます。
9. 案件タイプ別に進め方はどう変わるか
LP制作案件の進め方
LP案件は、訴求整理とCTA設計が中心です。情報を増やすより、何を削って何を残すかの判断が重要になります。短期案件が多いので、初期整理の精度が特に効きます。
コーポレートサイト案件の進め方
コーポレートサイトは、ブランド一貫性と情報整理のバランスが鍵です。社内の関係者が多く、確認ポイントも増えやすいので、レビュー導線の設計が重要になります。
プロダクトUI改善案件の進め方
プロダクトUI改善は、仮説検証と既存制約の理解が重要です。見た目の刷新だけでなく、既存フローとの整合、開発優先度、運用への接続を見ながら、小さく改善を積み上げる進め方が合っています。
まとめ
デザイン案件は、センスだけで進む仕事ではありません。目的の整理、要件定義、ワイヤーでの合意形成、レビューの設計、実装連携、公開後の改善まで、一連の進行が揃ってはじめて良い成果物になります。逆に言えば、進行の質が悪いと、どれだけアウトプットの腕があっても苦しくなります。
良い進行を行ない、案件を成功に導くには、早く作ることより、早く前提をそろえることが重要なのです。誰向けで、何を達成したくて、どこが制約で、誰が決めるのか。ここが見えているだけで、案件の安定感はかなり変わります。
もし今、案件進行で毎回バタついているなら、デザイン工程そのものより、着手前の整理とレビューの設計を見直してみてください。そこが整うと、制作も実装連携も、驚くほどスムーズになります。
