Webデザインの流れ 仕事でのWeb制作案件の受注から納品までの手順

Web制作案件を受注したあと、すぐにデザインソフトを開いて作り始めるわけではありません。

最初に作業範囲と目的を確認し、ヒアリング、情報設計、デザイン、実装、検証、公開、納品の順に進めます。公開後の更新や改善まで担当する案件では、運用方法も制作前から決めておく必要があります。

本記事では、Web制作案件の受注内容が決まったあと、制作を開始してから公開・納品するまでの流れを順番に解説します。

デザインだけを受注する場合は、コーディングや公開を担当しないこともあります。それでも前後の工程を理解しておくと、クライアントや実装担当者との認識を合わせやすくなります。

Web制作案件の全体の流れ

Webサイトやホームページの制作工程を大きく分けると、制作前の設計、デザインと実装、公開と納品の3段階です。

実務では、以下の12工程に分けると作業と確認のタイミングが明確になります。

すべての案件で一人が12工程を担当するわけではありません。受注範囲によって、担当する工程と納品物は次のように変わります。

受注範囲	主に担当する工程	主な納品物
デザインのみ	要件確認、情報設計、ワイヤーフレーム、デザイン	デザインデータ、画像素材、実装用の仕様
実装まで	デザイン、コーディング、CMS構築、検証	ステージングサイト、ソースコード、CMS
制作全体	設計から公開、納品、運用引き継ぎまで	公開サイト、管理情報、操作資料、保守条件

デザインのみの案件でも、ページ数、修正回数、納期、素材の提供方法など、担当範囲に関わる確認は制作前に行います。

制作前に作業範囲と要件を決める

Web制作で手戻りが起きやすいのは、デザインの技術が不足しているときだけではありません。

何を、どこまで、誰が担当するのかが曖昧なまま制作を始めると、完成間際にページや機能が追加され、納期や費用にも影響します。

契約内容と作業範囲を確認する

受注が決まったら、見積書や契約書、提案内容を見直し、制作する範囲を具体化します。「ホームページ一式」のような表現だけでは、ページ数や機能、公開後の対応範囲を判断できません。

少なくとも、次の項目は制作を始める前に確認しておきます。

作業範囲を文書で共有しておけば、制作途中の要望が当初の範囲に含まれるのか、追加見積もりが必要なのかを互いに判断しやすくなります。

このあたりを曖昧にしたまま進めるとトラブルのもとでもあるので最初の段階でしっかり決めておく必要があります。

キックオフとヒアリングを行う

ヒアリングでは、クライアントが希望する見た目だけでなく、Webサイトを作る目的、現在の課題、利用者にしてほしい行動まで確認します。

一般的な確認項目を分類すると、次のようになります。

分類	確認する内容
事業と目的	事業内容、制作理由、現在の課題、達成したい成果
ユーザー	対象者、利用場面、悩み、求めている情報
コンテンツ	必要なページ、原稿、写真、動画、更新情報
デザイン	ブランド、参考サイト、避けたい表現、既存ルール
機能	フォーム、検索、予約、会員機能、外部連携
運用	更新担当者、更新頻度、権限、保守方法
制約	予算、納期、既存システム、社内規定、利用環境

参考サイトを挙げてもらう場合は、どこが良いのか、どこは避けたいのかまで聞きます。同じサイトを見ても、色を評価している人と、情報の少なさを評価している人では、求める方向が異なるためです。

ヒアリング内容は議事録や確認シートにまとめ、クライアントと制作側の認識をそろえてから次の工程へ進みます。

目的・ターゲット・KPIを整理する

ヒアリングで集めた情報をそのままページへ並べるのではなく、サイトの目的に合わせて優先順位を付けます。

整理するときは、次の3点を一続きで考えます。

問い合わせが目的なら、訪問数だけでなく、フォーム到達や送信を確認できる状態にします。採用サイトなら、募集要項の閲覧や応募を中心に考えるなど、目的によって見るべき成果も変わります。

情報を増やすほど伝わるわけではありません。重要度の低い説明を詰め込むと、読者が見るべき情報や次の行動が埋もれてしまいます。

原稿・画像・必要素材を準備する

サイト構成が決まっても、原稿や写真がそろっていなければデザインを確定できません。仮の文章や画像だけで進めると、実際の内容へ差し替えたときに文字量やレイアウトが大きく変わります。

制作前または各ページの着手前に、次の素材を集めます。

複数人から素材を受け取る場合は、最新版が分かるファイル名と保存場所を決めます。画像や文章を支給してもらう場合は、公開サイトで使用できる素材かどうかも確認します。

サイトマップとページ構成を決める

整理した情報をもとに、必要なページとページ同士の関係をサイトマップへ落とし込みます。

企業サイトなら、トップページから会社情報、サービス、実績、採用、問い合わせなどへ分岐する構造が一般的です。

リンク構造まで決めておくと、必要なページ、ナビゲーションに置く項目、各ページから案内する次の行動が明確になります。

