「学習でデザインは作れるようになったけれど、実務ではどんな順番で仕事が進むのかイメージできない」という声はよく聞かれます。実際、制作会社に入って最初に戸惑うのは、デザインを作る時間よりも、その前後の工程のほうが長いという事実です。
Webデザインの実務では、デザインを作る作業は工程全体の一部にすぎず、要件整理・設計・確認・修正・公開準備といった前後の工程が大きな比重を占めます。この構造を知っておくと、学習の優先順位も変わってきます。
この記事では、Webデザインの実務の流れを、案件の相談を受けてから公開後の運用までの8つの工程に分けて解説します。それぞれの工程で何を作り、誰と何を確認するのかまで踏み込んで整理しました。

Webデザインの実務の流れ【全体像】
まずは一覧で全体を把握しておきましょう。案件の規模によって前後しますが、コーポレートサイトの新規制作であれば、おおむね次のような流れになります。
| 工程 | 主な作業 | 成果物 |
|---|---|---|
| 1. ヒアリング | 目的・課題・条件の確認 | ヒアリングシート・議事録 |
| 2. 要件定義 | ページ数・機能・スケジュールの確定 | 要件定義書・見積書 |
| 3. 設計 | サイトマップとワイヤーフレームの作成 | サイトマップ・ワイヤーフレーム |
| 4. デザイン | デザインカンプの制作 | デザインデータ(Figmaなど) |
| 5. 実装 | コーディング・CMS組み込み | HTML/CSS/CMSテーマ |
| 6. テスト | 表示確認・動作確認・原稿校正 | テスト結果一覧 |
| 7. 公開 | 本番環境への反映 | 公開済みサイト |
| 8. 運用 | 更新・解析・改善 | 解析レポート・改善案 |
工程1:ヒアリング
案件の出発点です。クライアントが「サイトをリニューアルしたい」と言ってきたとき、その言葉の裏には別の課題が隠れていることがよくあります。
確認すべきなのは、見た目の希望ではなく「このサイトで何を達成したいのか」という目的です。問い合わせを増やしたいのか、採用応募を集めたいのか、既存顧客への説明資料として使いたいのかで、作るべきものは大きく変わります。
- サイトの目的とゴール(数値で言えるとなお良い)
- ターゲットとなるユーザー像
- 現状の課題と、社内で挙がっている不満
- 参考にしたいサイトと、その理由
- 予算・公開希望日・原稿や写真の準備状況
工程2:要件定義と見積もり
ヒアリング内容をもとに、作るものの範囲を文章で確定させます。ここを曖昧にしたまま進めると、後から「これも入ると思っていた」という認識のズレが発生し、無償対応が膨らみます。
ページ数、対応するブラウザ、スマートフォン対応の範囲、原稿と写真の用意はどちらが行うか、修正は何回まで含むか。こうした条件を書面にして合意を取っておくことが、実務では欠かせません。
「デザイン修正は2回まで、それ以降は別途費用」といった条件は、冷たく感じるかもしれませんが、双方を守るためのものです。回数が決まっていると、クライアント側も指摘をまとめて出してくれるようになります。
ヒアリングや見積もりの進め方は、Webデザインの仕事の流れを解説した本でも具体例と一緒に紹介されています。実務に入る前に目を通しておくと、全体像がつかみやすくなります。
工程3:サイト設計(サイトマップとワイヤーフレーム)
サイトマップ
どんなページを何階層で作るかを図にまとめます。ページ数が確定するため、見積もりの根拠にもなります。
ワイヤーフレーム
各ページに何をどの順番で置くかを、色や装飾なしで組み立てた設計図です。この段階で情報の並び順を合意しておくと、デザイン工程での大きな作り直しを防げます。
実務では、ワイヤーフレームの確認を飛ばしていきなりデザインを見せると、「そもそもこの構成でいいのか」という議論がデザイン確認の場で始まってしまいます。工程を分ける意味はここにあります。

工程4:デザインカンプの制作
ワイヤーフレームに、配色・写真・書体・装飾を乗せて、実際の見え方を作ります。現在の実務ではFigmaが広く使われており、クライアントにURLを共有してブラウザ上で確認してもらう進め方が一般的です。
デザインカンプは、PC版とスマートフォン版の両方を用意するのが基本です。PC版だけ作ってスマートフォン版を実装時に考えるという進め方は、実装者との認識のずれを生みやすいので避けたいところです。
提出時には、意図を添えて説明します。「業種の信頼感を出すために彩度を抑えた」「問い合わせボタンは他の要素と色相を離して目立たせた」といった説明があると、感覚のぶつかり合いになりにくくなります。
工程5:実装(コーディングとCMS組み込み)
確定したデザインをHTML・CSS・JavaScriptで組み立てます。デザイナーが自分で実装する場合もあれば、コーダーやフロントエンドエンジニアに引き継ぐ場合もあります。
引き継ぐ場合は、フォントサイズ、余白の数値、ホバー時の挙動、可変時の折り返し方などを明記しておくと、確認の往復が減ります。仕様の正確な情報はMDN Web Docsを参照すると間違いが起きにくくなります。
更新を自社で行いたいという要望がある場合は、WordPressなどのCMSに組み込みます。どこを更新できるようにするかを事前に決めておかないと、公開後に「ここも直せると思っていた」という要望が出てきます。
CMSへの組み込みを担当する場合は、WordPressの仕組みを扱った入門書を1冊通しておくと、更新範囲の設計を考えやすくなります。
工程6:テストと校正
公開前の確認工程です。ここを丁寧にやるかどうかで、公開後のトラブルの数が変わります。
- 主要なブラウザでの表示確認
- スマートフォン・タブレットの実機での確認
- リンク切れ・フォーム送信の動作確認
- 原稿の誤字脱字、会社情報や電話番号の校正
- 文字と背景のコントラストなど、閲覧しやすさの確認
アクセシビリティの観点は見落とされがちですが、公共性の高いサイトでは要件に入ることもあります。考え方はウェブアクセシビリティ基盤委員会(WAIC)のサイトで公開されています。
電話番号・住所・料金・営業時間といった情報の誤りは、公開後に実害が出ます。制作側だけでなく、クライアント側にも最終確認をしてもらい、確認した記録を残しておきましょう。
工程7:公開
本番環境へ反映します。既存サイトのリニューアルであれば、URLが変わるページの転送設定、旧サイトのデータのバックアップ、公開直後の表示確認までがセットです。
公開作業は、アクセスが少ない時間帯に行うのが一般的です。公開してすぐに全ページを一通り確認するところまでが公開作業だと考えておくと、抜けが減ります。
工程8:運用と改善
Webサイトは公開してからが本番です。アクセス解析で閲覧状況を確認し、離脱の多いページや、想定より読まれていないコンテンツを見つけて改善していきます。計測にはGoogleアナリティクスのようなツールが使われます。
運用フェーズでは、更新作業の担当範囲も決めておきます。月額の保守契約を結ぶ場合は、対応する範囲と回数を明記しておくとトラブルを避けられます。

