エンジニアが知っておくべきUI/UXデザインの原則
DefinitionUI/UXデザインとは、見た目の美しさ（UI）だけでなく、ユーザーが目的を達成するまでの体験全体（UX）を設計し、使いやすさと満足度を最大化することです。
TL;DR (要約)
UI/UXはセンスではなく設計です。情報設計・一貫性・フィードバック・エラー設計を押さえると体験が改善します。特にフォームとエラー表示は、離脱と問い合わせを左右するため優先度が高い領域です。指標（離脱率/完了率/問い合わせ）で改善を回すと、属人的にならず継続できます。
この記事でわかること
- UIとUXの違い（何を改善するのか）について学べます
- 原則（情報設計・一貫性・フィードバック）について学べます
- フォーム/エラー設計の基本（離脱を減らす）について学べます
- アクセシビリティの最低限（B2Bでも重要）について学べます
- 指標と計測（何を見れば改善できるか）について学べます
- 改善の進め方（仮説→実装→検証）について学べます
- チェックリスト（レビューで使える）について学べます
UIとUXの違い（何を改善するのか）
「ボタンを青くする」のはUI（User Interface）改善ですが、「ユーザーが迷わずに購入完了できる」ようにするのはUX（User Experience）改善です。
エンジニアにとって重要なのは、「動くものを作る」だけでなく「使い続けられるものを作る」という視点です。どんなに高機能でも、使い方が分からなければその機能は存在しないのと同じだからです。
原則（情報設計・一貫性・フィードバック）
良いUIには共通する3つの原則があります。
デザインの心理学（3つの法則）
- ① ヒックの法則 (Hick's Law)
- 「選択肢が増えるほど、意思決定にかかる時間は対数的に増える」という法則。
→ 実践：メニュー項目を減らす、機能を断捨離する。 - ② フィッツの法則 (Fitts's Law)
- 「対象が大きく、近いほど素早く選択できる」という法則。
→ 実践：重要なボタン（購入など）は大きく、押しやすい場所に配置する。 - ③ ヤコブの法則 (Jakob's Law)
- 「ユーザーは他のサイトで慣れた操作性を好む」という法則。
→ 実践：俺流の独特なUIを作らず、GoogleやAppleなどの標準的なUIパターンを模倣する。
直感的なUIへの改善対比
| 要素 | Bad UI (エンジニア視点) | Good UI (ユーザー視点) |
|---|---|---|
| ボタン文言 | 「送信」「実行」「処理」 （システムが何をするか） |
「登録する」「メールを送る」「削除する」 （ユーザーが何をするか） |
| エラー表示 | 「エラーコード: 500」 （事実のみ） |
「サーバーとの通信に失敗しました。時間をおいて再試行してください」 （解決策を含む） |
| 空の状態 | 「データあありません」のみ （虚無） |
「まだデータがありません。新規作成ボタンから登録しましょう」 （ネクストアクション） |
- 情報設計 (Information Architecture)：
「関連するものは近くに置く」「重要なものは大きくする」というグルーピングのルール。画面を見た瞬間に「何ができる画面か」が伝わるかどうかが勝負です。 - 一貫性 (Consistency)：
「保存ボタンは常に右下」「キャンセルは常に左」といったルールを守ります。画面ごとに配置が違うと、ユーザーは毎回学習しなければならず、疲弊します。 - フィードバック (Feedback)：
「ボタンを押したらローディングが出る」「保存したらトースト通知が出る」など、システムがユーザーの操作を受け付けたことを必ず返します。無反応は「壊れている」と誤解されます。
フォーム/エラー設計の基本（離脱を減らす）
Webシステムでユーザーが最もストレスを感じるのが「入力フォーム」です。ここを改善するだけで、コンバージョン率や業務効率が劇的に向上します。
| 改善項目 | Bad UI (やりがち) | Good UI (改善案) |
|---|---|---|
| 入力項目数 | とりあえず全部聞く | 必須項目のみに絞る。任意項目は隠す。 |
| エラー表示 | 送信ボタンを押した後、画面上部にまとめて表示 | 入力しているその場でリアルタイムに表示（Inline Validation） |
| 入力形式 | 全角・半角を厳密に区別してエラーにする | システム側で自動変換して受け入れる（Postelの法則） |
| 必須マーク | 「※」のみ記述 | 「必須」「任意」を明記する |
実践：フォーム改善のBefore/After
Before (改善前)
住所入力で、郵便番号を入れた後に「住所検索ボタン」を押させる。
番地と建物名が別々の入力欄になっており、全角数字で入れると「半角で入力してください」と怒られる。
After (改善後)
郵便番号を入れた瞬間（7桁入力完了時）に自動で住所が補完される。
住所欄は1つに統合され、全角/半角どちらで入力してもシステムが裏側で自動変換して保存する（ユーザーに修正させない）。
アクセシビリティの最低限（B2Bでも重要）
アクセシビリティは「障害者対応」だけではありません。「屋外でスマホを見る営業担当（まぶしくて画面が見にくい）」「マウスが壊れてキーボードしか使えない状況」など、あらゆるシチュエーションでの使いやすさを保証します。
- コントラスト比：文字と背景のコントラストを
4.5:1以上確保する。 - キーボード操作：Tabキーだけで全ての入力欄とボタンに移動できるようにする。
- alt属性：画像には必ず説明を入れる。装飾用なら空文字
alt=""にする。
指標と計測（何を見れば改善できるか）
UI/UXは「なんとなく使いにくい」で終わらせず、数字で語りましょう。
- 離脱率 (Drop-off Rate)：フォームの入力途中で諦めたユーザーの割合。
- 完了率 (Completion Rate)：エラーなく一発で登録完了できた割合。
- 完了時間 (Time on Task)：入力開始から完了までの秒数。業務システムではこれが短いほど生産性が高いと言えます。
- KPI連携：UI改善をビジネス成果に繋げるKPI設計を参照し、単なる「使いやすさ」で終わらせず、売上やコスト削減（問い合わせ減）にどう寄与するかを定義します。
改善の進め方（仮説→実装→検証）
いきなりコードを書くのではなく、Figmaなどでプロトタイプを作り、実際の利用フローをシミュレーションします。
関係者（実際に使う人）に触ってもらい、「ここで迷った」「この言葉の意味が分からなかった」というフィードバックを貰うだけで、実装の手戻りを防げます。これを「ユーザビリティテスト」と呼びますが、たった3人に見せるだけで8割の問題は見つかると言われています。
チェックリスト（レビューで使える）
デザインレビューや実装完了時に確認すべきUIチェックリストです。
重要ポイント
チェックリスト
- □ ボタンやリンクが「クリックできそう」な見た目になっている
- □ 破壊的な操作（削除など）の前に確認ダイアログがある
- □ 処理待ちの間、スピナーやプログレスバーが表示されている
- □ エラーメッセージは「何が悪いか」だけでなく「どうすれば直るか」を伝えている
- □ 入力フォームのラベルと入力欄が紐付いている（`
- □ スマートフォンでタップしやすいサイズ（44px以上）になっている
- □ 色だけに頼った表現をしていない（色覚多様性への配慮）
- □ 専門用語が使われておらず、ユーザーの言葉で書かれている
- □ 戻るボタンやパンくずリストがあり、迷子にならない
- □ 成功時（完了画面）に「次に何をすべきか」が示されている
参考リンク / 出典
モダンで拡張性の高いシステム開発
Next.jsやクラウドネイティブ技術を活用し、ビジネスを加速させるシステムを構築します。
モダンなWeb開発の標準：Next.jsとヘッドレスCMSによる構築
このテーマの全体像を把握し、より体系的な理解を深めましょう。