UI/UX デザインの基礎

「デザインはデザイナーの仕事です」——半分は正しく、半分は間違いです。

実際には、エンジニアが毎日デザインの判断をしています。

□ エラーが起きた時、画面に何と出すか
□ 読み込み中に何を見せるか
□ データが0件の時、真っ白な画面でいいのか
□ ボタンを押した後、押せたことがどう伝わるか
□ この確認ダイアログは本当に必要か

デザインカンプに描かれているのは「うまくいった時」だけです。 それ以外の状態は、たいていエンジニアが決めています。

この章のゴールは、デザイナーになることではありません。 「なんか使いにくい」を言語化でき、デザイナーと同じ言葉で話せるようになることです。

UI と UX は別のもの

混同されがちですが、指しているものが違います。

UI は UX の一部です。そして——

見た目が美しくても、UX が最悪なことはあります。

美しいが最悪な例:
  □ 送信ボタンが洗練されているが、押した後に何も起きたように見えない
  □ 配色は綺麗だが、エラーの理由が書かれていない
  □ アニメーションが滑らかだが、1操作ごとに0.5秒待たされる

表示に3秒かかる美しい画面  <  0.3秒で出る素っ気ない画面

使いやすさは、好みではない

「使いやすい」は主観的に見えますが、確立された原則があります。 その中で、実装時に効くものを挙げます。

1. 今どうなっているかが分かる（システム状態の可視性）

✕ ボタンを押した。何も起きない。もう一度押す。二重登録される
○ ボタンを押した。ボタンが「送信中…」になり、押せなくなる。完了後にメッセージが出る

押した結果が見えないのが、最も多いバグです。 これは実装の問題であり、デザインの問題でもあります。

2. 現実世界の言葉で書く

✕ エラーコード: E_VALIDATION_FAILED_0x21
✕ 「不正なリクエストです」
○ 「メールアドレスの形式が正しくありません（例: name@example.com）」

画面に出す文字は、システムの都合ではなく利用者の言葉で書きます。

3. 引き返せる（ユーザーによる制御と自由）

□ 間違えた時に取り消せるか
□ 途中でやめられるか
□ 削除の前に確認があるか、あるいは元に戻せるか

△ 削除前に確認する          → 読まずに押される
◎ 削除後に「元に戻す」を出す → 間違えても取り返せる

4. 一貫性がある

同じ意味のものは、同じ見た目・同じ場所・同じ言葉にします。

✕ ある画面では「保存」、別の画面では「登録」、また別では「確定」
✕ ある画面では右下に主ボタン、別の画面では左下

利用者は、毎回考え直すことになります。

5. 記憶させない（認識 > 想起）

✕ 「先ほど入力した ID を入力してください」
○ 選択肢として一覧から選ばせる

思い出させるより、見せて選ばせるほうが速く、間違いません。

6. エラーからの回復を助ける

✕ 「エラーが発生しました」
○ 「メールアドレスは既に登録されています。ログインしますか？」

エラーメッセージに必要なのは3つです。

1. 何が起きたか
2. なぜ起きたか
3. 次に何をすればいいか      ← これが抜けているものが非常に多い

レイアウトの4原則

デザインの教科書（『ノンデザイナーズ・デザインブック』が有名）で必ず出てくる4つです。 これを知っているだけで、素人くささが消えます。

近接 — 余白は「装飾」ではなく「意味」

✕  ラベル
   （広い余白）
   入力欄        ← どのラベルの入力欄か分かりにくい

○  ラベル
   入力欄        ← 近い＝関係がある
   （広い余白）
   ラベル
   入力欄

要素の間隔は、関係の強さを表しています。 margin を適当に付けると、意図しない意味が生まれます。

整列 — 揃っていないものは目につく

✕  ┌──────────┐
   │ タイトル      │
   │    本文が少しずれている │
   │  ボタン        │
   └──────────┘

○  ┌──────────┐
   │ タイトル      │
   │ 本文          │
   │ ボタン         │
   └──────────┘

CSS では、個別に margin を足していくのではなく、 親側で gap を使うと自然に揃います。

□ 要素同士がくっついている
□ 文字が枠の端にぴったり接している
□ 情報を1画面に詰め込もうとしている

色と文字

色は「意味」で決める

□ 主要な操作      → 目立つ色（1画面に1つが原則）
□ 破壊的な操作    → 赤系
□ 成功           → 緑系
□ 警告           → 黄・橙系
□ それ以外       → 無彩色

「1画面に主ボタンは1つ」 が守られていないと、利用者はどれを押すべきか分かりません。

✕ 必須項目を赤い文字にしただけ
○ 赤くする + 「必須」と書く + アイコンを付ける

コントラストは測れる