実務でつまずきやすいポイント
原稿と写真が集まらない
制作が止まる原因として非常に多いのがこれです。クライアント側が本業の合間に原稿を用意することになるため、想定より時間がかかります。着手時に「いつまでに何を用意してもらうか」を一覧にして渡しておくと、進行が安定します。
決裁者が途中から登場する
担当者と合意して進めていたのに、最終確認で上位者から根本的な指摘が入るというパターンです。着手時に「最終的に誰が判断するのか」を確認しておきましょう。
修正依頼が小出しに届く
1件ずつメールで届くと、対応漏れと確認コストが増えます。修正依頼は一覧にまとめて送ってもらう形式を最初に提案しておくと、双方が楽になります。
実務の流れの中で、デザイナーが関わる場面
8つの工程すべてにデザイナーが同じ濃度で関わるわけではありません。どの工程にどれくらい関与するかは、会社の体制や案件の規模で変わります。
| 工程 | 制作会社(分業体制) | 少人数・個人受注 |
|---|---|---|
| ヒアリング | ディレクターが主導、同席することもある | デザイナーが直接実施 |
| 要件定義 | ディレクターが作成 | デザイナーが作成 |
| 設計 | ディレクターまたはデザイナー | デザイナーが作成 |
| デザイン | デザイナーが主担当 | デザイナーが主担当 |
| 実装 | コーダー・エンジニアが担当 | デザイナーが実装まで担当 |
| テスト | 担当者が分担して実施 | デザイナーが全部確認 |
分業体制の会社ではデザインに集中できる一方、上流の判断に関われる機会は減ります。逆に少人数の環境では負荷が大きくなるものの、案件全体を見渡す力が早く身につきます。どちらが良いかは、身につけたいスキルによって変わります。
未経験から入る場合、最初はテストや修正対応といった下流の工程から任されることが多く見られます。ここを「雑務」と捉えるか「工程を覚える機会」と捉えるかで、その後の伸び方が変わってきます。修正指示の内容を記録しておくと、次の案件で同じ指摘を受けない設計ができるようになります。

制作環境として用意しておきたいもの
実務では確認作業の量が学習時とは比べものになりません。環境が整っていないと、確認のたびに手が止まります。
- 27インチのWQHDモニター:デザインデータとブラウザを並べて確認でき、実装チェックの効率が上がります
- 動作確認用のスマートフォン(AndroidとiOSの2台):実機での表示確認は実務では欠かせません
- モニターアーム:長時間の確認作業でも姿勢を保ちやすくなります
- 外付けSSD:案件データのバックアップ用に使われます
- A4サイズのファイルボックス:案件ごとの資料や校正紙をまとめておくと、確認のたびに探さずに済みます
よくある質問
Q. 1つの案件はどのくらいの期間がかかりますか?
規模によって大きく変わります。数ページのサイトなら1か月前後、ページ数の多いコーポレートサイトでは数か月かかることもあります。原稿の準備状況によって、同じ規模でも期間は変動します。
Q. デザイナーもコーディングまで担当しますか?
会社によって異なります。分業が進んでいる制作会社ではデザイン専任のこともありますし、少人数の会社では実装まで一人で担当することもあります。求人票の業務範囲を確認してください。
Q. 実務の流れを学習中に体験する方法はありますか?
架空案件を、ヒアリングシートの作成から始めてみるのが有効です。自分でクライアント役の条件を書き、要件定義、ワイヤーフレーム、デザイン、実装まで通してやると、工程の意味が体感できます。
Q. ディレクターがいない案件では誰が進行しますか?
小規模な案件や個人での受注では、デザイナーが進行管理も兼ねることが一般的です。スケジュール管理やクライアントとの調整も業務のうちだと考えておきましょう。
Q. 工程を飛ばして早く作ることはできますか?
スケジュールが厳しい案件では、工程を圧縮することもあります。ただしワイヤーフレームの合意を飛ばすと、デザイン段階での作り直しが発生しやすく、結果的に時間が伸びる傾向があります。
まとめ
Webデザインの実務は、ヒアリング、要件定義、設計、デザイン、実装、テスト、公開、運用という8つの工程で進みます。デザインを作る作業はそのうちの一部にすぎず、前後の確認と合意形成が全体の進みやすさを決めています。
実務でつまずきやすいのは、原稿が集まらない、決裁者が後から出てくる、修正依頼が小出しに届くという3点です。いずれも着手時のひと手間で防げるものばかりです。工程の意味を理解して、順番を守って進めていきましょう。



