紙媒体のデザイン
チラシ、名刺、ポスター、パンフレット、書籍など。CMYK、300dpi、トンボ、塗り足し、入稿データの知識が重要。
01 / Why
デザイナー職を営業が知る意味
デザイナー案件は「Figmaが使える」「UI経験あり」だけでは提案精度が出ません。何を作った人か、どの工程を担った人か、誰と協業した人かを読めることが重要です。
営業が見るべき中心は、センスではなく再現性
デザイナーはビジュアルを通じて情報を伝わりやすくし、Webサイトやアプリを使いやすくする職種です。 SES営業に必要なのは、デザインの良し悪しを審査することではありません。 案件側が求める「成果物」「工程」「協業範囲」に対して、候補者の経験が再現できるかを確認することです。
営業向けポイント
「きれいな作品があります」では弱いです。「課題をどう捉え、Figmaで何を作り、実装側へどう渡し、結果どう改善したか」まで言えると提案が強くなります。
案件概要の言葉を分解
スキルシートの経験へ接続
面談で根拠を確認
提案コメントで補足
ポイント
デザイナー提案は「センスの評価」ではなく、案件概要の工程・成果物・協業範囲に候補者の経験を接続する仕事です。
02 / Overview
デザイナーの概要
元資料の分類を営業向けに見ると、DTP、Web、UI、UXは似ているようで案件適性が大きく違います。まず領域ごとの成果物を押さえます。
Webサイトの画面設計
サイトのビジュアル、レイアウト、レスポンシブ、バナー、LP、コーポレートサイトなど。HTML/CSSがあると提案幅が広い。
アプリやサービスの画面部品
ボタン、フォーム、ナビゲーション、コンポーネント、状態設計。Figma、オートレイアウト、デザインシステム経験が見られる。
体験全体の設計
調査、ペルソナ、カスタマージャーニー、プロトタイプ、ユーザビリティテスト、改善提案まで含む領域。
UIとUXの違いは、提案時のズレ防止に効く
| 観点 | UI | UX | 営業判断 |
|---|---|---|---|
| 対象 | 画面の見た目・操作部品 | サービス全体の体験 | UI案件にUXリサーチ専任を出す、または逆をしない |
| 成果物 | ワイヤー、モック、コンポーネント | 調査結果、仮説、導線設計、改善案 | ポートフォリオに成果物だけでなく設計理由があるかを見る |
| よくある言葉 | Figma、画面設計、デザインシステム | ユーザー調査、A/Bテスト、ペルソナ | 案件概要の言葉から求める深さを確認する |
まず押さえるポイント
DTP、Web、UI、UXは成果物が違います。「デザイナー経験あり」だけでまとめず、どの領域の経験かを分けて見ます。
03 / Role Names
職種名の違いを整理する
案件概要では似た肩書きが並びます。新人営業は、職種名だけで判断せず、主な役割・成果物・提案前の確認事項までセットで見ることが大切です。
デザイナー系職種の見分け方
| 職種名 | 主な役割 | 主な成果物 | ツール・キーワード | 提案前に確認すること |
|---|---|---|---|---|
| Webデザイナー | WebサイトやLPの見た目・レイアウトを設計する。 | LP、バナー、サイトデザイン、レスポンシブデザイン。 | Figma、Photoshop、Illustrator、HTML/CSS、SEO。 | フロントエンドエンジニアではありません。HTML/CSSは修正レベルか、実装まで可能かを分けて確認します。 |
| UIデザイナー | アプリやWebサービスの画面・操作部品を設計する。 | 画面デザイン、コンポーネント、状態設計、プロトタイプ。 | Figma、コンポーネント、オートレイアウト、デザインシステム。 | 画面作成だけか、導線・状態・実装ハンドオフまで担当したかを確認します。 |
| UXデザイナー | ユーザー体験全体を調査・設計・改善する。 | 調査結果、ペルソナ、ジャーニー、仮説、改善案、テスト結果。 | ユーザー調査、A/Bテスト、ユーザビリティテスト、プロトタイプ。 | UXデザイナーは見た目を作る人だけではありません。UI制作までできるか、調査・改善中心かを確認します。 |
| プロダクトデザイナー | 事業・ユーザー・開発をつなぎ、プロダクト全体の体験を設計する。 | 要件整理、UI、UX改善、ロードマップに沿った設計案。 | Figma、PdM連携、KPI、デザインシステム、仮説検証。 | PdMやエンジニアとどの程度意思決定に関わったかを確認します。 |
| グラフィックデザイナー | 広告・ブランド・ビジュアル表現を制作する。 | ロゴ、バナー、広告、SNS画像、キービジュアル。 | Illustrator、Photoshop、After Effects、ブランドガイドライン。 | Web/UI案件に出す場合は、画面設計やFigma経験があるかを確認します。 |
| DTPデザイナー | 紙媒体のレイアウトと印刷用データを制作する。 | チラシ、パンフレット、ポスター、入稿データ。 | Illustrator、InDesign、CMYK、300dpi、トンボ、塗り足し。 | 紙媒体中心か、Webやアプリ画面の経験もあるかを確認します。 |
| アートディレクター | ビジュアル方針を決め、制作物の品質を管理する。 | デザイン方針、レビュー結果、ブランド表現、制作指示。 | 品質管理、トーン&マナー、レビュー、クリエイティブ方針。 | 制作だけでなく判断・レビュー・品質管理を担ったかを確認します。 |
| Webディレクター | Web制作の進行・要件整理・関係者調整を担う。 | 要件整理、ワイヤー、進行表、課題管理、制作指示。 | 進行管理、ワイヤーフレーム、CMS、GA、Backlog、Notion。 | デザイン制作担当か、進行・顧客調整・品質管理寄りかを確認します。 |
ポイント
Webデザイナーはフロントエンドエンジニアではありません。UX、ディレクター、アートディレクターは「制作」より「調査・判断・進行・品質管理」寄りの場合があります。
04 / SES
SES案件での使われ方
デザイナー案件では、作る対象と参画工程で求められる人材が変わります。案件概要の「UI/UX」「Figma」「LP制作」だけで判断しないことが大切です。
新規サービス立ち上げ
情報設計、ワイヤー、プロトタイプ、UIデザイン、ユーザーテスト。UX寄りの経験が評価されやすい。
既存サービス改善
画面改修、CVR改善、導線改善、ABテスト、データを見たUI改善。改善理由を説明できる人が強い。
Webサイト・LP制作
バナー、LP、コーポレートサイト、レスポンシブ対応。HTML/CSSやSEO理解があると刺さりやすい。
デザインシステム運用
コンポーネント、トークン、ガイドライン、Figmaライブラリ整備。中級以上の見極めポイント。
Web/アプリ需要が高い
SES市場ではDTP単体より、WebやアプリのUI/UX案件の方が多く見られます。
Figmaはほぼ標準
Figmaの基本操作だけでなく、共同編集、コンポーネント、ハンドオフ経験まで確認します。
実装理解が差になる
HTML/CSS、レスポンシブ、画像最適化、GitHub運用を理解しているとエンジニア連携の根拠になります。
提案前に見るポイント
作る対象がLP、業務画面、スマホアプリ、デザインシステムのどれかで、必要な経験は変わります。案件概要の成果物から逆算します。
05 / Keywords
案件概要でよく見るキーワード
キーワードは「作業名」ではなく、求められる経験の深さを読む入口です。知らない言葉は候補者に確認する質問へ変換します。
UI/UX・設計
UI設計UXリサーチワイヤーフレームプロトタイプユーザビリティテストカスタマージャーニー
Figma・デザイン運用
FigmaコンポーネントオートレイアウトデザイントークンデザインシステムInspect
Web制作
LPレスポンシブHTML/CSSSEO画像最適化WebP/SVG
DTP・Adobe
IllustratorPhotoshopInDesignCMYK入稿バナー制作
案件概要の読み替え
「Figma必須」は基本操作だけか、コンポーネント設計までか。「UI/UX」は画面作成だけか、調査や改善提案までか。「HTML/CSS歓迎」は修正レベルか実装レベルかを確認します。
ポイント
キーワードは資格名ではなく確認の入口です。「Figma」「UI/UX」「HTML/CSS」は必ず担当範囲と深さを聞きます。
06 / Glossary
営業がわかればよい一言用語集
詳しい設計理論を暗記する必要はありません。案件概要・面談・提案で会話が止まらない程度に、言葉の意味を押さえます。
デザイントークン
色・余白・文字サイズなど、UIルールを再利用しやすく名前付きで管理したもの。
Inspect
Figma上でサイズ、色、余白などを実装者が確認できる機能。
ハンドオフ
デザイナーからエンジニアへ、実装に必要な情報を渡すこと。
コンポーネント
ボタンや入力欄など、繰り返し使うUI部品を共通化したもの。
オートレイアウト
Figmaで余白や並びを自動調整し、画面変更に強くする機能。
デザインシステム
UI部品、色、文字、使い方のルールをまとめ、画面の一貫性を保つ仕組み。
Human Interface Guidelines
Appleが出しているiOSアプリ向けのUI設計ルール。
Material Design
Googleが出しているAndroidやWeb向けのUI設計ルール。
CVR
購入、登録、問い合わせなど、目的行動に至った割合。改善案件でよく出ます。
A/Bテスト
複数案を比較して、どちらが成果につながるか検証する方法。
ワイヤーフレーム
色や装飾より前に、画面の構成と情報配置を示す設計図。
モック
完成イメージに近い静的な画面デザイン。
プロトタイプ
クリックや画面遷移を試せる試作品。動きや導線の確認に使います。
ユーザビリティテスト
ユーザーに実際に触ってもらい、迷う箇所や使いづらさを確認すること。
アクセシビリティ
年齢や障がいの有無に関わらず、誰でも使いやすくする考え方。
まず押さえるポイント
用語の定義を細かく語るより、「候補者がどこまで経験したか」を聞ける状態を目指します。
07 / Domains
代表的な案件領域
領域ごとに評価されるポートフォリオや経験が違います。候補者の作品を案件領域に合わせて見せる意識が必要です。
SaaS / 業務システム
情報量の多い画面、フォーム、一覧、管理画面。派手さより使いやすさ、状態設計、コンポーネント設計。
EC / メディア
商品導線、CVR改善、キャンペーンLP、バナー。数値改善やABテストの経験があると強い。
スマホアプリ
iOS/Android、Human Interface Guidelines、Material Design、タップ領域、画面遷移、エラー状態。
広告・クリエイティブ
バナー、LP、SNS画像、動画、After Effects。短納期制作やブランドトーン理解が見られる。
提案前に見るポイント
案件領域に近い作品があるかを最初に見ます。業務システム案件なら、派手な広告より一覧・フォーム・状態設計の経験が刺さります。
08 / Skill Sheet
スキルシートの読み方
デザイナーのスキルシートは、職務経歴だけでは足りません。ポートフォリオとセットで、担当範囲・成果物・意思決定・協業相手を読みます。
見る順番
作品数より、担当範囲とプロセスを見る
- 領域
- DTP、Web、アプリ、UI、UXのどこが主戦場か。
- 工程
- 調査、要件整理、ワイヤー、UI、実装連携、改善のどこを担当したか。
- ツール
- Figma、Illustrator、Photoshop、After Effects、Miro、Notion、Zeplinなど。
- 成果物
- LP、バナー、UIコンポーネント、プロトタイプ、ガイドライン、入稿データなど。
- 協業
- PM、ディレクター、エンジニア、PdM、マーケ、顧客との連携経験。
「UIデザイン」だけでは浅い
どの画面、何画面、どの状態、どのデバイス、どのコンポーネントを作ったかまで確認します。
「Figma使用」だけでは判断しない
閲覧・軽微修正・ワイヤー作成・コンポーネント設計・ライブラリ運用でレベルが違います。
ポートフォリオは案件に合わせる
業務システム案件に広告バナーだけ、アプリ案件に紙媒体だけでは伝わりにくいです。
書かれ方
FigmaでUI作成
弱い読み
Figmaが使える人
営業が聞くこと
ワイヤーからか、既存UI修正か。コンポーネントや状態設計まで担当したか。
提案の補足
「Figmaでの画面設計に加え、エンジニアへのハンドオフ経験があります」と根拠を添える。
ポイント
スキルシートは「職種名」より、領域・工程・成果物・協業相手を読みます。Figma経験は操作範囲まで確認します。
09 / Portfolio
ポートフォリオ確認チェックリスト
ポートフォリオは作品のきれいさを見る資料ではなく、案件に近い経験と提案コメントの根拠を拾う資料です。
案件に近い作品を探す
同じ領域、近い画面、近いユーザー、近い成果物があるかを見る。
担当範囲を見る
本人がどこを担当したか。チーム制作の場合は役割を必ず確認する。
プロセスを見る
課題、仮説、ワイヤー、UI、検証、改善のどこから関わったかを見る。
協業経験を見る
エンジニア、PM、PdM、ディレクター、顧客とどう進めたかを見る。
提案コメントの根拠を拾う
案件概要の不安を埋める一文にできる経験を探す。
提案前チェック
- 案件に近い作品があるか。
- 本人の担当範囲はどこか。
- どの工程から関わったか。
- 使用ツールは何か。
- デザインの意図や判断理由を説明できるか。
- エンジニア、PM、PdM、ディレクターとの協業経験があるか。
- 成果や改善結果を説明できるか。
- PC/SP、レスポンシブ、状態設計、アクセシビリティを意識しているか。
- UI/UX案件なら、調査・仮説・改善・テストの経験があるか。
NDAで公開できない場合の聞き方
NDAや守秘義務で作品を出せないケースはよくあります。公開作品が少ないだけで弱いと判断せず、担当範囲・成果物の種類・工程・協業相手・判断理由を抽象化して説明できるかを見ます。
公開できない案件でも問題ありません。差し支えない範囲で、どのようなサービスの、どの画面を、どの工程から担当されたか教えてください。
画面そのものを見せられない場合、担当した成果物の種類、関わった職種、判断理由、改善結果を抽象化して教えてください。
提案例: 非公開案件のため詳細提示はできませんが、SaaS管理画面のUI改善でフォーム・一覧・エラー状態の設計を担当しています。
ポイント
公開作品の多さだけで判断しません。非公開でも、担当範囲・工程・成果物・協業・判断理由を説明できれば提案材料になります。
10 / Interview
登録面談で聞くこと
面談では、作品の説明を聞くだけでなく、案件概要に出る言葉へ変換できる材料を集めます。質問は「何を作ったか」から「なぜそうしたか」へ深めます。
必ず聞く質問
- 直近で担当したデザイン領域はDTP、Web、アプリ、UI、UXのどれですか。
- Figmaでは何を作りましたか。ワイヤー、モック、プロトタイプ、コンポーネントのどこまでですか。
- デザインプロセスを、課題、アプローチ、成果の流れで説明できますか。
- エンジニアへのハンドオフで工夫したことは何ですか。
- レスポンシブやアクセシビリティを意識した経験はありますか。
- ポートフォリオで今回の案件に一番近い作品はどれですか。
深掘り質問
- デザインの決定をどう正当化しましたか。誰に説明しましたか。
- ユーザーリサーチやユーザビリティテストの経験はありますか。
- デザインシステムやコンポーネント運用で担当した範囲はどこですか。
- iOS/Androidのガイドラインを意識した経験はありますか。
- HTML/CSSは修正レベルですか、ゼロから実装できますか。
- 短納期や修正依頼が多い現場で、どう優先順位をつけましたか。
面談での言い方
「作品の見た目ではなく、案件提案で担当範囲を正確に伝えたいので、どの工程からどの工程まで担当されたか教えてください。」
面談での言い方
「Figma経験ありと記載がありますが、共同編集、コンポーネント、Inspectでのハンドオフのうち経験があるものを教えてください。」
面談でまず聞くポイント
「何を作ったか」だけで終わらせず、「どの工程から」「誰と」「なぜその判断をしたか」まで聞きます。
11 / Level
レベル感の見極め
経験年数より、任された範囲、判断の深さ、他職種との協業、ポートフォリオの説明力で見ます。
指示を受けて制作できる
FigmaやIllustratorの基本操作、バナー、簡単なLP、既存デザインの修正。提案先は制作補助や運用寄り。
確認ゼロから設計した経験か、既存ルールに沿った制作か。
画面設計を任せられる
UIデザイン、レスポンシブ、コンポーネント、エンジニア連携。SaaSやアプリ案件に提案しやすい。
確認状態設計、ハンドオフ、実装制約の理解があるか。
設計方針や改善をリードできる
デザインシステム、UXリサーチ、ユーザビリティテスト、改善提案、チームレビュー。要件整理から入れる。
確認意思決定の根拠、ステークホルダー調整、成果指標を語れるか。
この回答なら △ / ○ / ◎
| 質問 | 弱い回答 | 提案可能 | 強く推せる |
|---|---|---|---|
| Figmaで何ができますか | 画面を作れます。 | ワイヤー、モック、プロトタイプ作成、簡単なコンポーネント化ができます。 | オートレイアウト、コンポーネント、バリアント、Inspectでのハンドオフ、ライブラリ運用まで経験しています。 |
| デザインプロセスを教えてください | 要望を聞いてデザインしました。 | 課題整理、参考調査、ワイヤー、モック、レビュー、修正の流れで進めました。 | ユーザー課題と事業目的を整理し、仮説、プロトタイプ、テスト、改善まで回しました。 |
| エンジニア連携で工夫したことは | Figmaを共有しました。 | 余白、色、フォント、状態差分を整理し、実装前に認識合わせしました。 | コンポーネント仕様、レスポンシブ挙動、エラー状態、アクセシビリティ観点まで渡し、実装後レビューも行いました。 |
| レスポンシブ経験はありますか | スマホ版も作りました。 | PC/SPのブレイクポイントを意識してLPやサイトを作成しました。 | コンテンツ優先度、タップ領域、画像最適化、実装制約まで考慮して設計しました。 |
| UXリサーチ経験はありますか | ユーザー目線で考えました。 | インタビューやアンケート結果を見て改善案を出しました。 | 調査設計、ペルソナ、ジャーニー、ユーザビリティテスト、改善指標まで関与しました。 |
ポイント
年数だけでレベル判断しません。Figmaの深さ、判断理由、協業、改善経験を聞くとレベル差が見えます。
12 / Mismatch
営業がミスりやすい提案
デザイナーは肩書きが広いため、似た言葉を同じ意味で扱うとミスマッチになります。
| よくあるミス | なぜ危ないか | 提案前に確認すること |
|---|---|---|
| DTP中心の人をUI/UX案件へ提案する | 紙媒体とアプリ画面では成果物、制約、協業相手が違う。 | Figmaで画面設計した経験、レスポンシブや状態設計の経験。 |
| Figma経験ありだけで中級扱いする | 閲覧・軽微修正とコンポーネント設計ではレベルが違う。 | オートレイアウト、コンポーネント、ハンドオフ経験。 |
| ポートフォリオの見た目だけで推す | 案件側は再現性、プロセス、協業を見ている。 | 課題、アプローチ、成果、担当範囲を説明できるか。 |
| Webデザイナーをフロントエンド要員として出す | HTML/CSSが基礎レベルの場合、実装担当は難しい。 | 修正レベルか、レスポンシブ実装まで可能か。 |
| UXを「見た目が良い」と説明する | UXは調査、体験設計、改善の領域で、UIとは違う。 | リサーチ、テスト、改善指標への関与有無。 |
提案前に見るポイント
肩書きだけで提案しないこと。Web、UI、UX、DTP、ディレクターは似て見えて、求められる成果物と責任範囲が違います。
13 / Proposal
提案時の注意点とコメント例
提案コメントは「デザインできます」ではなく、案件概要の不安を埋める情報を短く添えます。
提案時の注意点
- 作品URLだけでなく、担当範囲と近い案件領域を添える。
- Figmaは操作範囲を具体化する。コンポーネント、ハンドオフ、プロトタイプなど。
- UI/UX案件では、調査・分析・改善経験の有無を曖昧にしない。
- HTML/CSSは「基礎理解」「修正可能」「実装可能」を分けて伝える。
- DTP経験は印刷知識として強みになるが、Web/アプリ適性は別途補足する。
提案コメントでまず入れること
案件に近い領域、担当工程、Figmaや協業の深さを短く補足します。「できます」ではなく「どこまで経験済みか」を書きます。
14 / Check
確認テスト
答えを開く前に、自分の言葉で説明できるか確認してください。
1. UIとUXの違いを営業向けに説明してください。
回答例: UIは画面の見た目や操作部品、UXはサービス全体の体験設計です。提案では画面作成だけか、調査や改善まで求めるかを確認します。
2. 「Figma必須」の案件で確認すべきことは何ですか。
回答例: 基本操作だけか、ワイヤー、モック、プロトタイプ、コンポーネント、オートレイアウト、ハンドオフまで必要かを確認します。
3. DTP経験者をWeb/UI案件に提案する前に何を確認しますか。
回答例: Web/アプリ画面設計、Figma、レスポンシブ、HTML/CSS理解、エンジニア連携、Web向けポートフォリオの有無を確認します。
4. ポートフォリオを見るときの重要観点は何ですか。
回答例: 作品数や見た目だけでなく、課題、アプローチ、成果、担当範囲、案件に近い領域の作品があるかを見ます。
5. 提案コメントで「デザインできます」だけでは弱い理由は何ですか。
回答例: 案件側は再現性を見たいからです。担当工程、使用ツール、成果物、協業経験、案件との近さを補足します。
6. HTML/CSS経験はどう分けて聞きますか。
回答例: 基礎理解、軽微修正、レスポンシブ実装、ゼロからのコーディングのどこまで可能かを確認します。
7. Webデザイナーとフロントエンドエンジニアの違いを説明してください。
回答例: Webデザイナーは主に見た目やレイアウトを設計する職種で、フロントエンドエンジニアはHTML/CSS/JavaScriptなどで画面を実装する職種です。候補者が実装までできるかは別途確認します。
8. ポートフォリオが非公開の場合、面談で何を確認しますか。
回答例: 公開可否ではなく、担当したサービス種別、画面、工程、成果物、協業相手、判断理由、改善結果を差し支えない範囲で確認します。
9. UXデザイナーをUI制作だけの案件に提案する前に確認すべきことは何ですか。
回答例: 調査や改善中心の経験だけでなく、Figmaでの画面作成、UI部品設計、ハンドオフ、実装側との連携経験があるかを確認します。
10. Figma経験ありの候補者を中級扱いする前に確認すべきことは何ですか。
回答例: 閲覧や軽微修正だけでなく、ワイヤー、モック、プロトタイプ、コンポーネント、オートレイアウト、Inspectでのハンドオフまで経験があるかを確認します。
確認テストで見るポイント
用語を暗記できたかより、案件概要・スキルシート・面談・提案のどこで確認するかを説明できれば合格です。
15 / Summary
まとめ
デザイナー提案は、見た目の評価ではなく、案件側が必要とする工程・成果物・協業に候補者の経験を接続する仕事です。
案件概要
領域、成果物、Figmaの深さ、HTML/CSS、UX範囲を分けて読む。
スキルシート
作品数ではなく、担当範囲、プロセス、協業、成果を読む。
登録面談
「何を作ったか」から「なぜそうしたか」「誰とどう進めたか」へ深掘る。
提案
案件概要の不安に対して、近い経験と根拠をコメントで補足する。
提案コメント例