「UI/UX を意識して実装して」とリーダーに言われたものの、具体的に何をすればいいのか分からない。レビューで「ここ UX 的に微妙」と指摘されても、なぜそう言われるのか腑に落ちない。デザイナーから渡された Figma を React で形にしているけれど、カンプに描かれていない部分の判断は結局いつも自分がしている——。フロントエンド実装に携わっていると、こうした「UI/UX の壁」にぶつかる場面は少なくありません。
UI/UX という言葉が難しいのは、「見た目の話」として片づけてしまうとデザイナーに丸投げするしかなくなり、かといって体系的に学ぼうとすると抽象的な概念論ばかりで「で、自分は実装で何を変えればいいの？」という疑問に答えてくれないからです。検索しても上位に出てくるのはデザイン会社や発注者向けの解説が多く、フロントエンドエンジニアが明日からコードに反映できる判断軸まで踏み込んだ記事は意外と見つかりません。
この記事では、UI と UX の違いを「実装でいう何に当たるか」に翻訳しながら整理し、そのうえでフロントエンドエンジニアが UI/UX にどう関わるべきかを具体化していきます。デザイナーに確認すべき範囲と自分の技術判断で決めてよい範囲の線引き、ローディングやエラー表示・アクセシビリティといった実装で UX を左右するポイントとハマりどころ、デザインシステムによる一貫性の保ち方、そして「UX 的に微妙」を主観で終わらせないための評価指標までを順に解説します。
読み終えたとき、UI と UX の違いを自分の言葉で説明でき、デザイナーと同じ言葉で議論でき、実装上の判断を技術的な根拠とともに自分で下せるようになっていることを目指します。
UI/UXとは？UIとUXの違いを実装者目線で整理する
UI/UX という言葉は「UI」と「UX」という別々の概念をまとめて呼んだものです。まずはこの2つを、フロントエンド実装で日々触れている具体物に紐づけて整理します。「モノ」と「コト」、「具体」と「抽象」という対比でよく説明されますが、実装者にとっては「自分が書いているコードのどの部分が UI で、どの部分が UX に効くのか」を押さえるほうが実用的です。
UIとは — 実装でいう「接点」の具体例
UI（User Interface）は、ユーザーとプロダクトが触れ合う「接点」のことです。直訳すると「ユーザーとの界面」で、ユーザーが見て、触って、操作する対象すべてが UI に含まれます。
フロントエンド実装でいえば、UI は次のような具体物に対応します。
- ボタン・リンク・入力フォームなどの操作部品
- テキストの大きさ・色・行間、アイコン、画像
- 要素同士の余白（マージン・パディング）やレイアウト
- ホバーやフォーカス時の見た目の変化
つまり、Figma のカンプに描かれている視覚要素を HTML/CSS で再現する作業の大部分は、UI を作る作業です。<button> のサイズ、ラベルの文言、配色のコントラスト、要素の配置——これらはすべて「ユーザーが直接触れる接点」であり、UI の構成要素です。UI は目に見える「モノ」であるため、比較的イメージしやすいはずです。
UXとは — 実装が左右する「体験」の具体例
UX（User Experience）は、ユーザーがプロダクトを利用する過程で得る「体験全体」のことです。UI のように目に見える「モノ」ではなく、「使ってみてどう感じたか」という体験＝「コト」を指します。
ここで重要なのは、UX は「見た目のきれいさ」だけで決まるわけではない、という点です。たとえば次のような場面は、いずれも UX の良し悪しに直結します。
- ボタンを押してから反応が返るまでが速いか、遅いか（体感速度）
- 入力を間違えたとき、何が原因でどう直せばいいかすぐ分かるか（エラー時の安心感）
- やりたいこと（購入・予約・送信など）を迷わず完了できるか（タスクの達成しやすさ）
- 通信が遅いときに「壊れた？」と不安にならず待てるか（待機中の納得感）
これらの多くは、見た目（UI）そのものではなく、実装の仕方で決まります。API のレスポンスを待つ間に何を表示するか、エラーをどう伝えるか、ローディング中に画面がガタつかないか——フロントエンドエンジニアが書くコードは、UI を作ると同時に、こうした UX を直接左右しているのです。「言われた通りカンプを再現しただけ」のつもりでも、実装の判断ひとつで体験は大きく変わります。
UIとUXの関係性 — なぜ「UIはUXの一部」なのか
UI と UX の関係を一言でいうと、「UI は UX を構成する要素のひとつ」です。優れた UI は良い UX に貢献しますが、UI が良ければ自動的に UX も良くなるわけではありません。
たとえば、ボタンのデザイン（UI）がどれほど洗練されていても、押した後に5秒間まったく反応がなければ「使いにくい」という体験（UX）になります。逆に、見た目は質素でも、操作が速く・迷わず・エラーから復帰しやすいプロダクトは「使いやすい」という良い UX を生みます。
この関係を実装者の視点で言い換えると、次のようになります。
- UI: ユーザーが触れる接点を作る（HTML 構造・スタイル・配置）
- UX: その接点を通じてユーザーが得る体験を設計する（状態遷移・フィードバック・パフォーマンス・エラー処理）
UI が UX の入り口である以上、フロントエンドエンジニアは「接点を作る人」であると同時に「体験を左右する人」でもあります。この2つを切り分けて考えられるようになると、後述するレビュー指摘の「UX 的に微妙」が、具体的にどの実装判断を指しているのかを読み解けるようになります。
なぜフロントエンドエンジニアがUI/UXを理解すべきか
「UI/UX はデザイナーの仕事で、自分はカンプを忠実に実装すればいい」と考えていると、見落とされがちな事実があります。それは、ユーザー体験を決める判断の多くが、実は実装段階で初めて発生し、その場で実装者が決めている、という事実です。
デザインカンプに描かれない判断は実装者が決めている
Figma のカンプは、多くの場合「正常系の一画面」を切り取った静止画です。しかし実際のプロダクトには、カンプに描かれていない無数の状態と分岐が存在します。
- データがまだ読み込まれていないとき、画面に何を表示するか
- データが0件のとき（空状態）、ユーザーに何を見せるか
- API がエラーを返したとき、どう伝えてどう復帰させるか
- 文字数が想定より多いとき、レイアウトが崩れないか
- 画面幅が狭いスマートフォンで、要素がどう折り返されるか
- ボタンを押した直後、処理中であることをどう示すか（二重送信の防止を含む）
これらはカンプに描かれていないことがほとんどで、実装者がその場で判断しています。そして、ここで挙げた項目はいずれも UX に直結します。つまり、フロントエンドエンジニアは意識するしないにかかわらず、日々 UX の意思決定を下しているのです。
ここに「UI/UX を理解すべき理由」の核心があります。設計意図を理解せずに判断すると、デザイナーが想定した体験とズレた実装になったり、エッジケースで使いにくい画面ができたりします。逆に、設計意図を理解していれば、カンプにない部分を「デザイナーならこう考えるはず」と補完でき、必要なら根拠を持って提案もできます。
「UI/UXエンジニア」という役割と橋渡しの価値
近年、「UI/UX エンジニア」という職種や、デザインと開発の橋渡しができるフロントエンドエンジニアへの需要が高まっています。求人で「UI/UX 理解のあるフロントエンド歓迎」といった表現を見かけるのも、この流れによるものです。
橋渡し役の価値は、デザイナーとエンジニアの間で起きがちな「分業の隙間」を埋めるところにあります。デザイナーは技術的な実現可能性まで把握しているとは限らず、エンジニアはデザインの意図まで汲み取れているとは限りません。この隙間に、エッジケースの考慮漏れ・実現困難なデザイン・体験を損なう実装が落ち込みます。
UI/UX を理解したフロントエンドエンジニアは、次のような形でこの隙間を埋められます。
- デザイナーの意図を汲んだうえで、カンプにない状態を矛盾なく実装する
- 技術的に無理のある表現を早期に指摘し、体験を保ったまま実現可能な代替案を出す
- アクセシビリティやパフォーマンスなど、デザインカンプには現れにくい品質を担保する
「言われた通り作るだけ」から「設計意図を理解して関与する」への転換は、プロダクトの品質を上げるだけでなく、エンジニア自身のキャリアの幅も広げます。次の章では、では具体的にどこまで自分で判断してよく、どこからデザイナーに確認すべきなのか、という線引きを整理します。
エンジニアが判断していい範囲とデザイナーに確認すべき範囲
UI/UX に関わると言っても、何でもかんでも自分で決めてよいわけではありません。重要なのは「技術判断として自分で決めてよいこと」と「設計意図に関わるため確認・提案すべきこと」の線引きです。この境界が分かっていれば、毎回「これは聞くべき？勝手に決めていい？」と迷わずに済みます。
実装者が技術判断として決めてよいこと
次のような領域は、見た目の体験を変えない範囲で実装者が技術判断として決めてよい部分です。デザイナーに逐一確認する必要は基本的にありません。
- HTML のセマンティクス・DOM 構造: 見出しに
<h1>〜<h6>を使う、ボタンには<button>、リンクには<a>を使う、リストは<ul>/<ol>で組む、といったマークアップの選択。見た目が同じでも、適切な要素を使うことはアクセシビリティと保守性に効きます。 - 状態管理・コンポーネント分割の設計: どこを再利用可能なコンポーネントにするか、状態をどこで持つか、といった実装内部の設計。
- 実装上の代替表現: カンプに描かれていない「処理中の表示」「ローディングの出し方」などを、デザインシステムの既存パターンに沿って選ぶこと。
- パフォーマンス起因の調整: 画像の遅延読み込み、不要な再レンダリングの抑制など、体験の見た目を変えずに速度を改善する調整。
見た目には現れないが体験には効く——この領域こそ、エンジニアが主体的に品質を上げられる場所です。たとえば、<div onClick> でボタンを作る代わりに <button> を使うだけで、キーボード操作やスクリーンリーダー対応が自動的に得られます。これはデザイナーに確認するまでもなく、実装者が責任を持つべき判断です。
デザイナー・UX設計に確認/提案すべきこと
一方、次のような領域は「体験そのものの設計」に関わるため、勝手に決めずデザイナーや UX 設計の担当者に確認・提案すべきです。
- 情報設計・画面の優先順位: 何を一番目立たせるか、どの情報を上に置くか。空状態やエラー状態で「何を見せるべきか」も、判断に迷えば確認します。
- 遷移フロー: 画面 A から画面 B への導線、エラー後にどこへ戻すか、といったユーザーの動線設計。
- トーン&マナー・文言: エラーメッセージやボタンラベルの言い回し。技術的に正しくても、ユーザーを不安にさせる文言は体験を損ないます。
- 想定外の状態での見せ方: カンプにない空状態・エラー状態のデザインは、「とりあえず実装」する前にデザイナーに一言相談すると、体験の一貫性が保てます。
ポイントは、「確認すべきこと」も丸投げで聞くのではなく、実装者として案を持って相談することです。「エラー時の表示がカンプにないのですが、こういう文言とレイアウトで考えています。問題ないですか？」という聞き方なら、橋渡し役として機能します。
早期に実現性を検証する（Feasibility Study）
線引きに加えて、実装者が能動的に仕掛けられる動きが「実現性の早期検証（Feasibility Study）」です。これは、デザインが固まりきる前の段階で「この表現は技術的に実現できるか」「パフォーマンスやアクセシビリティの面で問題はないか」を先回りして確認することです。
たとえば、複雑なアニメーションや凝ったインタラクションを含むデザインを見たら、実装が本格化する前に小さく試作して「実現可能か」「想定するデバイスで滑らかに動くか」を検証します。実装が進んでから「これは無理でした」となると手戻りが大きく、妥協した結果として体験が劣化しがちです。
早い段階で「ここは技術的に厳しいので、代わりにこういう表現はどうですか」と提案できれば、デザイナーも別案を検討する余地が残ります。実現性の検証を実装者から仕掛けることは、橋渡し役としてもっとも価値の出る動き方のひとつです。
実装でUXを左右する具体ポイントとハマりどころ
ここからは、フロントエンドエンジニアが明日から実装に反映できる具体的なポイントを扱います。いずれも「なぜ UX に効くのか」と「実装時のハマりどころ」をセットで押さえることが大切です。判断の根拠を持てれば、レビューで指摘される前に自分で品質を担保できるようになります。
ローディングと体感速度（スケルトンスクリーンの落とし穴）
データの読み込み中に何を表示するかは、体感速度を大きく左右します。真っ白な画面のまま待たせると「壊れた？」という不安を生みますが、読み込み中であることを伝えれば同じ待ち時間でも体感はずっと良くなります。
近年よく使われるのが、コンテンツの輪郭をグレーのプレースホルダーで先に見せる「スケルトンスクリーン」です。スピナー（くるくる回る表示）よりも「もうすぐ表示される」という予測を与えやすく、体感速度の改善に効果があります。
ただし、スケルトンスクリーンにはハマりどころがあります。
- 一瞬で消えるちらつき: データが速く返ってきた場合、スケルトンが一瞬だけ表示されてすぐ消えると、かえってチラついて見えます。表示する場合は最小表示時間を設けるか、一定時間（たとえば 200〜300ms）以内に応答が返るなら最初から出さない、といった制御を検討します。
- レイアウトシフト: スケルトンの形と実際のコンテンツの形が違うと、データ表示時に画面がガタッとずれます。これは後述する CLS（Cumulative Layout Shift）の悪化につながるため、スケルトンは実コンテンツとほぼ同じサイズ・形にするのが原則です。
- 使いどころの見極め: すべての読み込みにスケルトンが必要なわけではありません。短時間で終わる操作にはスピナーや控えめなインジケーターで十分なこともあります。
フォーム・エラー・入力フィードバック
フォームは、ユーザーがもっとも「使いにくさ」を感じやすい場所です。入力ミスやエラーへの対応がぞんざいだと、それだけで離脱につながります。
実装で UX を左右するポイントは次のとおりです。
- エラーは原因と直し方をセットで伝える: 「エラーが発生しました」だけでは、ユーザーは何をすればいいか分かりません。「メールアドレスの形式が正しくありません（例: name@example.com）」のように、何が・なぜ・どう直すかを伝えます。
- エラー表示の位置とタイミング: エラーメッセージは該当する入力欄の近くに表示します。また、入力中に逐一赤くするのか、送信時にまとめて検証するのかで体験が変わります。一般には、一度入力を終えた（フォーカスが外れた）タイミングで検証すると、入力途中で急かされる不快感を避けられます。
- 送信中の状態を示す: 送信ボタンを押した後、処理中であることを示し（ボタンを
disabledにする・ラベルを「送信中…」にするなど）、二重送信を防ぎます。これはユーザーの「押せたのか分からない」という不安の解消と、データ不整合の防止を同時に実現します。
アクセシビリティの観点では、エラーメッセージを入力欄と関連づける（aria-describedby で結びつける、エラー時に aria-invalid="true" を付与する）ことで、スクリーンリーダー利用者にもエラーが正しく伝わります。
状態の網羅（空・読み込み・エラー・成功）
実装でもっとも漏れやすいのが「状態の網羅」です。カンプには正常系（データがある状態）だけが描かれていることが多く、それ以外の状態は実装者が補わなければなりません。
最低限、次の4状態を意識すると抜け漏れが減ります。
- 読み込み中（loading）: データ取得中。スケルトンやインジケーターを表示。
- 空（empty）: データが0件。「まだ登録がありません」といった案内と、可能なら次のアクション（「新規作成する」ボタンなど）を示す。
- エラー（error）: 取得に失敗。原因の説明と再試行手段を提供する。
- 成功（success）: データが正常に表示された状態。
このうち「空状態」は特に見落とされがちで、データが0件のときに真っ白な画面が表示されてしまう、というのはよくある不具合です。空状態を丁寧に作り込むと、初めて使うユーザー（データがまだない状態）の体験が大きく改善します。実装に入る前に「この画面に存在しうる状態は何か」を洗い出す習慣をつけると、後からの手戻りを減らせます。
アクセシビリティはUXの一部（WAI-ARIA / WCAG）
アクセシビリティ（a11y）は「特別な配慮」ではなく、UX の一部です。キーボードしか使えないユーザー、スクリーンリーダーを使うユーザー、色の判別が難しいユーザーにとって、使えるかどうかは体験そのものを左右します。実装者が責任を持って担保できる、価値の高い領域です。
最低限押さえておきたいポイントは次のとおりです。
- セマンティックな HTML を使う: 操作要素には
<div>ではなく<button>や<a>を使います。これだけでキーボード操作・フォーカス・スクリーンリーダー読み上げが標準で備わります。WAI-ARIA（roleやaria-*属性）は、ネイティブ要素で表現できない場合の補完として使うものであり、「まずセマンティックな HTML、足りない部分を ARIA で補う」が原則です。 - キーボードだけで操作できる: マウスを使わず Tab キーだけですべての操作ができるか、フォーカスの当たっている要素が視覚的に分かるか（フォーカスリングを安易に消さない）を確認します。
- コントラスト比を確保する: 文字色と背景色のコントラスト比は、WCAG 2.1 のレベル AA で、通常サイズのテキストは 4.5:1 以上、大きいテキストは 3:1 以上が求められます（WCAG 2.1 達成基準 1.4.3、W3C/WAIC 日本語訳）。配色は UI（見た目）の話に見えて、判読できなければ体験を損なうため UX の問題です。
- タップターゲットの大きさ: スマートフォンでボタンが小さすぎると押し間違えが増えます。WCAG 2.2 ではレベル AA の達成基準 2.5.8「ターゲットのサイズ（最低限）」が新設され、ポインタ入力のターゲットは少なくとも 24×24 CSS ピクセルとされています（WCAG 2.2 達成基準 2.5.8、W3C/WAIC 日本語訳）。より大きい 44×44 CSS ピクセル以上はレベル AAA（達成基準 2.5.5）の基準です。AA 準拠を目指すなら 24px を下限としつつ、タッチ操作が中心の画面では 44px 程度を確保しておくと安心です。
WAI-ARIA や WCAG という言葉は難しく見えますが、その多くは「セマンティックな HTML を正しく使う」「キーボードで操作できる」「色だけに頼らない」といった基本の積み重ねです。これらはデザイナーに確認するまでもなく、実装者が主体的に担保できる UX 改善です。
デザインシステムとコンポーネントでUI/UXの一貫性を保つ
個々の画面で「ローディングはどうする」「エラーはどう出す」と毎回ゼロから悩むのは非効率ですし、判断がバラつくと UX も一貫しなくなります。これを仕組みで解決するのが「デザインシステム」と「コンポーネント化」です。
一貫性がUXを底上げする理由
UX において一貫性が重要なのは、ユーザーの学習コストを下げ、操作の予測可能性を高めるからです。同じ役割のボタンが画面ごとに色や形が違うと、ユーザーは「これは押せるのか」「さっきと同じ意味か」をその都度判断しなければなりません。逆に、どの画面でも同じパターンが使われていれば、一度覚えた操作を迷わず再利用できます。
実装者にとっても、一貫性はメリットになります。共通のパターンを部品化しておけば、新しい画面を作るたびに「この場合のローディングは…」と悩まずに済み、品質も自然と揃います。
デザインシステム/デザイントークンと実装の対応
デザインシステムは、色・余白・タイポグラフィ・コンポーネントなどのルールと部品をまとめた「共通言語」です。その最小単位が「デザイントークン」で、たとえば「プライマリカラー」「余白の刻み（4px / 8px / 16px…）」といった値を名前付きで定義します。
実装では、これらを CSS 変数やテーマ設定として持ち、各コンポーネントが直接の色コード（#3366ff など）ではなくトークン（--color-primary など）を参照するようにします。こうしておくと、デザイン側でトークンの値が変わっても、参照しているコンポーネントすべてに一括で反映でき、デザインと実装のズレも生じにくくなります。
Figma 側のコンポーネントと実装側のコンポーネントを1対1で対応づけられると、さらに連携がスムーズになります。「Figma のこのボタンコンポーネント＝実装のこの Button コンポーネント」という対応が取れていれば、デザイナーとエンジニアが同じ言葉で会話でき、認識のズレが減ります。
デザインと実装の乖離を防ぐ運用
デザインシステムを導入しても、運用を怠ると「Figma は更新されたのに実装が古いまま」「実装側で独自のボタンが増殖する」といった乖離が起きます。乖離を防ぐための実務的なポイントは次のとおりです。
- 新しいパターンは「まず共通部品に追加できないか」を考える: 画面固有の一回限りの実装を増やさず、再利用可能な部品として育てます。
- アクセシビリティ要件をコンポーネントに標準搭載する: 共通の
Buttonコンポーネントにフォーカススタイルや適切なマークアップを最初から組み込んでおけば、それを使うだけで品質が担保されます。各画面で個別に気をつけるより、部品に責任を持たせるほうが確実です。 - デザイン変更と実装変更の同期ルールを決める: トークンやコンポーネントが更新されたとき、誰がどう実装に反映するかを取り決めておきます。
個別画面の判断を「仕組み化」することで、毎回ゼロから悩む必要がなくなり、実装者はより本質的な体験設計に時間を使えるようになります。
UI/UXの良し悪しを数値で測る（評価指標）
「ここ UX 的に微妙」という指摘がピンとこないのは、評価が主観に閉じているからです。UI/UX には定量的に測る指標があり、共通の物差しを持てば、デザイナーやレビュアーと同じ言葉で議論でき、自分の実装改善の効果も客観的に示せます。
行動KPIと態度KPI
UX の評価指標は、大きく「行動 KPI」と「態度 KPI」に分けられます。
行動 KPI（ユーザーが実際にどう振る舞ったか）:
- タスク成功率: ユーザーが目的（購入・登録・送信など）を完了できた割合
- タスク処理時間: 目的を達成するまでにかかった時間
- ユーザーエラー率: 操作中にエラーや誤操作が起きた割合
- 離脱率・直帰率: 途中で離れてしまった割合
- CVR（コンバージョン率）: 最終的に成果（申込・購入など）に至った割合
態度 KPI（ユーザーがどう感じたか）:
- SUS（System Usability Scale）: 10項目のアンケートで使いやすさを 0〜100 のスコアで測る手法。一般に平均は 68 点とされ、これより高ければ平均以上、低ければ平均以下と判断する目安になります（SUS スコアの解説、UX PA Magazine）。
- NPS（Net Promoter Score）: 「他者に薦めたいか」を尋ねる推奨度の指標
- CSAT（顧客満足度）: 特定の体験に対する満足度
行動 KPI は「事実としてどうだったか」、態度 KPI は「ユーザーがどう感じたか」を捉えます。両者を併せて見ることで、「処理は速いのに満足度が低い（行動は良いが態度が悪い）」といった、片方だけでは気づけない問題も見えてきます。
実装者が関われる計測（Core Web Vitals・イベント計測）
これらの指標のうち、フロントエンドエンジニアが直接関われるのがパフォーマンス指標とイベント計測です。
Google が定める「Core Web Vitals」は、体験の質に関わる代表的なパフォーマンス指標で、次の3つで構成されます。
- LCP（Largest Contentful Paint）: メインコンテンツが表示されるまでの時間。2.5 秒以内が目安。
- INP（Interaction to Next Paint）: クリックやタップなどの操作に対する応答の速さ。200ms 以内が目安。2024 年 3 月に従来の FID（First Input Delay）を置き換える形で正式な指標になりました（Google が FID を INP に置き換え、海外SEO情報ブログ）。
- CLS（Cumulative Layout Shift）: 読み込み中に画面が予期せずずれる量。0.1 以下が目安。
これらは実装の工夫で改善できます。たとえば LCP は画像の最適化や読み込み順の調整、INP は重い処理の分割や不要な再レンダリングの抑制、CLS は画像・広告枠の領域をあらかじめ確保することで改善します。先に触れたスケルトンスクリーンのレイアウトシフトも、CLS の数値に直結します。
加えて、ボタンのクリックやフォーム送信といったユーザー操作をイベントとして計測すれば、「どこで離脱しているか」「どの操作でつまずいているか」がデータで見えてきます。こうした計測の仕込みは実装者の領域であり、データドリブンに改善を回す出発点になります。
「UX 的に微妙」を数値に翻訳できれば、「INP が 400ms あって操作の反応が遅い」「空状態でユーザーが次に進めず離脱している」といった具体的な改善対象に落とし込めます。
よくある質問（FAQ）
UI/UXとは結局どういう意味ですか？
UI（User Interface）はユーザーが触れる「接点」、UX（User Experience）はその接点を通じて得る「体験全体」を指します。一言でいえば、UI は「ボタンや画面などの見た目・操作部品」、UX は「使ってみてどう感じたか（速い・分かりやすい・迷わない、など）」です。UI は UX を構成する要素のひとつであり、UI が良くても応答が遅ければ UX は悪くなる、という関係にあります。
UIデザイナーとUXデザイナー、UI/UXエンジニアの違いは？
UI デザイナーは見た目・接点のデザイン（レイアウト・配色・コンポーネント）を主に担い、UX デザイナーは体験設計（情報設計・ユーザー調査・遷移フロー）を主に担います。UI/UX エンジニアは、これらのデザインを技術的に実装し、デザインと開発の橋渡しをする役割です。実装の立場から実現性の検証や体験の品質担保（アクセシビリティ・パフォーマンス）に関わる点が特徴です。
フロントエンドエンジニアはUI/UXデザイナーになれますか／兼務できますか？
実装で日々 UX の判断に関わっているフロントエンドエンジニアは、UI/UX への理解を深めやすい立場にあります。完全な分業の組織もあれば、小規模チームでは実装とデザインを兼ねる場合もあります。まずは「設計意図を理解して実装に反映する」橋渡し役から始め、情報設計やユーザー調査の知識を足していくと、デザインへの関与を段階的に広げられます。
UI/UXを意識した実装とは具体的に何をすればいいですか？
カンプにない状態（読み込み中・空・エラー・成功）を網羅すること、エラーを原因と直し方とセットで伝えること、送信中の状態を示して二重送信を防ぐこと、セマンティックな HTML とキーボード操作・コントラストといったアクセシビリティを担保すること、そして Core Web Vitals などのパフォーマンスに配慮することが、具体的な第一歩です。いずれも本記事の「実装でUXを左右する具体ポイントとハマりどころ」で解説しています。
UI/UXの勉強は何から始めればいいですか？
実装者であれば、まずは本記事で扱った「状態の網羅」「アクセシビリティの基本（セマンティックHTML・キーボード操作・コントラスト）」「Core Web Vitals」のように、自分のコードに直結する領域から始めるのが効果的です。そのうえで、UI と UX の違いや評価指標（SUS・行動KPI）を押さえ、デザイナーと共通言語で会話できるようにしていくと、関与できる範囲が自然と広がっていきます。
まとめ
UI（接点）と UX（体験全体）は別の概念であり、UI は UX を構成する一要素です。優れた UI が良い UX に貢献しても、応答の遅さやエラー処理の雑さがあれば体験は損なわれます。そして、その体験を左右する判断の多く——読み込み中の表示、空状態、エラーの伝え方、アクセシビリティ——は、カンプに描かれず実装段階で実装者が決めています。
だからこそ、フロントエンドエンジニアが UI/UX を理解する価値があります。技術判断として自分で決めてよい範囲と、デザイナーに確認・提案すべき範囲を切り分け、案を持って橋渡しできれば、「言われた通り作るだけ」から一歩抜け出せます。
明日からの一歩としては、まず「この画面に存在しうる状態（読み込み・空・エラー・成功）」を洗い出すこと、セマンティックな HTML とキーボード操作・コントラストでアクセシビリティを担保すること、そして「UX 的に微妙」を SUS や Core Web Vitals といった指標で語れるようにすることから始めてみてください。設計意図を理解し、技術的な根拠を持って関与できるようになれば、デザイナーと同じ言葉で議論できる頼れる実装者へと近づけるはずです。