「読みにくい」は感覚ではなく、数値で判定できます。

WCAG（W3C のアクセシビリティ指針）の基準
  通常の文字      コントラスト比 4.5:1 以上
  大きい文字      3:1 以上

薄いグレーの文字（#999 を白背景に置くなど）は、基準を満たしません。 ブラウザの開発者ツールで色を選ぶと、コントラスト比が表示されます。

文字

以下は経験則としての目安です（WCAG のような適合要件ではありません。 最終的には実機と利用者で確認してください）。

□ 本文は 16px 以上（スマホで小さいと読めない）
□ 行間は 1.5〜1.8 倍（日本語は英語より行間が要る）
□ 1行の長さは 30〜40 文字程度（長すぎると目が戻れない）
□ フォントサイズの種類を増やしすぎない（4〜5段階で足りる）

状態の設計 — ここがエンジニアの本番

デザインカンプにはたいてい**「データがある、成功した状態」しか描かれていません**。 残りは実装者が決めることになります。

1つの画面には、最低でも5つの状態があります。

✕ 「データがありません」
○ 「まだ登録がありません。最初の1件を追加してみましょう」＋ 追加ボタン

□ 100ms 未満     → 何も出さない（点滅がかえって鬱陶しい）
□ 〜1秒          → スピナー
□ 1秒以上        → スケルトン（表示される形の枠）や進捗を出す
□ 10秒以上       → 進捗の割合、キャンセル手段

画面側で連打を防ぐ      → 誤操作は減る
サーバー側で守る        → こちらが本体

フォーム

入力フォームは、最も嫌われる UIです。だからこそ差が出ます。

□ 入力欄は必要最小限にする（1つ減らすごとに完了率が上がる）
□ ラベルはプレースホルダで代用しない（入力すると消えて分からなくなる）
□ 入力形式を勝手に制限しない（電話番号のハイフン、全角半角はこちらで吸収する）
□ エラーは、その項目のすぐ横に出す（上部にまとめて出すと、どれが悪いか分からない）
□ 検証のタイミングは「入力中」ではなく「離れた時」（打っている最中に赤くしない）
□ 入力途中の内容を失わせない（エラーで全部消えるのが最悪）

アクセシビリティ

「障害のある人のための特別対応」ではありません。 誰にとっても使いやすくする話であり、多くは HTML を正しく書くだけで満たせます。

□ 見出しは h1 → h2 の順に使う（見た目のために h3 から始めない）
□ ボタンは <button>、リンクは <a>（div にクリックを付けない）
□ 画像には alt を書く（装飾なら alt="" と明示する）
□ フォームの label と入力欄を紐づける
□ キーボードだけで操作できる（Tab で回れるか、フォーカスが見えるか）
□ 色以外でも情報が伝わる

<!-- 悪い -->
<div onclick="submit()">送信</div>
 
<!-- 良い -->
<button type="submit">送信</button>

デザイナーと働く

何を渡され、何を返すか

デザイナーから  Figma のデザイン、コンポーネントの定義、遷移の意図
あなたから      技術的な制約、状態の網羅、実データを入れた結果

□ 名前が「山田太郎」ではなく、40文字の会社名だったら
□ 商品名が2行に折り返したら
□ 金額が8桁になったら
□ 一覧が0件だったら / 10000件だったら
□ 画像が無い商品があったら

デザインシステム

ボタン・入力欄・色・余白のルールをまとめたものです。

□ 同じ用途には同じ部品を使う（勝手に新しいボタンを作らない）
□ 色や余白は、定義されたトークン（変数）から選ぶ
□ 無い部品が必要になったら、追加をデザイナーと相談する

「今回だけ」で作った独自の部品が、後で全部の一貫性を壊します。

✕ カンプの見た目に1pxずつ合わせる
○ 8の倍数などのルールに沿わせ、ずれる時はデザイナーに確認する

実務の落とし穴まとめ

まとめ

• UI は見た目、UX は体験全体。 そして速さは UX であり、エンジニアの最大の貢献点
• 使いやすさには原則がある。状態の可視化・利用者の言葉・引き返せること・一貫性
• 確認ダイアログより、元に戻せるほうが強い
• 近接・整列・反復・対比。迷ったら余白を増やす
• 色は意味で決め、色だけで情報を伝えない。コントラストは数値で測れる
• 1画面に5つの状態がある。デザインカンプに描かれているのは1つだけ
• エラーメッセージには何が・なぜ・次にどうするかを書く
• アクセシビリティの大半は、正しい HTML を書くことで満たせる
• 実データを入れて崩れたら、スクリーンショット付きで相談する

公式ドキュメント

章末問題

次は、ここまでの HTML を手で書かずに、状態から組み立てる話です。