デザイナーとは（仕事・歴史・向いている人）

プロダクトデザイナーは、Web サービスやアプリなどの「プロダクト」の体験を作る職種です。画面の見た目を整えるだけでなく、誰の・どんな課題を・どう解くかから考え、作って確かめ、リリースした後の改善まで関わります。

会社によって範囲は大きく違います。小さなチームではリサーチからアイコン作りまで1人で担い、大きな組織では UX リサーチャーや UX ライターと分担します。求人では肩書きより仕事内容を確かめます。

デザインの職種は名前が多く、範囲も重なっています。大まかには、何を対象にするか（画面・体験・ブランド）と、どこまで担うか（見た目・検証・実装）で分けられます。

デザインエンジニアがチームにいると、Figma とコードの部品の対応がそろいやすくなり、アニメーションや操作感のように静止画では伝わりにくい部分を、実物で早く確かめられます。デザイナー全員がコードを書く必要はありませんが、「どこまでがコードで簡単に作れて、どこからが大変か」を知っておくと、誰と組んでも受け渡しのずれが減ります。

デザインの進め方には決まった型がいくつかありますが、よく使われるのが英国のデザイン・カウンシルが示したダブルダイヤモンドです。「正しい課題を見つける」段階と「正しい解き方を見つける」段階のそれぞれで、いったん広げてから絞ります。

実際には一方向に進むとは限らず、検証の結果で課題の段階に戻ることもあります。大事なのは、段階ごとに「何が分かったら次に進むか」をチームで共有しておくことです。

プロダクトデザイナーの時間は、手を動かしてデザインを作る時間と、チームと話して決める時間に大きく分かれます。開発の周期（スプリント。1〜2週間で区切って進めるやり方）に合わせて動くことが多いです。

1日の例としては、午前に集中してデザインを作り、午後にレビューや相談を入れる、という分け方がよくあります。相談や確認の時間が全体の半分近くになることも珍しくないので、エンジニアと話すための言葉（状態・コンポーネント・トークン・API など）を知っていると、その時間がぐっと短く・具体的になります。

肩書きも「Web デザイナー」→「UI/UX デザイナー」→「プロダクトデザイナー」と、担う範囲に合わせて変わってきました。どの時代も、新しい技術（GUI・Web・スマホ・AI）が出るたびに、その制約と可能性を知るデザイナーが求められてきた、という流れは同じです。

逆に「自分の好きな見た目を作り込みたい」気持ちが強すぎると、データや制約で案が変わることを負担に感じることがあります。プロダクトデザインは、チームで決めて、作って、確かめる仕事だと考えると、合うかどうかを判断しやすくなります。

プロダクトデザイナーのスキルは、手を動かすスキル・考えるスキル・チームで進めるスキルの3つに分けて考えると整理しやすいです。実装の知識は「チームで進めるスキル」の土台になります。

コードは必須ではありませんが、HTML・CSS を少し書いてみる、ブラウザの開発者ツールで余白や色を確かめる、くらいができると、実装との違いを自分で調べられるようになります。

どの道に進んでも、「実装の制約を知って、実現できる形で体験を守った経験」は強みになります。面接では、その経験を STAR（状況・課題・行動・結果）で話せるようにしておきます（第6部）。

特に毎日やりとりするのは PdM とエンジニアです。PdM とは「何を・なぜ」、エンジニアとは「どう作るか」を話し、デザイナーはその間で体験の形を決めます。3者が早い段階から同じ資料を見ていると、手戻りが大きく減ります。

デザインのデータ（Figma など）は、多くの場合「理想の1画面」です。ところが実際の画面は、通信が遅い・データが0件・名前がとても長い・スマホが横向き、といった条件で動きます。こうした条件をデザインで決めていないと、実装の途中でエンジニアが判断に迷い、その場の判断で作られるか、デザインを決め直すことになります。どちらも手戻りと、意図とずれた画面のもとになります。

技術を知っていると、こうした抜けに自分で気づけます。また、「この表現は標準の部品で作れるので早い」「これはデータの取り方から変える必要がある」と分かると、エンジニアとの相談も具体的になります。

このサイトの ★ は職種ごとに意味が少し違います。エンジニアの ★ は「自分で作れる・運用できる」ことが基準ですが、デザイナーの ★ は実装の制約を知り、それをデザインに反映できるかが基準です。

たとえば「ストリーミング表示」なら、エンジニアは通信の仕組みまで知る必要がありますが、デザイナーは「文字が少しずつ届く」「途中で止められる」ことを前提に画面を考えられれば十分です。