階層を細かく分けすぎると目的のページへ到達しにくくなります。組織図をそのままWebサイトへ置き換えるのではなく、利用者が探す情報と行動の流れを基準に設計します。

ワイヤーフレームからデザインを作る

サイトの目的、ページ構成、素材が決まったら、各ページのレイアウトと見た目を作ります。いきなり装飾を作り込まず、情報の配置を決めてからデザインへ進むと修正範囲を抑えられます。

ワイヤーフレームを作成する

ワイヤーフレームは、トップページや下層ページの骨組みです。色や細かな装飾を決める前に、見出し、画像、文章、ボタンなどの配置と優先順位を確認します。

この段階では、次の点を中心に検討します。

ワイヤーフレームは手書きや簡単な作図ツールでも作成できます。重要なのは見栄えではなく、読者が内容を理解し、迷わず次の行動へ進める構造になっているかどうかです。

ワイヤーフレームでは、装飾よりも情報の優先順位とUI・UXを先に確認します。

デザイン方針を決める

各ページを作り込む前に、サイト全体で共通して使うデザイン方針を決めます。ページごとに色や余白、ボタンの形が変わると、同じサイトに見えにくく、実装や更新の負担も増えます。

最初に代表的なページや主要パーツで方向性を確認しておくと、全ページを作ったあとにサイト全体を修正する事態を防ぎやすくなります。

デザインカンプを作成する

デザインカンプは、実装後のWebサイトに近い完成イメージです。ワイヤーフレームへ色、書体、写真、装飾、UIパーツを反映し、見た目と情報の伝わり方を確認します。

制作にはFigmaなどのUIデザインツールを使うほか、写真の補正や合成にはPhotoshop、ロゴやアイコンなどのベクター素材にはIllustratorを組み合わせることもあります。使用するツールは、案件や制作チームの環境に合わせます。

見た目を整えるだけでなく、文字が読みやすいか、重要な情報が目に入るか、ボタンが他の要素と区別できるか、スマートフォンでも操作しやすいかを確認します。

レイアウトで迷ったときは、整列、余白、視線の流れなどの基本を確認すると、情報の優先順位をデザインへ反映しやすくなります。

プロトタイプで動きと導線を確認する

プロトタイプは、デザインカンプへ画面遷移やクリック時の動きを加えた確認用の試作品です。

メニューの開閉、モーダル表示、フォームの流れ、複数画面をまたぐ操作など、静止画だけでは伝わりにくい動きを共有できます。クライアント、デザイナー、実装担当者が同じ操作イメージを確認できるため、実装後の認識違いを減らせます。

すべての案件で詳細なプロトタイプが必要なわけではありません。ページ遷移や操作が単純なサイトでは主要画面だけを確認し、動きが重要なサイトやアプリでは確認範囲を広げます。

デザイン承認後に実装へ進む

デザインカンプと必要なプロトタイプが完成したら、クライアントの確認を受けます。文章、画像、色、レイアウト、主要な動きについて、どこまで承認済みなのかを明確にします。

実装へ進んだあとに構成やデザインを大きく変えると、デザインとコードの両方を修正する必要があります。承認時点のデータと修正内容を残し、追加変更の扱いも共有しておきます。

コーディングと公開前検証を行う

デザインが確定したら、ブラウザで表示・操作できるWebサイトへ実装します。実装後は、公開前の環境で表示や機能を確認し、クライアントの最終確認を受けます。

コーディング・CMS構築を行う

デザインカンプをもとに、HTML、CSS、JavaScriptなどで画面と動きを実装します。WordPressなどのCMSを使う場合は、クライアントが更新する投稿や固定ページ、入力項目、権限も設定します。

案件によっては、ノーコード・ローコードツール、ECや予約の外部サービス、JavaScriptフレームワークなどを利用します。デザイン担当と実装担当が分かれている場合は、画像の書き出し、文字サイズ、余白、動作、レスポンシブ時の変化を引き渡します。

デザイナー自身がコードを書かない場合でも、画面幅による変化や実装しやすいUIの考え方を理解しておくと、見た目だけでは再現できないデザインを避けやすくなります。

ステージング環境で表示と機能を確認する

公開前は、一般の利用者から見えないステージング環境やテスト環境で検証します。制作したPCだけで正常に見えていても、別のブラウザやスマートフォンでは表示が崩れることがあります。

確認する環境と項目は案件ごとに決めますが、一般的には次の範囲を確認します。

古い社内システムなどで特定環境への対応が必要な場合は、通常の検証対象へ曖昧に加えるのではなく、対象OSやブラウザ、対応範囲を契約時に指定します。

クライアントの最終確認を受ける

制作側の検証後、クライアントにもステージングサイトを確認してもらいます。見た目だけでなく、掲載内容、問い合わせ先、フォーム、外部リンク、利用規約など、事業側でしか判断できない部分を確認します。

修正依頼はページや箇所が分かる形でまとめ、対応後に再確認します。公開可能という承認を記録してから、公開準備へ進みます。

Webサイトを公開して納品する

公開作業では、完成したデータを本番環境へ移すだけでなく、ドメイン、SSL、リダイレクト、計測、バックアップなどを確認します。公開後には本番環境で再検証し、運用に必要なデータや権限を引き渡します。

公開前の準備をする

公開日時を決めたら、本番環境と関係者の作業を整理します。既存サイトを差し替える場合は、問題が起きたときに元へ戻せる準備も必要です。

デザインのみを納品する案件では、公開準備の代わりに、デザインデータ、画像、書き出し仕様、動作指示を実装担当者へ引き渡します。

Webサイトを公開する

本番サーバーへファイルやデータを反映し、必要に応じてドメインやDNSを切り替えます。CMSを使用する場合は、本番環境の設定、ユーザー権限、メール送信、キャッシュなども確認します。

公開作業はアクセスの少ない時間に行えばよいとは限りません。担当者が確認できる時間、障害時に復旧できる体制、外部サービスの反映時間などを考えて日時を決めます。

公開後の実環境を確認する

ステージング環境で問題がなくても、ドメイン、サーバー、キャッシュ、外部サービスが変わると本番環境だけで問題が起きることがあります。

公開後は、主要ページの表示、フォーム送信、メール受信、SSL、リダイレクト、計測、OGP、サイトマップ、noindexの解除を確認します。スマートフォンや別回線からもアクセスし、制作環境のログイン状態やキャッシュに依存していないかを見ます。

データと運用方法を引き渡す

公開が完了したら、契約で定めたデータ、アカウント、操作方法をクライアントへ引き渡します。

クライアントが自社で更新する場合は、実際の管理画面を使って操作方法を説明します。制作側が保守を続ける場合も、何を月額費用に含めるのか、追加費用になる作業は何かを明確にします。

公開後は運用・改善を行う

Webサイトは公開した時点で完成ではありません。情報を更新し、利用状況を確認しながら、目的を達成できる状態へ改善していきます。

GA4とSearch Consoleで成果を確認する

公開後の改善では、感覚だけでデザインを変えず、アクセス状況とユーザーの行動を確認します。目的に応じて、見る指標と計測方法を公開前に用意しておきます。

ツール	主に確認できること
Google Analytics 4（GA4）	流入元、閲覧ページ、エンゲージメント、キーイベント
Google Search Console	検索クエリ、表示回数、クリック、掲載順位、インデックス
Google Tag Manager	GA4や広告などの計測タグと発火条件の管理

問い合わせを増やすサイトなら、アクセス数だけでなく、フォーム到達、入力開始、送信完了なども確認します。検索流入を増やす場合は、どの検索語で表示され、どのページが入口になっているかを見ます。

データとユーザー反応から改善する

データから問題が見つかったら、原因の仮説を立てて改善します。離脱が多いからボタンの色を変えるのではなく、必要な情報が不足していないか、次の行動が分かるか、フォームの負担が大きくないかを確認します。

改善対象には、文章、ページ構成、ナビゲーション、フォーム、表示速度、内部リンク、CTAなどがあります。A/Bテストを行う場合は、比較したい要素と評価指標を先に決め、同時に複数箇所を変えすぎないようにします。

更新・保守の範囲を決める

Webサイトを安定して使い続けるには、コンテンツの更新だけでなく、システムと契約の管理も必要です。

誰が、どの頻度で、どこまで対応するのかを制作前のヒアリングで確認し、納品時にも最新の運用体制を共有します。ドメインやサーバーの更新担当が不明なままだと、サイト自体が表示できなくなる原因になります。

工程ごとの成果物を確認する

各工程で何を確定し、次の担当者へ何を渡すのかを決めておくと、作業の抜けや認識違いを防げます。代表的な成果物は次のとおりです。

工程	主な成果物・確認結果
1. 契約・範囲確認	見積書、契約書、対象ページ、仕様範囲
2. ヒアリング	議事録、ヒアリングシート、参考資料
3. 目的整理	目的、ターゲット、KPI、主要な行動
4. 素材準備	原稿、写真、ロゴ、掲載情報、権利確認
5. 情報設計	サイトマップ、ページ一覧、導線
6. ワイヤーフレーム	各ページの構成案、要素、優先順位
7. デザイン	デザインカンプ、共通スタイル、画像素材
8. プロトタイプ	画面遷移、操作、動き、承認結果
9. 実装	ステージングサイト、CMS、ソースコード
10. 検証	テスト結果、修正一覧、公開承認
11. 公開	本番サイト、公開後の確認結果、バックアップ
12. 納品・運用	データ、アカウント、操作資料、保守条件

Webデザインは制作前後の工程まで理解すると進めやすい

Web制作には、デザイン以外にも契約内容の確認、ヒアリング、情報設計、素材準備、実装、検証、公開、納品、運用があります。

分業する案件では、すべての工程を一人で実行する必要はありません。ただし、自分の前後で何が確定し、誰へ何を渡すのかを理解していると、手戻りや認識違いを減らせます。

まずは受注範囲を明確にし、各工程で確認と承認を取りながら進めてください。公開後の運用まで担当する場合は、計測、更新、保守の方法も制作前から設計しておきましょう。