--- title: UI/UX 設計の原則 100 項目 — 9 カテゴリで引ける大全｜humbulls description: 画面設計で迷ったときに引ける UI/UX の原則 100 項目を、9 カテゴリに整理して解説します。フォーム・エラー処理・応答速度・アクセシビリティまで網羅し、AI で自社サイトをレビューする実行キット付きです。 image: https://humbulls.com/hubfs/blog-covers/cover-ui-ux-design-principles-100.png --- [Skip to content](https://humbulls.com/knowledge/ui-ux-design-principles-100#main-content) [POST](https://humbulls.com/knowledge?hsLang=ja) [サービスサイト](https://humbulls.com/?hsLang=ja) [ナレッジ](https://humbulls.com/knowledge?hsLang=ja) [セミナー](https://humbulls.com/event?hsLang=ja) [資料DL](https://humbulls.com/download?hsLang=ja) [無料相談](https://humbulls.com/consult?hsLang=ja) [ALL](https://humbulls.com/knowledge?hsLang=ja) [KNOWLEDGE](https://humbulls.com/knowledge/tag/knowledge?hsLang=ja) [CASE STUDIES](https://humbulls.com/knowledge/tag/case-studies?hsLang=ja) [セミナー](https://humbulls.com/event?hsLang=ja) [無料相談を予約](https://humbulls.com/consult?hsLang=ja) [資料ダウンロード](https://humbulls.com/download?hsLang=ja) [← サービスサイトへ戻る](https://humbulls.com/?hsLang=ja) 1. [ホーム](https://humbulls.com/knowledge) 2. UI/UX 設計の原則 100 項目 — 9 カテゴリで引ける大全 ![UI/UX 設計の原則 100 項目 — 9 カテゴリで引ける大全](https://humbulls.com/hubfs/blog-covers/cover-ui-ux-design-principles-100.png) # UI/UX 設計の原則 100 項目 — 9 カテゴリで引ける大全 最終更新日:2026.8.20 / 公開日:2026.8.20 - [AI](https://humbulls.com/knowledge/tag/ai) - [BtoB](https://humbulls.com/knowledge/tag/btob) - [コンセプト](https://humbulls.com/knowledge/tag/コンセプト) - [Claude Code](https://humbulls.com/knowledge/tag/claude-code) 最終更新日:2026.8.20 / 公開日:2026.8.20 「デザインの確認をお願いします」と言われても、「なんとなく使いにくい」から先が言えない。サイトや LP を発注する側から、humbulls がよく聞く相談です。 原因は担当者にデザインの素養がないことではありません。**指摘に名前が付いていないので、好みの言い合いにしかならない**のです。 本記事では、画面設計の判断基準になる 100 の原則を 9 カテゴリに整理し、項目ごとに「つまずく例」と「直した例」の画面を並べました。名前と見分け方さえ持っていれば、特別な知識がなくても同じ指摘ができます。 ![UI/UX 設計の原則 100 項目を 9 カテゴリに整理した地図。方針・認知・操作・入力・エラー・反応・レイアウト・モバイルとアクセシビリティ・思想の順に並ぶ](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-figure-01-nine-categories.png) 100 項目は、上から読む必要はありません。いま手を動かしている場所から引いてください。 | 章 | 決めること | 引くタイミング | | --- | --- | --- | | 1. 全体を決める原則 | プロダクト全体の方針 | 機能を足すか迷ったとき | | 2. 人の頭の中に合わせる | 情報の並べ方と言葉づかい | 押されない・見つけられないとき | | 3. オブジェクトと操作の文法 | 画面と操作の切り分け | 管理画面の構成を決めるとき | | 4. 入力とフォーム | 設問・デフォルト・ボタン文言 | 送信数が伸びないとき | | 5. エラーと安全設計 | 失敗の防ぎ方と戻し方 | 問い合わせが増えているとき | | 6. 反応・時間・状態遷移 | 待たせ方と動きの付け方 | 重い・固まると言われたとき | | 7. 画面の見せ方とレイアウト | 整列・色数・段階的な開示 | 情報が多くて読まれないとき | | 8. モバイルとアクセシビリティ | 押せる大きさと読める文字 | スマホで使いにくいとき | | 9. 道具としての思想 | 何を良しとするかの基準 | 施策と使いやすさが衝突したとき | どこから直すか迷ったら、読めない・押せない (第 8 章) → 入力の設問 (第 4 章) → 待ち時間と見た目 (第 6・7 章) の順に当ててください。直したときに数字が動く順番でもあります。 ## 1. 全体を決める原則 — 何を減らし、誰に主導権を渡すか 「機能を足すほど良くなると思っていたのに、社内から『前のほうが使えた』と言われました」。サイトや管理画面を作り直すたびに項目が増えていく、という話はよく聞きます。 原因は機能の数そのものではなく、増えた複雑さを誰が引き受けるのかを決めていないことにあります。減らす対象を先に決めていないので、判断がそのまま画面の上に積み上がります。 もうひとつ、着手前に握っておきたい前提があります。画面のなかで最後に決めるのは、いつも使う人の側です。ここが曖昧だと、親切のつもりで組んだ自動処理が、そのまま押し付けとして届きます。 #### シンプルにする 画面に置くものを減らし、一度に判断させる量を小さくします。人は選択肢が並ぶほど見比べに時間を使うので、要素が増えるほど「どれを押せばいいのか」で手が止まります。BtoB サイトのトップに主要導線を十数本並べる構成はよく見かけますが、増やした分だけ一本あたりは目立たなくなります。**消したら誰が困るかを聞いてみて、即答できない要素は整理の余地**があります。 ![シンプルにするの参考 UI。左が「つまずく例」、右が「直した例」。トップの導線 12 本を等しく並べた画面、資料 DL とお問い合わせの 2 本だけを面に出し、残りをメニュー帯へ移した画面](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-001-reduce-what-is-on-screen.png) #### 簡単にする 見た目が整っていることと、やり終えるまでが楽なことは別物です。要素を減らしても、入力のたびに調べものが要れば、その画面は簡単になっていません。問い合わせフォームで「ご希望のプラン」を選ばせると、プラン名を知らない見込み客はいったんサイトに戻って調べることになります。**整った画面ほどこの手のつまずきは表に出ない**ので、作業を最後まで通せるかどうかで見てください。 ![簡単にするの参考 UI。左が「つまずく例」、右が「直した例」。同じ整った 3 択ラジオでも、プラン名を聞く問い、読者がすでに知っている検討状況を聞く問い](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-002-easy-not-just-tidy.png) #### 複雑性保存の法則 どんな仕組みにも、それ以上は削れない複雑さが残ります。Xerox PARC の Larry Tesler が 1980 年代半ばに示した考え方で、**削りきれない分は消えず、使う人が背負うか、作り手が設計と開発の段階で引き受けるか**に分かれます (Laws of UX、2026 年 8 月取得)。郵便番号から住所を自動で埋める入力欄は、ユーザーの手間を開発側が引き取った例です。画面が楽になったと感じたら、その手間をどこが肩代わりしたのかを確かめてください。 ![複雑性保存の法則の参考 UI。左が「つまずく例」、右が「直した例」。住所を全部手入力させる欄＋「引き受けるのは入力する人」帯、郵便番号から自動で埋まる欄＋「引き受けるのはつくる側」帯](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-003-conservation-of-complexity.png) #### 単純なものは単純なままに よくある用件は最短で終わらせ、込み入った用件も回り道すれば達成できるようにします。上級者向けの設定を全員に見せると初めて来た人が止まり、隠しすぎると使い慣れた人が毎回遠回りします。資料ダウンロードなら、名前とメールだけで完了する道を正面に置き、部署や導入時期は任意欄に下げる形になります。片方を立てるために、もう片方を犠牲にしていないか見てください。 ![単純なものは単純なままにの参考 UI。左が「つまずく例」、右が「直した例」。資料 DL で部署・導入時期まで全部必須、名前とメールで完了する道を正面に置き、詳細は任意リンクで回り道](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-004-simple-stays-simple.png) #### 一貫性 同じ意味のものは同じ見た目と同じ言葉で示し、違う意味のものは見分けがつくようにします。ユーザーは自社サイトより他社のサイトで過ごす時間のほうが長く、すでに知っているサイトと同じ挙動を好みます (Laws of UX の Jakob's Law、2026 年 8 月取得)。世の中で通っている作法から外れると、それだけで操作を覚え直させることになります。同じ機能が「送信」「確定」「登録」と呼び分けられていたら、まず用語の一覧をつくって揃えてください。 ![一貫性の参考 UI。左が「つまずく例」、右が「直した例」。3 つのフォームの送信ボタンが「送信」「確定する」「登録」とバラバラ、全部「送信する」に揃えた](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-005-consistent-wording.png) #### ユーザーの主導権 進める・戻る・やめるの判断を、ユーザーの手に残します。Jakob Nielsen が 1994 年に公開した 10 項目のユーザビリティ原則でも、誤って入り込んだ操作から抜け出せる「非常口」を用意することが挙げられています (Nielsen Norman Group、2026 年 8 月取得)。フォームの途中で勝手に次のページへ送られる、閉じられないモーダルが出るといった作りは、この主導権を奪っています。やっぱりやめたと言える出口があるか確認してください。 ![ユーザーの主導権の参考 UI。左が「つまずく例」、右が「直した例」。メール登録モーダルに閉じる手段がない、同じモーダルに「閉じる」を置き、登録しなくても読み続けられる](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-006-user-in-control.png) #### タスクコヒーレンス 同じ人が同じ操作を繰り返す、という前提で画面を組みます。前回の絞り込み条件、前回選んだ拠点、前回使った出力形式は、たいてい今回も同じものが選ばれます。Alan Cooper は『About Face』で、ユーザーが入力する価値のあるものはプログラムが覚える価値がある、と書いています。管理画面で毎回同じ期間指定をやり直させているなら、初期値を前回値にするだけで作業が一段短くなります。 ![タスクコヒーレンスの参考 UI。左が「つまずく例」、右が「直した例」。レポート出力の期間・拠点・形式が毎回「選択してください」、前回値が初期値で入っている](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-007-task-coherence.png) #### メジャーなタスクに最適化する すべての用件を平等に扱わず、多く起きる用件を一番速い経路に置きます。BtoB サイトなら資料請求と問い合わせが上位に来て、採用情報やニュースはその下に回ります。ここを横並びにすると多数派が毎回同じだけ探すことになり、少数派への公平さが全体の速度を落とします。アクセス解析で上位に来ているページと、画面のなかで一番目立っている要素が食い違っていたら、優先順位を組み替える合図です。 ![メジャーなタスクに最適化するの参考 UI。左が「つまずく例」、右が「直した例」。「よく使われている順」を下に置いたままナビが 5 項目横並び、上位 2 つをボタン化して右端に出した](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-008-optimize-major-task.png) #### カスタマイズ機能に頼らない 設定で切り替えられるようにする前に、初期状態を正しくします。150 以上の設定を持つ Microsoft Word の利用者を調べた調査では、何かひとつでも設定を変更していた人は 5% 未満でした (UIE、2011 年 9 月公開、2026 年 8 月取得)。届いた状態には理由があると考えて、ほとんどの人は触りません。社内で意見が割れたときに設定項目を足して決着させているなら、決めきれなかった分がそのままユーザーの手間になります。 ![カスタマイズ機能に頼らないの参考 UI。左が「つまずく例」、右が「直した例」。表示設定 3 項目が全部未選択、既定値 50 件を入れ、残りは詳細設定へ畳んだ](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-009-good-defaults-over-settings.png) ここまでの 9 項目は、個別の画面をいじる前に、プロダクト全体の方針として決めておくものです。ここが決まっていないと、次章以降の判断はその場しのぎになります。 次の章では、この方針を実際の情報の並べ方に落としていきます。 ## 2. 人の頭の中に合わせる — 認知の制約を設計条件として扱う 「ボタンはちゃんと置いてあるのに、ユーザーテストで誰も押さなかった」。サイトを作り直した直後の検証で、担当の方からよく聞く報告です。設計の抜けを探しても、ボタン自体は要件どおりの位置に置かれています。 押されなかった理由は、利用者の注意力の不足ではありません。 画面のほうが、人の頭の働き方に逆らって組まれています。知覚・記憶・注意の限界を先に設計条件として固定すると、レイアウトも文言も判断できるようになります。 #### メンタルモデル 利用者は画面を開く前から、これはこう動くはずだという自分なりの見取り図を持って来ます。設計がその見取り図とずれていると、機能が足りていても操作を間違えます。資料請求のボタンを押した人がその場で PDF を待っていると、フォーム送信後にメールで届く設計では手が止まります。「どこから申し込めるのか分からない」という連絡が窓口に届いているなら、説明文を足すより先に、この見取り図とのずれを探すほうが早く直ります。 ![メンタルモデルの参考 UI。資料 DL の主ボタン → 直後の結果カード。左は「資料をダウンロード」なのにメール送信が返る、右は「メールで資料を受け取る」に文言を合わせ、押す前の見取り図と結果を一致させた](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-010-mental-model.png) #### シグニファイア 押せる、入力できる、掴んで動かせるといった操作の可能性を利用者に知らせる、目に見える手がかりを指します。ドナルド・ノーマンは、行為そのものの可能性と、それを伝える印を切り分けるためにこの語を持ち込みました (ACM Interactions、2008 年)。装飾を減らす途中でボタンの枠線と影を消し、テキストリンクの下線も外した画面は、押せる場所を伝える印をまとめて落としています。**白黒のスクリーンショットを初見の人に渡し、押せる場所を指してもらう**と手早く確かめられます。 ![シグニファイアの参考 UI。左は押せる場所が地の文に溶けている例、右は下線とボタンの面で押せることを示した例](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-011-signifier.png) #### マッピング 操作するものと、その結果が現れる場所を、どう対応づけるかという話です。人は空間的な並びから対応を読み取るので、操作と結果の並びが一致していれば、説明がなくても正しく手が動きます。管理画面で一覧の行が縦に並んでいるのに、操作ボタンだけ画面上部に横並びでまとまっていると、どのボタンがどの行に効くのかが毎回分からなくなります。対応関係を注記や吹き出しで補っている箇所は、本来なら配置だけで解けていたはずの場所です。 ![マッピングの参考 UI。取引先一覧の編集・削除。左は画面上部の横並びツールバー、右は同じ 2 操作を各行の右端へ。操作の種類は左右同一にし、差分を「配置」だけに絞った](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-012-mapping.png) #### 視覚ゲシュタルト 人はものを 1 つずつ見るのではなく、近いもの、似ているもの、囲まれているものをひとまとまりとして受け取ります。問い合わせフォームでは、ラベルと入力欄の間隔より入力欄と次のラベルの間隔のほうが狭いというだけで、ラベルと欄の対応が 1 段ずれて見えます。区切り線や背景色を足す前に、画面を縮小するか目を細めて、見えている塊の数と境目が設計意図と合っているかを見ます。 ![視覚ゲシュタルトの参考 UI。問い合わせフォームの会社名・お名前。左はラベル→欄 28px、欄→次ラベル 8px でラベルが上の欄に付いて見え、右は 8px、28px に反転](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-013-gestalt-proximity.png) #### ユーザーの言葉を使う 画面に置く語は、利用者が普段使っている言い方に寄せます。社内の呼び名をそのままナビゲーションに出すと、外から来た人はどこを押せばよいのか判断できません。BtoB サイトなら、検索キーワードと商談の議事録が語彙の出所になり、営業が電話口で使っている言い回しはそのまま使えます。ナビゲーション項目を声に出して読み、社外の人が意味を言い当てられないものが混じっていたら、そこが言い換えの対象です。 ![ユーザーの言葉を使うの参考 UI。グローバルナビ 3 項目。左は社内の呼び名（BX デザイン、グロース支援、インサイト）、右は検索・商談で使われる言い方。ヒーロー見出しとリード文は左右同一](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-014-users-words.png) #### ユーザーの記憶に頼らない 覚えていないと次に進めない画面を作らない、という原則です。短期記憶に保てる塊の数は 7±2 とされ (Miller、1956 年)、記憶術の助けを除くと 4 つ前後だとする整理もあります (Cowan、2001 年)。ただし**この数字をメニュー項目数の上限にするのは誤用**で、画面に表示されているものは覚える必要がありません (Nielsen Norman Group、2009 年)。原則が効くのは、長い申込フォームの確認画面で前の画面の入力内容を見せ直すような場面です。 ![ユーザーの記憶に頼らないの参考 UI。申込フォームの確認画面。左は「ご入力いただいた内容で送信します」だけで記憶頼み、右は会社名・お名前・メールを見せ直した。見出しと送信ボタンの位置・文言は左右同一](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-015-recognition-over-recall.png) #### コンストレイント 間違った操作をそもそもできないように、選べる範囲をあらかじめ狭めておく考え方です。人は禁止事項を読んで覚えるのが苦手なので、事後にエラーメッセージで叱るより、はじめから選べなくするほうが負担は軽くなります。打ち合わせの日程調整で過去の日付を選べなくする、数量欄で数値キーボードだけを出す、といった細工がこれにあたります。入力エラーの多い項目は、書き方の説明を足す前に、間違った値をそもそも入れられる作りになっていないかを見ます。 ![コンストレイントの参考 UI。打ち合わせ希望日のカレンダー（2026 年 8 月の実配列）。左は過去日も押せて 5 日を選びエラー、右は本日以前をグレーで落として 12 日を選ぶ。部品は同一で、差分は過去日の選択可否のみ](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-016-constraints.png) #### 直観的より慣用的に 利用者が速く扱えるのは、すでに別の場所で覚えを済ませた見慣れた形です。初見で意味の分かる斬新な形よりも、手が早く動きます。ロゴを押すとトップに戻る、ログインや問い合わせは右上にあるといった配置を、多くの人は他社のサイトを回るうちに覚えてきました。**ここを自社らしさの表現として動かすと覚え直す手間を負わせる**ので、一般的な位置から外すなら、見合う理由があるかを公開前に確かめてください。 ![直観的より慣用的にの参考 UI。サイトヘッダーで、ロゴ中央+問い合わせ左端の自社流配置 → ロゴ左上+問い合わせ右上の他社共通配置に、並び順だけを変えた](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-017-idiomatic-over-intuitive.png) #### 空間的に記憶できるようにする 人は情報の中身だけでなく、それが画面のどこにあったかという位置でも覚えています。同じ操作を毎日繰り返す管理画面ほどこの記憶が効き、慣れた利用者は文字を読まずに場所へ手を伸ばします。よく使う順に自動で並べ替わるメニューや、ページごとに項目数が変わるナビゲーションは、こうして積み上げた記憶を毎回無効にします。利用頻度に応じて順序が動く要素があれば、その便利さと引き換えに何を壊しているのかを見直してください。 ![空間的に記憶できるようにするの参考 UI。左が「つまずく例」、右が「直した例」。管理画面のサイドメニューを昨日、今日の 2 列で並置し、使用頻度で自動並び替え → 順序固定に（差分は今日の列の並びだけ）](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-018-spatial-memory.png) #### プロスペクティブメモリー あとでこれをやろう、という将来の予定を覚えておく働きを、心理学ではプロスペクティブメモリーと呼びます。この記憶は途中で別の作業が挟まると、予定ごと抜け落ちます。長い申込フォームで残りは後で入力しようと離脱した人が戻ってこないのは、興味が薄れたからとは限りません。「あとで」を利用者の頭に預けている導線を見つけたら、途中保存と再開リンク、通知メールのように、思い出す仕組みを設計側で用意します。 ![プロスペクティブメモリーの参考 UI。左が「つまずく例」、右が「直した例」。ステップ 3、5の申込フォームで、「次へ」だけ → 「保存して再開リンクを受け取る」を並置し、思い出す役目を設計側に移した](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-019-prospective-memory.png) #### フィッツの法則 対象に手を伸ばして届くまでの時間は、距離が遠いほど、対象が小さいほど伸びます。Paul Fitts が 1954 年に MT = a + b × log₂(2D/W) と定式化した関係で、D が対象までの距離、W が対象の幅にあたります。画面の端や四隅ではポインタが縁で止まるため、そこに置いた要素は片方向に無限の幅を持つ標的として働きます。主要な CTA を小さく作って余白に浮かせた画面や、削除ボタンを保存ボタンの真横に並べた画面は、この法則に逆らっています。 ![フィッツの法則の参考 UI。左が「つまずく例」、右が「直した例」。料金プランカードのCTAを、余白に浮いた小ボタン → 同じ中心位置のままカード幅いっぱいに拡大（変えたのは標的の大きさだけ）](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-020-fitts-law.png) #### ヒックの法則 選択肢の数が増えると、選び終わるまでの時間が対数的に伸びます。Hick (1952 年) と Hyman (1953 年) が RT = a + b × log₂(n+1) として整理した関係で、n が選択肢の数にあたります。ただし順不同のリストを 1 項目ずつ目で追う場面には当てはまらず、分類や並び順のある選択に適用範囲が限られます。問い合わせフォームの業種プルダウンに 60 件の選択肢を並べているなら、大分類を 1 段挟めないかをまず検討してください。 ![ヒックの法則の参考 UI。左が「つまずく例」、右が「直した例」。問い合わせフォームの業種選択を、60 件フラットなプルダウン（スクロールバー+ほか 57 件） → 大分類 6 チップの 1 段に](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-021-hicks-law.png) #### 錯視を考慮する 座標や寸法の数値をそろえても、目にはずれて見えることがあります。円や三角形は同じ高さの四角形より小さく見えるので、アイコンを並べるときはわずかに大きく作って釣り合わせます。文字の左端も、括弧や引用符が付くと数値上の位置より内側に引っ込んで見えるため、目で合わせ直したほうが整います。CSS 上は中央にそろえたのにずれて見えるという指摘が出たら、実装ミスを探す前に錯視を疑ってください。 ![錯視を考慮するの参考 UI。左が「つまずく例」、右が「直した例」。概念系。ツールバーの四角・円・三角を上下ガイド線つきで並置し、数値 48px揃え → 円 54、三角 56で目の揃えに](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-022-optical-adjustment.png) まずは自社で一番使われている導線を 1 本開き、13 項目のうち破っているものに印を付けてみてください。印が重なった画面は、細部を磨くより並べ方から組み直すほうが早く直ります。 → 手元の画面がここまでの原則を満たしているかは、巻末の実行キット①でそのまま点検できます。 ## 3. オブジェクトと操作の文法 — 「何を」選んでから「どうする」 「管理画面のメニューが『〜を登録する』『〜を編集する』だらけで、目的の一覧にたどり着けない」。ツールを導入して運用が始まった会社から、数週間もすると出てくる声です。同じことは、資料請求の導線が「申し込む」「送信する」ばかりになった BtoB サイトでも起きます。 この画面が使いにくいのは、説明書が足りないからではありません。手続きを画面の入口に据えたせいで、扱いたい対象そのものが画面から消えているのです。作る側は業務を作業の連なりとして把握しているので、その並びをそのままメニューに写してしまいます。 オブジェクト指向 UI と呼ばれる設計では、この順番を逆さにします。先に対象を並べて見せ、選んだあとから何ができるかを示す形に組み替えます。以下の 10 項目は、画面から名詞を取り戻すための道具立てです。 #### オブジェクトベースにする 画面の単位を、作業の手続きではなく業務が扱う対象に置き換えます。人は自分の仕事を「先週の問い合わせ」「あの見積書」のように対象で覚えていて、「新規登録処理」という手続き名からは記憶を引き出せません。**メニュー項目がすべて動詞で終わっていたら、設計が手続きの側から始まった合図**です。「問い合わせ」「資料」「担当者」と名詞に並べ替えると、登録画面と編集画面がひとつにまとまり、画面の数も減ります。 ![オブジェクトベースにするの参考 UI。左が「つまずく例」、右が「直した例」。管理画面メニューが「問い合わせを登録する、編集する…」と動詞 4 項目に並ぶ例 → 「問い合わせ、資料請求、担当者」の名詞 3 項目になり、登録も編集もその中にまとまって項目が減る例](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-023-object-based-menu.png) #### ビューはオブジェクトを表象する ビュー、つまりひとつの画面は、その裏にある対象の姿を映したものにします。問い合わせ一覧という画面に映っているのは問い合わせの集まりであって、検索という機能ではありません。ビューと対象が素直に対応していれば、利用者は自分が今どこにいるかを画面の名前だけで言い表せますし、URL を共有するだけで話が通じます。タイトルを読んでも居場所を説明できない画面や、ひとつの画面に別々の対象が同居している画面では、この対応が崩れかけています。 ![ビューはオブジェクトを表象するの参考 UI。左が「つまずく例」、右が「直した例」。同じ問い合わせ一覧なのに画面名「検索」・URL、search?type=inquiry&status=new の例 → 画面名「問い合わせ」・URL](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-024-view-represents-object.png) #### オブジェクトは自身の状態を体現する 状態は、対象そのものの見た目に出します。下書きの記事は下書きらしく、送信済みの資料請求は送信済みと分かる形で、一覧のその行の中に状態が現れているのが理想です。状態をステータス欄の文字だけに閉じ込めると、利用者は上から一行ずつ舐めるように読むしかなくなり、件数が増えたところで対応漏れが出ます。**色や余白や並び順に状態が出ていない一覧は、見落としを利用者の注意力で埋めさせている画面**なので疑ってください。 ![オブジェクトは自身の状態を体現するの参考 UI。左が「つまずく例」、右が「直した例」。資料請求一覧の状態がステータス欄の文字だけの例 → 未対応行は行頭の帯+太字+墨面チップ、対応済み行は薄い文字+枠だけのチップで、行そのものが状態を持つ例](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-025-state-in-the-object.png) #### 名詞→動詞の操作順序 先に対象を選ばせ、そのあとで操作を選ばせます。この順番なら、選んだものを目で確かめてから操作を決められるので、違う相手に処理を当てる事故が減ります。動詞から入る画面では、今どれを相手にしているのかを頭の中だけで保持したまま進むことになり、途中で電話や別の依頼が挟まると取り違えます。「削除モードに入ってから対象を選ぶ」という流れが残っていたら、順番が入れ替わっているので組み直せます。 ![名詞→動詞の操作順序の参考 UI。左が「つまずく例」、右が「直した例」。先に削除を押して「削除モードです、削除する行をクリックしてください」となり、対象を選ぶ手段が画面にない例 → 先にチェックで 2 行選び、帯の同じ位置に「2 件を選択中」と出ている例](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-026-noun-then-verb.png) #### 直接操作 対象そのものをつかんで動かせるようにします。Ben Shneiderman は 1983 年に IEEE Computer 誌へ寄せた論文で、対象が常に画面に見えていること、操作の結果がすぐ返ること、素早く取り消せることを直接操作の条件に挙げました。管理画面の一覧で表示順を変えるのに設定画面を開かせているなら、行をつかんでそのまま動かせないか検討する価値があります。 ![直接操作の参考 UI。左が「つまずく例」、右が「直した例」。フォーム項目の並び替えを「表示順の設定」という別画面で番号入力する例 → 一覧のまま各行にグリップが付き、つかんで上下に動かせる例（上下矢印で可動を示す）](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-027-direct-manipulation.png) #### モードレス 同じ操作がいつでも同じ結果を返す状態を、モードレスと呼びます。編集モードと閲覧モードのように画面の状態で意味が変わると、利用者は自分が今どちらにいるかを覚え続けることになり、覚え違えがそのまま誤操作になります。モードをなくす設計を広めた Larry Tesler は、個人サイトのドメインに nomodes.com を使っていました。同じボタンが場面によって違う働きをする画面は、モードをひとつ抱えています。 ![モードレスの参考 UI。会社情報の設定で、左は「編集する」を押すまで直せない閲覧、編集モード制、右はモードを廃して常に入力欄でその場保存](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-028-modeless.png) #### ジェスチャはコマンド式ではなく直接操作式にする スワイプやドラッグは、隠しコマンドではなく物を動かす感覚に対応させます。「三本指で左に払うと前の画面に戻る」は覚えないと使えませんが、「つまんだカードを引っ張って別の列に移す」は見れば分かります。前者は説明を読むまで存在にすら気づけないので、知っている人だけが速く使える画面になります。触っても何も動かず、決まった動きをしたときだけ反応するなら、ジェスチャがコマンドになっています。 ![ジェスチャはコマンド式ではなく直接操作式にするの参考 UI。案件ボードで、左はカードが動かず隠しジェスチャの注記だけ、右は同じカードをつまんで隣の列へドラッグ中（破線ゴースト＋矢印）](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-029-gesture-direct-manipulation.png) #### ナビゲーション項目は名詞にする メニューやタブのラベルは、対象の名前で書きます。「資料をダウンロードする」より「資料一覧」、「お問い合わせする」より「お問い合わせ」と置くほうが、その先に何があるかを想像しやすくなります。動詞のラベルからは、押した先が入力フォームなのか説明ページなのか判別できず、押す前の身構えが変わってしまいます。BtoB サイトのグローバルナビが「〜する」で揃っていたら、案内ではなく勧誘の言葉になっていないか見直してください。 ![ナビゲーション項目は名詞にするの参考 UI。BtoB サイトのグローバルナビ＋ドロップダウンで、左は「サービスを見る／導入事例を読む」と動詞、右は「サービス／導入事例」と名詞](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-030-nav-labels-nouns.png) #### アイコンは名詞または形容詞を表す アイコンには対象か性質を担わせ、操作そのものは託しません。ゴミ箱の絵が通じるのは、それが「ゴミ箱」という物を指しているからで、「削除する」という動詞を絵にできているわけではありません。Nielsen Norman Group も 2014 年 7 月の記事で、大半のアイコンには定まった意味がなく、常時表示のテキストラベルを添える必要があると述べています。ラベルのないアイコンだけが並ぶツールバーは、社内でも読み方が割れます。 ![アイコンは名詞または形容詞を表すの参考 UI。問い合わせ一覧のツールバーで、左はアイコン 4 つがラベルなし、右は同じアイコンに「削除／書き出し／複製／メール送信」を常時表示](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-031-icon-needs-label.png) #### すべての操作可能な要素は意味を持つ 押せる見た目のものには、必ず働きを持たせます。働きのないものを押せる見た目で置くと、利用者はカーソルを合わせて反応がないことに気づき、壊れていると受け取ります。BtoB サイトの実績ロゴやカード型の見出し、装飾のつもりで角丸と影を付けた囲みでよく起きる崩れ方です。**押してみないと分からない要素がひとつあると、利用者はほかの要素も試すようになり**、画面全体の操作が探り探りになります。 ![すべての操作可能な要素は意味を持つの参考 UI。導入企業セクションで、左はロゴが枠付きカードで押せそうに見えるが働きがない、右は枠を外して押せるのはボタン 1 つだけ](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-032-clickable-means-something.png) 名詞を先に立てるだけで、画面の数も、利用者が覚えることも減ります。ここまでが「何を扱うか」の文法で、次の章ではそれをどう見せるかに移ります。 ## 4. 入力とフォーム — 離脱はデザインではなく設問で起きる 「問い合わせフォームの項目を 3 つ減らしてくれと営業に言われたのですが、どれを削るべきか根拠がありません」 離脱が起きる原因は項目の多さではなく、答えるためにいったん手を止めて考えこむ設問が混ざっていることにあります。項目数は、その症状として表に出ているだけです。 「年間予算」を自由入力で書かせる欄が 1 つあるだけで、社内確認が必要になって送信が止まります。選ぶだけで終わる設問なら、10 個並んでいても指は止まりません。削る候補は、その場で即答できない設問から選びます。 ![問い合わせフォームの設問を「残す・統合する・デフォルトで埋める・削る」の 4 つに仕分ける判定図](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-figure-02-form-triage.png) #### 入力フォームにはストーリー性を持たせる フォームは、書き終わるまで続く一本の会話だと考えてください。前の質問と次の質問がつながっていれば先を予測でき、予測できるあいだは手が止まりません。資料請求なら、会社名から部署、役職、いま抱えている課題へと、面談で聞く順番のまま進む並びにします。所属を聞いた直後に予算を尋ね、そのあとまた部署名に戻る並びは、書き手に「まだ終わらないのか」と思わせます。 ![入力フォームにはストーリー性を持たせるの参考 UI。同じ設問 5 つ（会社名、部署名、役職、課題、予算）を、左は話題が飛ぶ順・右は面談と同じ順に並べ替え、各行の話題チップで飛び方を可視化](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-033-form-question-order.png) #### 操作の流れを作る 入力欄の並びは、そのまま指と視線の移動経路になります。左右にジグザグさせたり、縦一列の途中で 2 カラムに割ったりすると、次にどこを埋めるのかを毎回探すことになります。ラベルは欄の上に置いて縦一列に積むのが最短で、スマートフォンでも同じ形のまま幅を縮められます。姓と名、市区町村と番地のように必ず対で埋める項目だけ、横並びを許します。 ![操作の流れを作るの参考 UI。同じ 3 欄を、左は幅と左右位置がバラバラ・右は左端そろえの縦一列にし、入力の経路を折れ線／直線の矢印で重ねて移動距離を対比](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-034-single-column-flow.png) #### 前提条件は先に提示する 「送信後に営業から電話が来る」「登録には法人のメールアドレスが必要」といった条件は、設問の前に出します。書き終わってから条件を知らされると、それまでの入力が無駄になり、印象も悪くなります。WCAG 2.2 も、入力を求める場面ではラベルか説明を提供することを達成基準 3.3.2 (レベル A) として定めています。条件をフォームの末尾に小さくぶら下げていたら、位置が逆です。 ![前提条件は先に提示するの参考 UI。「法人メール必須・送信後に電話」という同一文言を、左は設問の下・右は設問の上に置き、区切り線ごと位置だけを入れ替え](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-035-conditions-before-fields.png) #### よいデフォルト 初期値には、たいていの人がそう答える値を入れておきます。国名が日本、問い合わせ種別が「サービスについて」のように多数派の選択が入っていれば、その欄は読むだけで通過でき、考える回数が 1 つ減ります。ただし、金額や送信先のように誤ったまま通ると困る項目に初期値は置きません。デフォルトは手間を省くための道具であって、利用者の判断を代行させるものではありません。 ![よいデフォルトの参考 UI。「国・地域」「お問い合わせ種別」の 2 セレクトを、左は両方「選択してください」・右は多数派の「日本」「サービスについて」が入った状態にし、初期値の有無だけを差分に](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-036-good-defaults.png) #### 制限コントロールを活用する 選べる値をあらかじめ絞った部品を使い、間違った値をそもそも入れられなくします。日付をテキスト欄で受け取ると「2026/08/07」「2026年8月7日」が混ざり、受け取ったあとの整形と、書き手へのエラー表示が両方必要になります。カレンダーから選ばせれば、表記は最初から 1 つに揃います。エラーメッセージを増やす前に、その欄が本当に自由入力でなければならないのかを確かめます。 ![制限コントロールを活用するの参考 UI。「ご希望日」を、左は自由入力＋書式エラーの差し戻し・右は 2026 年 8 月のカレンダー（7 日選択済み）にし、エラーが要る側と要らない側を対比](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-037-constrain-the-input.png) #### 選択肢の文言は肯定文にする 選択肢に否定を入れると、読み手は頭のなかで打ち消し算をすることになります。「メールマガジンを受け取らない」にチェックが入った状態は、受け取るのか受け取らないのかを一瞬考えさせます。「メールマガジンを受け取る」に直せば、チェックの有無がそのまま意思になります。「〜しない」「〜を希望しません」で始まる選択肢や、二重否定の同意チェックは、裏返して書けないか試します。 ![選択肢の文言は肯定文にするの参考 UI。同じ 3 つのチェックボックスを全部未チェックのまま、左は「受け取らない、希望しない、同意しない」、右は「受け取る、希望する、同意する」にし、文言だけを差分に](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-038-affirmative-choice-labels.png) #### 値を入力させるのではなく結果を選ばせる 利用者に計算や換算をさせず、こちらで候補を用意して選ばせます。「希望日時を入力」の欄を空き枠のボタンに替える、従業員数を数字で書かせずに規模の区分から選ばせる、といった置き換えです。書き手が電卓や社内資料を開いた時点でその場の送信は難しくなり、あとで戻ってくる人はほとんどいません。**設問に答えるのに別の画面が要るなら、直すべきは入力欄の見た目ではなく設問の側**です。 ![値を入力させるのではなく結果を選ばせるの参考 UI。左はご予算を自由入力で書かせる例、右は幅の選択肢から選ばせる例](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-039-choose-result-not-value.png) #### 入力欄を構造化する 長いフォームは、意味のまとまりごとに区切って見出しを付けます。連絡先、会社情報、相談内容と 3 つに割るだけで全体量が把握でき、どこまで進んだかも分かります。区切りのない 20 行のフォームは、項目数が同じでも実際の作業量より重たく見えます。まとまりは 3〜5 個に収め、1 まとまりが 1 画面に入る量にすると、スクロールと理解の単位が揃います。 ![入力欄を構造化するの参考 UI。同じ 6 項目の問い合わせフォームを、左は区切りなしの一続きの行、右は「お客様情報、ご相談内容」の 2 見出しで区切った 2 チャンクにし、変えたのは見出しと余白だけにしました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-040-group-the-fields.png) #### デフォルトボタンには具体的な動詞を用いる ボタンの文字には、押した結果をそのまま書きます。「送信」や「OK」を「資料をダウンロードする」「無料相談を申し込む」に替えれば、押す前に何が起きるか分かります。Microsoft の Windows 向けガイドラインも、OK のような汎用ラベルを避け、問いかけへの具体的な応答をボタン文言に使うよう案内しています (Microsoft Learn、2026 年 8 月閲覧)。ボタンだけを読んで意味が通らなければ、書き直してください。 ![デフォルトボタンには具体的な動詞を用いるの参考 UI。左は確認ダイアログのボタンが「OK、キャンセル」、右は結果が読める動詞にした例](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-041-default-button-verb.png) #### ラジオボタンは単数選択、チェックボックスはオンオフ 形が役割を伝えます。丸いラジオボタンは「並んだ選択肢からひとつ」、四角いチェックボックスは「この項目を入れるか外すか」と、利用者は押す前に形だけで見分けています。この対応が崩れると、複数選べるのかどうかを試しにクリックして確かめることになります。1 つだけ置かれたラジオボタンは、押したあと解除できないので、チェックボックスに替えます。 ![ラジオボタンは単数選択、チェックボックスはオンオフの参考 UI。「ご希望の連絡方法」のラジオ 2 択は左右とも同じにして、下段のメールマガジン 1 項目だけを、左はひとつだけの丸いラジオ、右は四角いチェックボックスに変えました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-042-radio-vs-checkbox.png) #### フリップフロップ問題を避ける オンとオフを 1 つのボタンで切り替えるとき、そのラベルが現在の状態を指すのか、押した後の状態を指すのかが読み取れなくなります。「通知オン」と書かれたボタンでは、いま通知が有効なのか、押すと有効になるのかが判別できません。状態はスイッチや表示で示し、ボタンには操作だけを書きます。管理画面の一括設定やメール配信の停止ボタンのように、押す頻度が低い操作ほど起こしやすくなります。 ![フリップフロップ問題を避けるの参考 UI。管理画面の通知設定 2 行で、左は「通知オン」「配信オン」というボタン、右は同じ位置をスイッチ + 状態表示に置き換えました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-043-state-not-flip-flop.png) #### ユーザーに厳密さを求めない 表記のゆれは、受け取る側で吸収します。電話番号のハイフン、全角と半角、郵便番号の桁区切りを理由にエラーを返すのは、**システムの都合を書き手に押し付けているだけ**です。WCAG 2.2 も同じ方向を向いていて、同じ手続きのなかで一度入力させた情報をもう一度求めるなら、自動で埋めるか選べるようにすることを求めています (達成基準 3.3.7、レベル A)。エラーが出た項目を並べてみると、その多くは受け取ってから整形すれば済む種類です。 ![ユーザーに厳密さを求めないの参考 UI。電話番号に「03-1234-5678」と入った同じ画面で、左は入力し直しを求めるエラー、右はそのまま受け付け保存時に整形すると伝える通知に変えました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-044-accept-loose-input.png) #### 入力サジェスチョンを提示する 過去の入力やブラウザの自動入力が効くようにしておくと、氏名や住所の欄は数タップで埋まります。HTML の autocomplete 属性を正しく指定すれば有効になり、WCAG 2.2 の達成基準 1.3.5 (レベル AA) が求める「入力欄の目的を機械的に判別できる状態」にもなります。郵便番号から住所を補完する、社名の先頭数文字で候補を出すといった補助も同じ発想です。自動入力が効かないフォームは、name 属性が独自の命名になっていないかを疑ってください。 ![入力サジェスチョンを提示するの参考 UI。お名前欄にカーソルがある同じフォームで、左は候補が出ずゼロから打つ状態、右は入力欄と同じ幅の自動入力候補が浮いた状態にしました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-045-input-suggestion.png) #### 肯定／否定ボタンの順序はプラットフォームのルールに従う 確認ダイアログのボタンの並びは、OS ごとに逆です。macOS では追加したボタンが右端から左へ並び、実行を促す既定のボタンが右に来ます (Apple Developer Documentation、2026 年 8 月閲覧)。Windows の現行ガイドラインは向きが反対で、肯定側を左、キャンセルを右に置くよう案内しています (Microsoft Learn、2026 年 8 月閲覧)。自社の好みで決めず、その画面が動く環境の慣習に合わせます。 ![肯定／否定ボタンの順序はプラットフォームのルールに従うの参考 UI。左が「つまずく例」、右が「直した例」。「変更内容を保存しますか。」のダイアログを macOS と Windows の 2 段で並べ、左は両方「保存」「キャンセル」の順で統一、右は macOS 側だけ「キャンセル」「保存」に直した](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-046-button-order-per-platform.png) 14 項目の多くは、画面の見た目より設問の書き方に関わります。CSS を触る前に **1 問ずつ音読して答えられない設問を洗い出し**、そのうえで、送信した後に画面が何を返すのかを見直してください。 → 自社フォームの設問を 4 分類する作業は、巻末の実行キット②でそのまま実行できます。 設問を減らした効果は、[GA4 で BtoB サイトのリード計測](https://humbulls.com/knowledge/ga4-btob-lead-tracking?hsLang=ja) の手順で公開前後を比べられます。 ## 5. エラーと安全設計 — 起こさせない、起きても壊さない 「送信でエラーになった瞬間、書いた問い合わせ内容が全部消えた」。フォーム改修の相談で、いちばんよく聞く話です。同じ内容をもう一度書き直してもらえることは、まずありません。 入力が消える事故を利用者の操作ミスとして扱うのは筋違いです。原因は失敗したときに何を守るのかを決めないまま画面を作ったことにあります。 打ち手は二層で持ちます。エラーを起こさせない設計と、起きた後に利用者の時間を守る設計を分けて考えてください。守るものが決まれば、この章の 9 項目のどれを先に手当てするかも決まります。 #### エラーを回避する エラーメッセージの文言を磨く前に、エラーになる状態そのものをなくします。Nielsen のユーザビリティ 10 原則も、良い文言より問題の未然防止を先に置いています (Nielsen Norman Group, 2026-08)。問い合わせフォームなら、電話番号のハイフンを弾かずに、受け取った側で外してしまえば済みます。入力欄の注記が「半角英数字で入力してください」だらけになっていたら、システムの都合を利用者に肩代わりさせていないか疑ってください。 ![エラーを回避するの参考 UI。電話番号欄。左は「ハイフンなしで」と注記してエラーを返す、右は同じ入力を受け付け、保存時に自動で正規化した値まで見せる](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-047-prevent-errors-not-messages.png) #### フールプルーフよりフェールセーフ 誤操作を起こさせない工夫がフールプルーフ、失敗しても被害の小さい側へ倒れる仕組みがフェールセーフです。製造現場のポカヨケは前者の代表格ですが、人の操作を封じきることはできません。管理画面の一括削除なら、ボタンを隠すよりも、削除を一定期間だけ取り消せる形にしておくほうが効きます。**禁止事項の数と復旧手段の数を並べて、前者ばかりが増えていないか**数えてみてください。 ![フールプルーフよりフェールセーフの参考 UI。顧客リストの一括削除。左はボタンを封じて「管理者だけが実行できます」、右は押せるままにし「30 日間はゴミ箱から戻せます」](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-048-failsafe-over-foolproof.png) #### エラー表示は建設的にする エラー後の画面には、何が起きたかを伝える仕事と、次の一手を示す仕事があります。同じ 10 原則は、エラーコードを使わず平易な言葉で問題を正確に指し示し、解決策まで示すべきだと整理しています。「入力内容に誤りがあります」とだけ出る赤字は、どの欄が何と衝突しているのかを利用者に探させています。該当欄の直下に「郵便番号は 7 桁の数字で入れてください」と書けているかを確かめてください。 ![エラー表示は建設的にするの参考 UI。会社名 + 郵便番号。左は上部に「入力内容に誤りがあります」だけ、右は上部で欄名を示し、該当欄を枠で囲って直下に直し方を置く](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-049-constructive-error-message.png) #### 可能性と確率を区別する 起こりうることと、実際によく起こることを、同じ重みで扱わないための戒めです。すべての可能性に確認ダイアログを立てると、利用者は中身を読まずに「はい」を押す習慣を覚え、本当に危険な一回でも手が止まりません。資料ダウンロードの入力ミスと、顧客データの一括削除を同じ強さで警告している画面は、起こる頻度と失う大きさの掛け算をしていません。警告を減らす作業は、危険な操作を目立たせる作業でもあります。 ![可能性と確率を区別するの参考 UI。資料 DL と顧客データ一括削除の対比表。左は両方「本当によろしいですか」、右は軽い方は確認なし + 取り消し、重い方だけ件数入力の強い確認](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-050-probability-not-possibility.png) #### ユーザーが入力したものはユーザーのもの 利用者が時間をかけて打ち込んだ文章は、打ち込んだ本人のものです。送信に失敗した瞬間に本文が消えるフォームも、編集中にセッションが切れて白紙に戻る管理画面も、この所有権を無視しています。エラーで画面を戻すなら**入力値を詰め直し、長文欄は下書きを一時保存し、登録済みのデータは書き出せるように**してください。要望欄のような長文は、二度目を書いてもらえない前提で守ります。 ![ユーザーが入力したものはユーザーのものの参考 UI。送信エラーで戻った長文欄。左は本文が消えてプレースホルダに戻る、右は入力値が詰め直され、下書きを自動保存している](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-051-input-belongs-to-user.png) #### 整合性を損なうような操作をユーザーに求めない 同じ値を二度入力させたり、片方だけ更新できてしまったりする操作を、利用者に押しつけない原則です。会社名を契約管理と請求先で別々に持っている管理画面が典型で、更新のたびに片側が古くなり、書類の社名が食い違います。矛盾を防ぐための手順が社内マニュアルに書き足されていたら、画面が果たすべき仕事を人に外注した合図だと考えてください。整合性の維持は、本来システム側の担当です。 ![整合性を損なうような操作をユーザーに求めないの参考 UI。取引先設定の会社名。左は契約管理と請求先に別々の入力欄があり片方が旧社名、右は請求先を参照表示にして自動反映](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-052-single-source-of-truth.png) #### エスケープハッチ どの画面からでも、途中でやめて元の場所へ戻れる出口を用意します。10 原則の 3 つめは、誤って入り込んだ状態から長い手続きなしで抜け出せる「非常口」を求め、戻る・キャンセル・閉じる・取り消しを具体例に挙げています。5 ステップの申し込みフォームで 2 ステップ目から前に戻れない作りは、非常口がない状態です。閉じる・戻る・ブラウザバックが効くかを、公開前に実機で押してください。 ![エスケープハッチの参考 UI。5 ステップ申し込みのステップ 2。左は「次へ」だけ、右は「戻る」と下線付きの「閉じる」を足し、やめても入力が残ると添える](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-053-escape-hatch.png) #### ガッツを見せる システムの側が簡単に音を上げない、という姿勢の話です。検索して「該当する結果はありません」とだけ返す画面は、一度の照合で降参しています。表記ゆれを吸収する、近い候補を出す、条件をひとつ外した結果を添えるといった粘りがあれば、利用者はもう一度そのサービスを使ってくれます。ゼロ件の画面や 404 の画面に次の一手が置かれていなければ、踏ん張りが足りていないと考えてください。 ![ガッツを見せるの参考 UI。管理画面の検索でゼロ件。左は「該当する結果はありません」で終わる、右は表記ゆれを吸収して 1 件出し、条件を外した件数まで添える](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-054-zero-results-persistence.png) #### ゼロ・ワン・インフィニティ 数を制限するなら 0 個・1 個・無制限のどれかにして、中間の半端な上限を作りません。プログラミング言語の設計論に由来する原則で、Bruce MacLennan が 1970 年代前半に定式化し、1983 年の著書に記しています (Wikipedia, 2026-08)。添付ファイルは 3 つまで、担当者は 5 人まで、といった上限は、6 人目が現れた日に壊れます。制限を置くなら、その数字の根拠を言えるかを確かめてください。 ![ゼロ・ワン・インフィニティの参考 UI。担当者の登録。左は「上限の 5 人に達しています」で追加ボタンが無効、右は上限なしで追加ボタンが押せる](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-055-zero-one-infinity.png) エラー設計の良し悪しは、うまく操作できたときの画面には出ません。わざと間違えて押したときに何が残っているかで決まるので、次の章も「うまくいかないとき」の目で読み進めてください。 ## 6. 反応・時間・状態遷移 — 待たせ方が体感品質を決める 「保存ボタンを押しても何も起きないように見えるので、みんな 3 回押している」。管理画面の運用でよく聞く話です。処理そのものは数秒で終わっていても、押した瞬間に画面が静止していれば、届いていないと判断されます。 原因は処理の遅さではなく、押した事実が画面に返っていないことにあります。体感の速さと実測の速さは、別々に設計できます。 反応が **0.1 秒以内なら人はシステムが即座に応じたと感じ、1 秒までは考えの流れが途切れず、10 秒を超えると注意が別のことへ移ります** (Nielsen Norman Group, 2026-08 取得。原典は Miller 1968 と Card ら 1991 の研究)。この章の 14 項目は、その境界のあいだをどう埋めるかを集めたものです。 ![操作からの経過時間 0.1 秒・1 秒・10 秒と、それぞれの段階で必要になる画面上の反応を並べた図](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-figure-03-response-time.png) #### ユーザーの操作に対して 0.1 秒以内に反応を返す 押した瞬間に、画面のどこかが目に見えて変わるようにします。0.1 秒以内に変化が返ると、人はシステムが即座に応じたと感じ、自分の手で動かしている実感を保てます。処理そのものに 1 秒かかっても構わないので、ボタンの見た目が沈む、ラベルが「送信中」に変わる、その反応だけを先に返してください。**押しても静止したままの画面は連打を招き、申込データの二重登録や自動返信メールの重複**という形で後から現れます。 ![ユーザーの操作に対して 0.1 秒以内に反応を返すの参考 UI。同じ資料 DL ボタンの「押した瞬間、0.1 秒後」 2 コマ。左は 0.1 秒後も黒ボタンのまま、右はグレー面の「送信しています」に変わる。処理時間 1.4 秒の帯は左右同一](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-056-respond-within-100ms.png) #### 操作の近くでフィードバックする 反応は、操作した場所のそばに出します。人の視線は押した指先やカーソルの周りに留まっているので、画面上端に出た通知バーは、色を変えたところで読まれないまま消えていきます。フォームの必須項目が空だったなら、ページの先頭にまとめるのではなく、その入力欄の真下に理由を置きます。エラーの件数だけを冒頭に出す作りは、どこを直せばいいのか分からず、入力し直す気力を奪ったまま離脱につながります。 ![操作の近くでフィードバックするの参考 UI。問い合わせフォームのメール欄。まったく同じ文言のエラー帯を、左は画面上端に、右は入力欄の真下に置いた。差分は位置だけ](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-057-feedback-near-the-action.png) #### 黙って実行する できる処理は、確認を挟まず静かに済ませます。「本当によろしいですか」を毎回出していると、読まずに OK を押す習慣が付き、いざ危険な操作のときにも確認として働きません。下書きの自動保存や検索条件の記憶は、告知なしで行い、結果だけを残せば十分です。取り消しがきく操作なら、確認ダイアログを出すより、あとから戻せる手段をひとつ用意しておくほうが、作業は速く進みますし事故も減ります。 ![黙って実行するの参考 UI。配信メールの下書き画面。左は「下書きを保存しますか」の確認ダイアログが本文に被る、右はたずねずに保存しヘッダ右に「3 分前に自動保存しました」だけ残す](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-058-act-silently.png) #### UI をロックしない 処理の間、画面全体を覆って操作を止めないようにします。CSV の書き出しに 30 秒かかるとしても、その間ユーザーが別の一覧を見たり検索したりできない理由はありません。進行中の処理は画面の一角に小さく表示し、終わったところで知らせる形にすれば、待っているあいだも別の仕事が進みます。半透明の膜が全面にかかるローディングを見つけたら、本当に画面全部を止める必要があるのか疑ってください。 ![UI をロックしないの参考 UI。問い合わせ一覧の CSV 書き出し中。同じ進捗表示を、左は全面を覆う膜の中央に、右は右下隅の小カードに逃がした。覆う範囲だけが違う](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-059-do-not-lock-the-ui.png) #### ユーザーが自分のペースで作業できるようにする 待ち時間も進み方も、システム側の都合で決めつけません。自動で切り替わるスライドショー、数秒で消える通知、時間切れで落ちる入力画面は、読むのが遅い人や途中で電話に出た人を切り捨てます。急がせないだけで、拾えるユーザーの幅は広がります。資料ダウンロードのフォームでセッションが 10 分で切れる設定になっていたら、入力途中の内容が消えていないか確かめてください。 ![ユーザーが自分のペースで作業できるようにするの参考 UI。資料 DL 申込フォーム上部の帯だけを変更。左は「残り 2 分 41 秒で入力内容が破棄されます」、右は「入力の途中でも、内容は保存されます」。入力欄と値は左右同一](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-060-let-users-set-the-pace.png) #### 回答の先送り すべての情報を最初に聞かず、必要になった時点で尋ねます。問い合わせフォームで従業員規模や予算を冒頭に置くと、答えに迷った人はそこで手が止まります。まず名前とメールで送信させ、詳細は次の画面や後日のメールで補えば、聞ける情報の量を保ったまま、途中離脱を抑えられます。入力欄が 10 個並んでいるなら、いま本当に必要なのはどれかを数え直してみてください。 ![回答の先送りの参考 UI。問い合わせフォームで最初に聞く項目数だけを変更。左は 4 欄 +「4 項目すべてが必須です」、右は 2 欄で送信でき「ご予算や規模は、返信メールでうかがいます」](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-061-defer-the-question.png) #### 即座の喜びを与える 価値を先に見せて、手続きは後に回します。診断ツールや見積もりシミュレーターで、結果を出す前にメール登録を求めると、まだ価値を知らない人は離れていきます。概算だけ先に画面へ出し、詳細版の送付先としてメールを聞けば、登録する理由が本人にとってはっきりします。自社のツールを開いてみて、**得られるものより先に負担が来る順序になっていたら**、前後を入れ替える余地があります。 ![即座の喜びを与えるの参考 UI。運用費用シミュレーター。同一の結果ブロックで、左は金額だけ伏せて「金額を見る」にメール登録を要求、右は「月額 12 万円 〜 18 万円」を先に出しメールは詳細版の送り先として聞く](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-062-value-before-the-ask.png) #### プリコンピュテーション 待ち時間になりそうな処理を、先に済ませておきます。次のページの画像を裏で読み込む、一覧の続きを先に取得しておく、といった準備をしておけば、ユーザーが操作した時点では表示するだけで済みます。BtoB サイトなら、ナビゲーションにカーソルが乗った時点で遷移先の読み込みを始めておく、資料ダウンロードの PDF を入力画面の表示中に用意しておく、といった使い方ができます。処理を速くするより、順番を前倒しするほうが効く場面は多くあります。 ![プリコンピュテーションの参考 UI。左が「つまずく例」、右が「直した例」。導入事例ページを開くまでの 2 レーン時間軸で、同じ 0.6 秒の読み込みバーがクリック後に始まる例と、カーソルが乗った時点に前倒しされて表示が早まる例を対比しました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-063-precomputation.png) #### ユーザーがとれる操作がひとつしかないなら自動化する 選択肢が実質ひとつしかない場面では、選ばせずに実行します。検索結果が 1 件だけなら一覧を挟まず詳細を開く、拠点がひとつなら拠点選択のプルダウンを出さない、選べる支払方法がひとつなら選択画面ごと省く、といった判断です。選ぶという行為そのものが、読んで理解して決めるという負担を発生させます。項目がひとつしかないセレクトボックスや、押す先がひとつしかない確認画面は、消す候補です。 ![ユーザーがとれる操作がひとつしかないなら自動化するの参考 UI。左が「つまずく例」、右が「直した例」。取引先の検索で結果が 1 件のとき、「詳細を見る」ボタン付きの一覧を挟む例と、そのまま詳細を開いている例を対比しました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-064-automate-single-option.png) #### データをバインドする 同じ数値が複数の場所に出るなら、片方を直したときもう片方も同時に変わるようにします。人が手で写し替えている限り、更新のたびに写し漏れの機会が生まれ、いつか食い違います。管理画面で単価を変更したのに合計金額が古いままだと、ユーザーはどちらの数字を信じればいいのか迷い、そこで操作を止めて問い合わせに回ります。更新ボタンを押さないと合計が変わらない画面や、一覧と詳細で在庫数が食い違う画面は、この原則が守られていない印です。 ![データをバインドするの参考 UI。左が「つまずく例」、右が「直した例」。見積編集で単価を 10,000 から 12,000 円に変えた直後、合計が 100,000 円のまま取り残される例と、120,000 円に追随している例を対比しました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-065-bind-the-data.png) #### 画面の変化をアニメーションで表す 要素が突然現れたり消えたりせず、動いて変わるようにします。人は画面のどこが変わったかを瞬時には把握できないため、予告なく切り替わった部分は見落とされます。一覧から 1 行を削除したときに、その行が縮んで消えていけば、どこが減ったのかを言葉なしで伝えられます。動きの長さは 100〜400 ミリ秒が目安で、500 ミリ秒に達すると動作そのものが煩わしく感じられます (Nielsen Norman Group, 2026-08 取得)。 ![画面の変化をアニメーションで表すの参考 UI。左が「つまずく例」、右が「直した例」。一覧から 1 行を削除する 3 コマ（押す前、0.1 秒後、0.3 秒後）で、中コマが完了状態に飛んでいる例と、対象行が縮んでいる途中が見える例を対比しました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-066-animate-the-change.png) #### トランジションは両方向につける 開くときに動くなら、閉じるときも動かします。開くのは滑らかなのに閉じるのは一瞬で消えるパネルは、同じ部品として認識されず、どこへ戻ったのか分からなくなります。往路と復路の動きを対にしておくと、いま自分がどの階層にいて、どこへ戻れば元の一覧にたどり着くのかを覚えていられます。モーダルやサイドメニューを作ったら、閉じる側の動きが省かれていないか確認してください。 ![トランジションは両方向につけるの参考 UI。左が「つまずく例」、右が「直した例」。サイドパネルの開閉を開くとき、閉じるときの 2 段 3 コマで表し、閉じる側の中コマだけが抜けている例と、往路と同じく途中が描かれている例を対比しました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-067-transition-both-ways.png) #### 動かしたままに動くのではなく動かしたいように動く 動きを設計するときは、物理的な正確さではなく、意図が伝わるかどうかを基準にします。等速で動くパネルは機械的に見えますが、はじめに速く動いて最後にゆっくり減速する動きは、手で押して止めたときのように自然に感じられます。実物の挙動を正しく再現しているかどうかは、ここでは問われません。動きに求められているのは、要素がどこから来てどこへ行ったのかを、説明文なしで理解させることです。 ![動かしたままに動くのではなく動かしたいように動くの参考 UI。左が「つまずく例」、右が「直した例」。パネル左端の位置を同じ間隔で撮った 6 コマの多重露光で表し、等間隔（等速）と終端に向けて詰まる（減速）を、開き始め・開ききった位置の目印つきで対比しました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-068-motion-shows-intent.png) #### ショートカットを用意する 同じ操作を一日に何度も繰り返す人には、近道を用意します。管理画面で毎日 100 件の申込を処理する担当者にとって、1 件あたり 3 クリックか 1 クリックかは、そのまま作業時間の差になります。キーボード操作、一括選択、前回の検索条件の再利用、よく使う絞り込みの保存などが該当し、どれも通常の導線を残したまま足せます。はじめて使う人の分かりやすさと、毎日使う人の速さは両立するので、片方だけを見て設計しないようにします。 ![ショートカットを用意するの参考 UI。左が「つまずく例」、右が「直した例」。未処理 100 件の申込一覧で行ごとの「承認」しかない例と、行の承認を残したままチェックボックス +「まとめて承認」を足した例を対比しました](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-069-shortcuts-for-repeat-work.png) ここに並べた原則は、処理を速くする話ではありません。待っている時間をどう扱うかの話で、サーバーに手を入れずに直せる箇所がいくつも含まれています。 ## 7. 画面の見せ方とレイアウト — 情報を減らさずに見た目を減らす 「ダッシュボードに指標を 20 個並べたら、誰も見なくなった」。管理画面のリニューアルで、担当者からよく聞く話です。 画面を見づらくしているのは、載せた情報の量ではありません。意味を持たない見た目の差が、画面のなかに多すぎることが原因です。 人は位置や色や太さの違いに意味を読み取るので、揃っていない余白はそのままノイズになります。**同じ意味のものは同じ見た目にして、差をつけるのは意味が違うところだけ**にします。この 1 本の方針で、この章の 14 項目はほとんど説明がつきます。 #### 整然とレイアウトする 要素の左端や幅、余白の刻みを、画面のなかで数種類に絞って揃えます。人は近さと並びで「これは同じ仲間だ」と判断するため、数ピクセルのずれが意味の差として伝わってしまいます。制作物を確認するときは、画面に縦線を 1 本引いてみてください。**見出し・本文・ボタンの左端が 3 か所以上でばらついていたら**、直すべきずれです。 ![整然とレイアウトするの参考 UI。左が「つまずく例」、右が「直した例」。サービス紹介の「導入までの流れ」で、見出し・本文 2 行・CTA の左端が 4 か所ばらつく状態と、破線ガイド上に 1 本で揃えた状態](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-070-align-to-one-edge.png) #### 色やフォントを使いすぎない 画面で使う色と文字サイズの種類を、あらかじめ決めた数に閉じ込めます。色や太さは「重要」「警告」「無効」といった意味の記号として働くので、種類が増えるほど記号としての力が落ちます。**強調色が 2 つ以上ある画面では、どちらが本当に押してほしいボタンなのか**利用者には判断できません。書体は 1 種類に絞り、文字サイズは見出しから注記まで段階を決め打つと、画面全体が落ち着きます。 ![色やフォントを使いすぎないの参考 UI。左が「つまずく例」、右が「直した例」。料金 3 プランの申し込みボタンが墨ベタ、太枠、グレー面の 3 通りに強調された状態と、おすすめ 1 枚だけ墨ベタで他は同じ細枠に統一した状態](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-071-limit-emphasis-styles.png) #### グラフィックのトーン＆マナーを揃える アイコン、図版、写真の作りかたを 1 つの流儀に統一します。線だけのアイコンと塗りつぶしのアイコンが混ざった画面は、それぞれが別の出どころを持つように見えて、まとまりを失います。資料ダウンロードのページでよくあるのが、配布素材のイラストと自社で作った図が同居している状態です。線の太さ、角の丸み、使う色の数、この 3 つを先に決めてから作り始めると崩れません。 ![グラフィックのトーン＆マナーを揃えるの参考 UI。左が「つまずく例」、右が「直した例」。資料ダウンロード一覧のアイコンが極細線、塗りつぶし、角なし極太線で混在した状態と、線幅 2px・角丸 3px に統一した状態](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-072-unify-graphic-style.png) #### データよりも情報を伝える 手元の数値をそのまま並べるのではなく、受け手が判断できる形に加工して見せます。人は数字そのものではなく、前と比べてどうか、目標に対してどうかを知りたがっています。管理画面でありがちなのが、今月の件数だけが大きく置かれていて、増えたのか減ったのか誰にも分からない状態です。差分・比率・基準線のどれかを添えるだけで、数値は情報に変わります。 ![データよりも情報を伝えるの参考 UI。左が「つまずく例」、右が「直した例」。管理画面の KPI タイル 3 枚が今月の件数だけの状態と、同じ件数の下に区切り線と前月比を添えた状態](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-073-data-into-information.png) #### プログレッシブ・ディスクロージャ 最初は主要な選択肢だけを見せ、詳細は求められたときに開きます。Jakob Nielsen が 2006 年に Nielsen Norman Group で整理した手法です。問い合わせフォームなら、必須項目を先に出して、任意の補足欄はたたんでおきます。すべてを最初から並べた画面は、はじめての人の手を止めるだけです。 ![プログレッシブ・ディスクロージャの参考 UI。左が「つまずく例」、右が「直した例」。問い合わせフォームで必須 3 件と任意 2 件が同じ見た目で 5 段並ぶ状態と、必須 3 件だけ出して任意 2 件を折りたたみ行にまとめた状態](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-074-progressive-disclosure.png) #### スクロール画面では続きがありそうに見せる 画面の下端で内容がきれいに終わっていると、利用者はそこがページの終わりだと判断します。次のブロックの上部をわずかに覗かせたり、区切り線を画面の途中で断ち切ったりして、続きの存在を伝えます。BtoB サイトのファーストビューを大きな画像で埋めて下端でぴたりと切ると、その下の実績や料金まで読んでもらえません。画面が短いスマートフォンほど、この差がはっきり出ます。 ![スクロール画面では続きがありそうに見せるの参考 UI。左が「つまずく例」、右が「直した例」。ファーストビューでヒーローが下端までぴたり収まる状態と、次セクションの見出しと事例カードの上端を clipPath で覗かせた状態](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-075-hint-more-below.png) #### プロパティの選択肢でプレビューを見せる 設定を選ばせる画面では、選択肢そのものに結果の見本を表示します。「ゴシック」「明朝」と文字で書かれても、どう変わるかは選んで戻すまで分かりません。メール配信ツールのテンプレート選択が名称の一覧になっていると、利用者は片っ端から開いて確認する作業を強いられます。色は色見本で、書体は書体見本で、レイアウトは縮小図で見せてください。 ![プロパティの選択肢でプレビューを見せるの参考 UI。左が「つまずく例」、右が「直した例」。メールテンプレート選択がラジオ + 名称だけの状態と、同じ 3 行の右端にレイアウトの縮小図サムネイルを添えた状態](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-076-preview-in-the-option.png) #### ハイライト表現は構成要素をひとつだけ変化させる 選択中や現在地を示すときは、背景色なら背景色だけ、太さなら太さだけを変えます。色も大きさも書体も同時に変えると、選ばれた項目が別の種類の要素に見えてしまい、並びの対応関係が読めなくなります。サイドメニューで選択中の項目だけ文字が大きくなっている作りは、この失敗にあたります。変えるのは 1 つ、というルールを先に決めておくと迷いません。 ![ハイライト表現は構成要素をひとつだけ変化させるの参考 UI。管理画面サイドメニューの現在地 — 左は選択項目だけ背景・文字サイズ・太さの 3 つが同時に変わり別部品に見える、右は背景の面だけを変え、大きさと太さは他項目と揃える](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-077-highlight-one-property.png) #### メニュー項目の位置を変化させない メニューの並び順を、利用頻度や状況に応じて動かさないようにします。使い慣れた人は項目名ではなく位置で覚えているので、順番が変わるたびに読み直しが発生します。よく使う項目を上へ自動で繰り上げる仕組みは、親切に見えて習熟を妨げます。今は選べない項目も、消さずに無効の見た目のままその場に残してください。 ![メニュー項目の位置を変化させないの参考 UI。一覧の操作ドロップダウンを管理者、担当者で並置 — 左は権限で「書き出し」が消えて「削除」が繰り上がる、右は無効の見た目で同じ場所に残し、削除の位置が動かない](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-078-menu-position-stable.png) #### ウェイファインディング 利用者が今どこにいて、どこから来て、次にどこへ行けるのかを画面の上で分かるようにします。Kevin Lynch が 1960 年の『The Image of the City』で論じた都市の「読み取りやすさ」と同じ話で、目印と道筋があれば人は迷いません。Web サイトならパンくず、現在地が分かるナビゲーション、フォームの残りステップ表示がこれにあたります。戻ったあとにどの画面が出るのか想像できない作りなら、直す対象です。 ![ウェイファインディングの参考 UI。資料 DL フォームの 2 ステップ目 — 左は現在地の手がかりが一切ない、右は 3 段階のステップ表示で、済んだ段階・今・この先が読める](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-079-wayfinding.png) #### ペンは紙の近くに置く 操作するための道具は、操作される対象のそばに置きます。離れていると視線とマウスが往復する分だけ手数が増え、どの行に対する操作なのかも曖昧になります。一覧表の編集ボタンが画面いちばん上のツールバーにしかない管理画面では、行を選んでから上に戻る往復が毎回発生します。行ごとの操作は行のなかに、全体の操作は全体の枠に置くのが基本です。 ![ペンは紙の近くに置くの参考 UI。リード一覧 — 左は「編集」が上部ツールバーにしかなく行選択→上へ戻る往復が要る、右は行のなかに「編集」を置き、ツールバーには全体操作の「一括書き出し」だけ残す](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-080-controls-near-the-object.png) #### 視覚的に何であるかを示し文字で説明する 形や色で何のことかを一瞬で伝え、その意味を文字で確定させます。絵記号は目に速く入るかわりに解釈の幅が広く、文字は正確なかわりに読む時間がかかります。両方を重ねると、互いの弱いところを補い合えます。アイコンだけが並ぶツールバーは、作った人以外に意味が伝わらないと考えてください。 ![視覚的に何であるかを示し文字で説明するの参考 UI。資料 DL 一覧のファイル形式 — 左は PDF、Excel、PowerPoint の文字だけ、右は書類アイコン（線・格子・塗り面で描き分け）を添え、形で当たりを付けて文字で確かめられる](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-081-visual-plus-label.png) #### パースエージョン 画面の作りかたは、人の行動を後押しする力を持ちます。B.J. Fogg が 2003 年の『Persuasive Technology』でこの領域を整理していて、推奨の初期値や進み具合の可視化がその道具にあたります。相手の得になる後押しなら設計、事業者の得のために判断を歪めるならダークパターンです。通信販売では、2022 年 6 月施行の改正特定商取引法が、最終確認画面での 6 項目の表示を義務づけ、誤認させる表示を禁じています。 ![パースエージョンの参考 UI。申し込みの最終確認 — 左はサポートパックが事前チェック済みで合計が 65,000 円、右は未チェックが初期値で、支払う総額 50,000 円をそのまま出す](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-082-persuasion-not-dark-pattern.png) #### ゲームを持ち込まない 作業のための画面に、遊びとしての仕掛けを持ち込まないようにします。ゲームは過程を楽しませるために難しさや演出を足しますが、業務では同じ足し算がそのまま手数と待ち時間に変わります。入力を終えるたびに祝福のアニメーションが挟まるフォームは、同じ作業を何十件も繰り返す担当者にとって邪魔でしかありません。動機づけが必要なら、進み具合を静かに示すところまでにとどめます。 ![ゲームを持ち込まないの参考 UI。リード連続登録 — 左は保存のたび星つき「12 件目の登録、達成です」バナー、右は「12、40 件を登録しました」と細い進捗バーだけの静かな表示](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-083-no-gamification-in-work.png) 見た目の差を意味の差だけに絞れば、情報を削らないまま画面は静かになります。次の章に進む前に、手元の画面に縦線を 1 本引いて、使っている色を数えるところから試してみてください。 ## 8. モバイルとアクセシビリティ — 「読めない・押せない」をなくす 「スマホだと申し込みボタンが押しづらいと言われるのですが、デザイン上は十分大きく見えるんです」。BtoB サイトのフォーム改善で、担当者からよく聞く話です。 押しづらさの原因は、ボタンの見た目の大きさではありません。指が触れて反応する範囲が、見えている面積より狭いことがほとんどです。文字や画像にだけリンクを張り、まわりの余白が反応しない作りになっていると、この差が生まれます。 この章の 11 項目は、設計者自身の指の太さ・視力・使用言語を基準にしないための点検リストです。 #### タッチ操作する要素の大きさは 7mm 以上にする 指で押す部分は、見た目ではなく実寸で決めます。Material Design はタッチターゲットの最低を 48×48dp、実寸にして約 9mm としています (2026-08 取得)。Apple の HIG は 44×44pt が最低のヒットターゲットです。WCAG 2.2 の達成基準 2.5.8 はレベル AA で 24×24 CSS px ですが、こちらは**マウスやペンも含む下限なので、スマホのボタンは 44pt / 48dp に合わせ**ます。 ![タッチ操作する要素の大きさは 7mm 以上にするの参考 UI。左が「つまずく例」、右が「直した例」。スマホ問い合わせフォームの送信ボタンで、48dp の接触面ガイド(破線)を両面に固定し、ボタン高さだけを 28dp → 48dp に変えて対比](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-084-touch-target-size.png) #### ホットスポットを広げる 見た目を大きくしなくても、指が反応する範囲だけなら広げられます。アイコンの周囲に透明な余白を持たせる、表の行全体をリンクにする、チェックボックスのラベル文字を押しても切り替わるようにする、といった作りです。広げた範囲どうしが接すると誤タップが増えるため、Material Design は隣り合う対象を 8dp 以上あけることも勧めています。資料ダウンロードの一覧で、リンク文字の上でしか指が反応しないなら、まだ広げる余地があります。 ![ホットスポットを広げるの参考 UI。左が「つまずく例」、右が「直した例」。資料ダウンロード一覧の 3 行で、網かけ＝指が反応する範囲と明示し、リンク文字だけの網かけ → 行全体の網かけへ、反応範囲の広さだけを変えて対比](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-085-expand-the-hotspot.png) #### ドリルダウンは上→下、左→右 階層を掘り下げる操作は、進む向きを画面の上でも一定にします。日本語の UI は上から下、左から右へ読み進むので、掘り下げた先を下か右に置くと、いま何段目にいるかが位置で分かります。管理画面のメニューでサブ項目が親の上に開いたり、右から左へ展開したりすると、読む順序と進む順序がねじれます。パンくずの並びも同じ向きに揃えておくと、戻る道筋を見失いません。 ![ドリルダウンは上→下、左→右の参考 UI。左が「つまずく例」、右が「直した例」。管理画面サイドメニューで「設定」を開いたとき、サブ項目が親の上に出る／親の下に一段下げて出る、と展開方向だけを変えて対比](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-086-drilldown-direction.png) #### 左が戻るで右が進む 前後に動くボタンは、左を戻る、右を進むで固定します。横書きの UI では時間の流れを左から右に置く感覚が働きますし、スマホの左端スワイプで前の画面に戻る挙動もこの向きに揃っています。画面ごとに並びが入れ替わると、読み手は毎回ボタンの文字を読み直すことになります。問い合わせフォームの確認画面で「入力内容を修正する」が右、「送信する」が左に並んでいたら、押し間違いの温床になっています。 ![左が戻るで右が進むの参考 UI。問い合わせ確認画面で「送信する」と「入力内容を修正する」の左右配置だけを入れ替えて対比](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-087-back-left-next-right.png) #### モバイルでは包括的より階層的に 1 画面にすべてを並べる作りより、段階的に潜らせる作りのほうが狭い画面には向きます。スマホは横に情報を置けないぶん、選択肢を一度に見せると縦に長いリストになり、端から端まで目で走査する手間が増えるからです。潜る回数が増えるほど離脱も起きるので、資料ダウンロードのような導線は階層の底に埋めません。PC のグローバルナビをそのまま縦に積んで 20 行のメニューにしているなら、上位カテゴリでいったん受け止める設計に組み直します。 ![モバイルでは包括的より階層的にの参考 UI。左が「つまずく例」、右が「直した例」。スマホのグローバルナビで、PC のナビをそのまま積んだ全 20 項目のフラットな長いリスト(画面外へ切れる)／上位 5 カテゴリで受け止め資料 DL を最初の画面に出す](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-088-hierarchy-over-breadth.png) #### 音声読み上げに対応する 画面を見ずに音で操作する人にも、同じ情報が届くようにします。WCAG 2.2 は、画像などへの代替テキストを達成基準 1.1.1 で、部品の名前と役割をプログラムから判別できることを 4.1.2 で、どちらもレベル A として求めています。div にクリック処理を付けただけのボタン、alt のない図版、ラベルと結び付いていない入力欄は、読み上げでは素通りするか、意味の取れない音になります。外注しているなら、この 3 点を検収項目に入れてください。 ![音声読み上げに対応するの参考 UI。「画面の要素／読み上げられる内容」の対照表で、画面側は左右同一のまま、入力欄・図版・ボタンの読み上げ結果だけを変えて対比(見た目では差が出ないことを示す)](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-089-screen-reader-support.png) #### 文字の拡大に対応する 読み手が文字を大きくしても、内容と機能が欠けないようにします。WCAG 2.2 は、支援技術なしで 200% まで拡大できることを達成基準 1.4.4 に、幅 320 CSS px 相当で縦横 2 方向のスクロールが要らないことを 1.4.10 に置き、いずれもレベル AA としています。**ブラウザのズームを 200% にして、ボタンの文字が枠からはみ出したり**横スクロールが出たりするなら、高さや幅を固定しすぎている合図です。 ![文字の拡大に対応するの参考 UI。左が「つまずく例」、右が「直した例」。文字 200% の問い合わせフォームで、ラベルと入力欄を横並びにした固定幅 2 列は入力欄の右端が切れて横スクロールバーが出る、1 列に折り返して収まり横スクロールが消える](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-090-text-resize-200.png) #### 色に依存させない 色の違いだけで意味を伝えない、という原則です。WCAG 2.2 は達成基準 1.4.1 のレベル A、つまり最低限の要件に置いていて、色覚特性のある人に限らず、屋外の強い光の下や白黒印刷でも効いてきます。フォームのエラーを赤字だけで示していたり、グラフの系列を色の凡例だけで見分けさせていたりしたら、文言・記号・線の種類のどれかを足してください。見分けがつくかは、**画面をグレースケール表示に切り替えれば数秒で判定でき**ます。 ![色に依存させないの参考 UI。左が「つまずく例」、右が「直した例」。リード一覧のステータス列が丸の濃淡だけで凡例なしには読めない、同じ丸に「対応中・未対応・完了」の文字を添える](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-091-not-color-alone.png) #### ◯✕△等の記号を安易に使わない 記号は短くて便利ですが、意味の読み取り方が読み手ごとに割れます。日本では◯が可、✕が不可、△が条件付きという了解がありますが、英語圏で正を表すのはチェックで、記入欄の✕は「ここを選んだ」の意味にも読まれます。音声読み上げでも記号の名前が読まれるだけで、対応の可否までは伝わりません。サービス比較表で△を使うなら凡例を添え、できれば「一部対応」と文字で書くほうが確実です。 ![◯✕△等の記号を安易に使わないの参考 UI。左が「つまずく例」、右が「直した例」。プラン対応表のセルが丸・三角・バツの記号だけで条件付きの中身が伝わらない、「対応・一部対応・非対応」と文字で書く](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-092-symbols-need-words.png) #### アイコンのモチーフは特定の文化に依存させない 絵柄が通じるかどうかは、読み手の生活習慣に左右されます。郵便ポストや家の形は国ごとに違いますし、親指を立てる仕草は地域によって侮辱と受け取られます。フロッピーディスクで保存を表す例のように、実物を知らない世代には由来の伝わらない絵柄もあります。英語版と同じ画像を使い回す前提があるなら、通貨記号や〒のような国内固有のモチーフを避け、アイコンには短いラベルを添えておくと安全です。 ![アイコンのモチーフは特定の文化に依存させないの参考 UI。英語版と共有するツールバーがフロッピー・郵便ポスト・〒、下向き矢印と受け皿・吹き出し・地図ピンに差し替え（ラベルは左右同一、モチーフだけ変更）](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-093-icon-motif-culture.png) #### 多言語化を想定した UI ではラベルの長さの違いを考慮する 同じ意味でも、言語が変われば文字数は大きく変わります。W3C の国際化ガイドは、英語から欧州言語へ訳すと、元が 10 文字以下なら 200〜300%、70 文字を超える文でも 130% ほどに伸びるという目安を示しています (W3C Internationalization、2026-08 取得)。ボタンやタブの幅を日本語の文字数ぴったりに切っていると、英語版で表示が崩れます。伸びしろを見込んだ可変幅にしておけば、翻訳のたびに作り直さずに済みます。 ![多言語化を想定した UI ではラベルの長さの違いを考慮するの参考 UI。左が「つまずく例」、右が「直した例」。日本語の文字数ぴったりに切った固定幅タブは英語版で Overview、Team members、Billing address が切れる、内容に合わせて広がる可変幅にすると両言語とも収まる](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-094-label-length-i18n.png) ここまでの 11 項目は、実機を 1 台手に取り、ブラウザのズームを 200% にするだけで大半が確認できます。次の章でも、作り手の手元だけで良し悪しを決めないという姿勢が効いてきます。 → コントラスト比とタップ領域の実測には、巻末の実行キット①の数値基準がそのまま使えます。 ## 9. 道具としての思想 — 誰の作業を、誰のものにするか 「操作を覚えてもらうために、初回チュートリアルを 12 画面つくりました」。管理画面を作り直すときに、よく出てくる打ち手です。ここまでの 8 章では画面の組み立て方を見てきましたが、この章で扱うのは、その画面が誰のものかを決める 6 つの基準です。 チュートリアルが厚くなるのは、画面が使う人の手に馴染んでいないサインです。 原因は説明が足りないことではなく、画面の主語が提供側になっていることにあります。 #### ユーザーの道具にする 画面は、使う人が自分の仕事を片づけるための道具です。提供側の都合を通す場所ではありません。管理画面に運営側の見たい数字を並べたり、資料ダウンロードのフォームに営業が欲しい項目を足したりすると、ひと続きで終わるはずの作業が遠回りになります。**要素をひとつずつ指さして「これは誰の得ですか」と聞き**、提供側の得しか出てこない要素が並んでいたら疑ってください。 ![ユーザーの道具にするの参考 UI。資料 DL フォームの項目に「誰のためか」列を添え、左は送る側都合の 2 項目まで積んだ 5 項目、右は届けるのに要る 3 項目だけ残して予算と時期は返信で聞く形にした](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-095-tool-for-the-user.png) #### ユーザーが自分なりの方法で作業を遂行でき、それを改善できるようにする 同じ業務でも、段取りは会社ごと人ごとに違います。手順を 1 本道に固定すると、その道から外れた人の作業が一気に重くなります。一覧の絞り込み条件を保存できる、CSV でまとめて登録できる、といった逃げ道を残しておくと、使い込んだ人ほど速く終わらせられます。ウィザード形式しか用意されていない画面は、**毎日何十件も処理する担当者にとって、最初の一週間だけ親切な設計**です。 ![ユーザーが自分なりの方法で作業を遂行でき、それを改善できるようにするの参考 UI。リード登録ウィザードの 4 ステップと「次へ進む」は左右とも同じで、右にだけ「CSV でまとめて登録」の近道を並べ、1 本道か逃げ道つきかだけを対比させた](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-096-let-users-find-their-way.png) #### ユーザーを教育するのではなくユーザーが学習できるようにする 人は説明を読んで覚えるのではありません。やってみて、結果を見て覚えます。初回に 12 画面のチュートリアルを流しても、実際に操作するころには忘れていますから、押す前に何が起きるかを想像できる一行をボタンの横に置くほうが効きます。改善案として**「操作説明の動画をつくりましょう」が最初に出てきたら、画面そのものが説明を必要としている合図**です。 ![ユーザーを教育するのではなくユーザーが学習できるようにするの参考 UI。配信ボタン横の同じ位置で、左は初回だけ出る「チュートリアル 3、12」の吹き出し、右は常設の一行「登録済みの 342 件に、いますぐ送信します」を対比](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-097-learn-by-doing-not-tutorial.png) #### ユーザーイリュージョンをもたらす 使う人が向き合っているのは、デスクトップやゴミ箱のような比喩でできた、一貫した見立ての世界です。Xerox PARC で GUI をつくった Alan Kay は、この状態をユーザーイリュージョンと呼びました。「下書き・公開・アーカイブ」で通していた画面に急に「ステータス 3」と出てくれば、その世界は破れます。文言だけを抜き出して読み返すと、社内用の言葉が漏れている箇所が見つかります。 ![ユーザーイリュージョンをもたらすの参考 UI。記事一覧の状態列は左右とも「公開、下書き、アーカイブ」。通知バーだけが左は「ステータス 3 に変更しました」、右は「アーカイブに変更しました」で見立てが途切れない](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-098-user-illusion.png) #### デザインは新しい意味を提案する 使いやすさを磨く仕事の隣に、それが何であるかを提案し直す仕事があります。Roberto Verganti は 2009 年の著書『Design-Driven Innovation』で、これを意味のイノベーションとして整理しました。問い合わせフォームを「営業に捕まる場所」から「相談を整理して持ち帰れる場所」へ読み替えると、置く項目も文言も送信後の画面も変わります。使う人に聞いて出てくる答えではないので、こちらが仮説を立てて差し出す仕事になります。 ![デザインは新しい意味を提案するの参考 UI。概念系のため対比図。墨帯「この画面は何をする場所か」だけを左「営業が連絡先を受け取る場所」、右「相談を整理して持ち帰る場所」に変え、項目・ボタン文言・送信後がその帰結として並ぶ](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-099-propose-new-meaning.png) #### 人類にポジティブな影響を与える 設計の影響は、その画面を使う人だけで終わりません。ISO 9241-210:2019 は人間中心設計を、人の健やかさ、満足、アクセシビリティ、持続可能性を高め、健康や安全への悪影響を打ち消す取り組みだと説明しています。同じ規格が「利用者中心」ではなく「人間中心」という語を選んだのも、利用者以外の関係者への影響まで含めるためです。解約の導線を隠したり、同意を取ったことにしたりすれば短期の数字は上がりますが、外で説明できない設計は誰かに不利益を押しつけています。 ![人類にポジティブな影響を与えるの参考 UI。契約とお支払い画面の 4 行目だけを対比。左は解約が行から外れて「サポート窓口までお電話ください」の小さな注記、右は「契約を解約する」がほかの手続きと同じ並びにある](https://humbulls.com/hubfs/blog-figures/ui-ux-design-principles-100-100-positive-impact-on-humanity.png) 9 カテゴリ 100 項目は、言い方こそ違っても同じ一点に帰っていきます。使う人が背負うはずだった手間を、つくる側がどこまで引き受けるのかということです。発注レビューでも自己点検でも、迷ったらこの物差しを最後に当ててください。 ## まとめ 100 項目を暗記する必要はありません。レビューの場で要るのは、気になった箇所に原則の名前をひとつ付けられることです。**名前が付いた瞬間に、指摘は好みの話から直せる話に変わり**ます。 手を付ける順番も決まっています。**読めない・押せないを先に潰し (第 8 章)、次に入力の設問を減らし (第 4 章)**、そのあとで待ち時間と見た目に移ります (第 6・7 章)。 直したときに数字が動く順番も、だいたいこの順です。 まずは 1 画面だけ選び、この記事を横に置いて通しで当ててみてください。粒のそろった指摘一覧が、その日のうちにできあがります。 → 点検結果を制作会社に渡す形にまとめるところまでは、巻末の実行キット③で作れます。 あわせて読みたい記事を 3 本挙げておきます。 - [BtoB ペルソナの作り方](https://humbulls.com/knowledge/btob-persona-ai-30min?hsLang=ja) — 第 2 章「ユーザーの言葉を使う」を、実際の語彙リストに落とすところまで - [OGP 画像の参考サイト 5 選](https://humbulls.com/knowledge/ogp-image-reference-sites?hsLang=ja) — 第 7 章のトーン＆マナーを、SNS で共有される画面まで広げる話 - [サービスサイトの段階公開](https://humbulls.com/knowledge/phased-service-site-launch?hsLang=ja) — 100 項目を一度に満たそうとせず、公開しながら直していく進め方 humbulls の [Growth Partner](https://humbulls.com/services/growth-partner?hsLang=ja) では、画面の点検から改善の実装、効果の計測までを伴走しています。自社サイトのどこから直すべきかを一緒に決めたい場合はご相談ください。 ## 🤖 AI 実行キット 本文の判断を、そのまま AI で実行するためのキット集です。プロンプトは Claude (ブラウザ版で可) にコピペすれば動きます。100 項目を暗記する必要はありません。画面を渡して、関係する原則だけを引かせるのがこのキットの役割です。 ### キット① いま作っている画面を、関係する原則だけで自己点検する — 20 分 種別 判断キット 使うもの Claude (ブラウザ版で可)。画像を添付できるチャットであれば同じように動きます 事前に用意するもの 点検したい画面のスクリーンショット 1〜3 枚。デザインカンプの書き出しでも、公開中のページを撮ったものでも構いません。HTML をそのまま貼り付けても動きます #### プロンプト ``` いま作っている画面を、UI 設計の原則にもとづいて点検してください。 【対象画面】 - 画面の種類: 問い合わせフォーム(記入例。「一覧・検索画面」「ダッシュボード」「サービス紹介 LP」「管理画面の設定ページ」などから選ぶ) - 誰が使うか: 初めて訪問した見込み客。PC 6 割・スマホ 4 割(記入例) - この画面で完了してほしいこと: 問い合わせを送信し、完了画面まで到達すること(記入例) - 添付: スクリーンショット(画像を添付。HTML を貼る場合はこの下に貼る) - 画面に書かれている文言(OCR に頼らず、コピペで貼る): - (見出し・ラベル・ボタン文言・注意書きをそのまま貼り付け) - 補足(スクショに写らない挙動があれば書く): - 送信ボタンを押してから完了画面が出るまで約 4 秒かかります(記入例) 【絞り込み基準(必ずこの基準に従うこと)】 9 カテゴリの原則があります。画面の種類によって、見るべきカテゴリと見送るカテゴリが変わります。 まず、この画面で見るカテゴリを選び、その理由を 1 行ずつ書いてください。 A 全体設計(何を減らすか、主導権を誰が持つか) … 全画面で見る B 認知(メンタルモデル / 見た目が操作方法を語っているか / 近接・整列によるまとまり) … 全画面で見る C オブジェクトと操作(対象を選んでから操作を選ぶ順序になっているか) … 一覧・管理画面で見る。LP では見送る D 入力とフォーム(設問数 / 順序 / デフォルト値 / 前提条件の提示) … フォームを含む画面で見る E エラーと安全設計(そもそも起こさせない / 起きても壊れない / エラー文が次の行動を示す) … 入力・削除・課金がある画面で見る F 反応と時間(操作から 0.1 秒以内の反応 / 待ち時間の見せ方 / 画面を固めない) … 通信や保存がある画面で見る G レイアウト(整列 / 色とフォントの数 / データではなく情報を見せているか) … 全画面で見る H モバイルとアクセシビリティ(押せる大きさ / 文字と背景のコントラスト / 進む・戻るの方向) … 全画面で見る I 道具としての思想(利用者が自分の手順を作れるか) … 繰り返し使う業務画面で見る。単発の LP では見送る 【判定に使う数値基準(必ずこの基準に従うこと)】 - 本文と背景のコントラスト比が 4.5:1 未満なら「読めない」と判定する(WCAG 2.2 SC 1.4.3、レベル AA) - 押せる要素が 24×24 CSS ピクセル未満なら「押せない」と判定する(WCAG 2.2 SC 2.5.8、レベル AA)。 指で操作する前提の画面では 44×44 CSS ピクセルを目標値として扱う(同 SC 2.5.5、レベル AAA) - 操作から反応までが 1 秒を超えるなら進捗表示が要る、10 秒を超えるなら残り時間か中断手段が要る、と判定する - 1 画面で使っている文字色・書体・文字サイズの種類が数えて 10 種類を超えたら「使いすぎ」と判定する 【出力】 1. この画面で見るカテゴリと、見送るカテゴリ(各 1 行の理由つき) 2. 指摘の表。列は「原則の名前 / 画面のどこか / 何が起きるか / 重大度(高・中・低)」 - 「画面のどこか」は、要素名か画面上の文言をそのまま書く。「全体的に」は使わない - 「何が起きるか」は、利用者に起きる困りごとで書く。原則名の言い換えにしない 3. 逆に、この画面でよくできている点を 3 つ ``` #### 出力の確認ポイント - 絞り込んだ原則が 15〜25 個に収まっているか。9 カテゴリ 100 項目をそのまま並べてきたら、絞り込みが効いていません - 指摘の「画面のどこか」が、要素名か実際の文言を指しているか。場所を特定できない指摘は捨ててかまいません - 重大度「高」が 3 件以内か。半分以上が「高」なら、基準を無視して全部を重く見ています #### うまくいかないとき - カテゴリ F の指摘が空になる。スクリーンショットには待ち時間が写らないためです。「送信後に 4 秒かかる」「保存の完了表示がない」を補足欄に文章で書き足してください - 指摘が一般論になる。画面の文言をテキストでも貼ると直ります。画像だけだと細部の文字を読み違えます ### キット② 問い合わせフォームの設問を 4 分類して減らす — 15 分 種別 判断キット 使うもの Claude (ブラウザ版で可) 事前に用意するもの いま公開しているフォームの設問リスト。フォーム管理画面のスクリーンショットでも、画面をそのままコピペしたテキストでも動きます #### プロンプト ``` 問い合わせフォームの設問を棚卸ししてください。 【いまのフォーム】 - 目的: 資料請求と個別相談の受付を兼ねている(記入例) - 受け取ったあとの一次対応: 営業担当が 1 営業日以内にメールで返信する(記入例) - 月間の送信数と離脱の実感: 送信 12 件。入力を始めて途中でやめる人が多い印象(記入例。数字が分からなければ「未計測」と書く) - 設問リスト(上から画面に並んでいる順に、必須かどうかも書く): 1. 会社名(必須)(記入例) 2. 部署名(必須)(記入例) 3. 役職(必須)(記入例) 4. お名前(必須)(記入例) 5. メールアドレス(必須)(記入例) 6. 電話番号(必須)(記入例) 7. 従業員数(必須・プルダウン 8 段階)(記入例) 8. 年商(任意・プルダウン)(記入例) 9. 現在お使いのツール(任意・自由記述)(記入例) 10. ご相談内容(必須・自由記述)(記入例) 11. 弊社を知ったきっかけ(必須・プルダウン)(記入例) 【分類基準(必ずこの基準に従うこと)】 設問を 1 問ずつ、次の 4 つのどれかに分類してください。 残す: この回答の内容によって、一次対応のやり方か担当者が変わる設問 統合する: 別の設問と同じ判断材料になっている設問、または後工程(商談・ヒアリング)で必ず聞き直している設問 デフォルトで埋める: 流入元・送信日時・閲覧ページなど、本人に聞かなくても取得できる情報 削る: 集計や社内報告のためだけに置かれている設問。空欄でも一次対応が成立するもの 【並び順と必須の基準(必ずこの基準に従うこと)】 - 手元の資料を見ないと答えられない設問(従業員数・年商・契約中のツール名など)は、先頭に置かない。 聞く場合は「なぜ必要か」を 1 行添える - 必須にしてよいのは「これが空欄だと返信そのものができない」設問だけ - 選択肢が 2〜3 個の設問はプルダウンにせず、選択肢を画面に見せる形に変える - 自由記述は 1 問まで。2 問以上あれば統合する - 分類のあと、必須設問の数が元の半分以下になっていない場合は、基準を当て直してやり直す 【出力】 1. 設問ごとの表。列は「現在の設問 / 分類 / そう判断した理由 / 変更後の文言(残す・統合する場合)」 - 理由は「一次対応の何が変わるか」で書く。「あると便利」は理由として認めない 2. 変更後の設問リスト(画面に並べる順で、必須か任意かを付ける) 3. 設問数と必須数が、変更前後で何問から何問になったか ``` #### 出力の確認ポイント - 「残す」の理由が、一次対応の分岐で書かれているか。「ターゲット判定に使うため」だけでは弱く、それは商談で聞けます - 変更後の必須設問が 5 問以内に収まっているか。超えていたら基準の当て方が甘くなっています - 変更後の文言が、そのまま画面に置ける日本語になっているか。設計メモのような書き方なら書き直させてください #### うまくいかないとき - ほとんどが「残す」になる。「必須の合計を現状の半分以下にすること」を条件に足して、もう一度流してください - 業種の事情で外せない設問まで削られる。「この設問は審査要件で必須」と注記を添えて渡すと、分類から除外されます ### キット③ 制作会社に渡す UI レビュー指摘書を作る — 30 分 種別 実装キット 使うもの Claude (ブラウザ版で可)。表計算ソフトに貼るなら、出力形式に CSV を追加で指定します 事前に用意するもの キット①②の出力。まだ無い場合は、気になった点の箇条書きメモでも動きます。「フォームが長い」「スマホでボタンが押しにくい」程度の粒度で構いません #### プロンプト ``` 制作会社に渡す UI レビュー指摘書を作ってください。 【前提】 - 対象: 自社サイトのリニューアル案(記入例。「管理画面の改修」「LP の初稿」なども可) - 渡す相手: 外部の制作会社のディレクター。UI の専門用語は通じるが、当社の業務は知らない(記入例) - 次のマイルストーン: 2 週間後の第 2 稿提出(記入例) - 手元の指摘メモ(粒度はバラバラで構わない): - (キット①②の出力を貼り付け、または自分のメモを貼り付け) 【優先度の基準(必ずこの基準に従うこと)】 P1: そのままでは作業を完了できない。または誤操作でデータが消える。または読めない・押せない。 文字と背景のコントラスト比が 4.5:1 未満、押せる要素が 24×24 CSS ピクセル未満は無条件で P1 とする P2: 完了はできるが、迷いや入力のやり直しが発生する P3: 見た目の統一や語調の問題。作業の成否には影響しない 【書き方の基準(必ずこの基準に従うこと)】 - 1 行 1 指摘。ひとつの行に複数の問題を混ぜない - 「なぜ問題か」は原則名の言い換えにせず、その画面で利用者に起きることで書く - 「直し方」は案を 1 つに絞って書き切る。「〜を検討してください」で終えない - 主観語(きれいに / モダンに / いい感じに / スタイリッシュに)を使わない - 実装の重さが判断できない指摘には「要相談」と書き、工数や日数を推測して書かない - 相手の力量を評価する表現を書かない。事実 → 影響 → 提案の順で書く 【出力】 1. 冒頭サマリー 3 行(P1 の件数 / 最も影響が大きい 1 件 / 第 2 稿で優先して直したい範囲) 2. 指摘表。列は「原則の名前 / 現状 / なぜ問題か / 直し方」。行の先頭に優先度と対象画面を付ける 3. 同じ内容の CSV(1 行目はヘッダー、区切りはカンマ) 4. 今回は指摘しないと決めた項目と、その理由(3 件まで) ``` #### 出力の確認ポイント - P1 が「使えない」ものだけになっているか。好みの問題が P1 に紛れていたら P3 に落としてから渡します - 「直し方」が 1 案に絞られているか。選択肢を並べた指摘書は、そのまま差し戻しの往復になります - 原則の名前を知らない相手が読んでも、現状と直し方だけで意味が通るか #### うまくいかないとき - 指摘が抽象的なまま出てくる。「各行に対象画面と要素名を必ず入れる」を条件に足してください - 相手を責める調子になる。「事実 → 影響 → 提案の順で書き直してください」と指示すると整います ## 参考文献 - [Response Times: The 3 Important Limits](https://www.nngroup.com/articles/response-times-3-important-limits/) — Nielsen Norman Group (取得: 2026-08) - [Understanding SC 2.5.8: Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) — W3C WAI / WCAG 2.2 (取得: 2026-08) - [Accessibility — Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/accessibility) — Apple (取得: 2026-08) - [Touch Target](https://m2.material.io/develop/web/supporting/touch-target) — Material Design (取得: 2026-08) - [10 Usability Heuristics for User Interface Design](https://www.nngroup.com/articles/ten-usability-heuristics/) — Nielsen Norman Group (取得: 2026-08) - [Understanding SC 1.4.1: Use of Color](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html) — W3C WAI / WCAG 2.2 (取得: 2026-08) ![栗田一輝](https://humbulls.com/hs-fs/hubfs/square_humbulls-kazukikurita-profile-pics.jpg?width=216&name=square_humbulls-kazukikurita-profile-pics.jpg) Author 栗田一輝 humbulls 代表 / B2B マーケ × AI 活用の 設計・実装・運用支援。 [![AI × BtoBマーケティング完全ガイドをダウンロードする（無料）](https://hubspot-no-cache-na2-prod.s3.amazonaws.com/cta/default/22817028/interactive-375238103746.png)](https://cta-na2.hubspot.com/web-interactives/public/v1/track/redirect?encryptedPayload=AVxigLIMhaUO2JQVVs58hAgG6EsuOfdd9hwLFHdC3ozLH9m%2Fzg3b%2BJOPlB328AGLWKzWs5WNNcgL1A%2B2RJcGeu%2Bw3%2BfycdFvYvXSEOs3WOdgtwBTU7l2HYh%2F5wfmtyXTBen4EoU%2BVW6RZARNqh9b69Cyf4ljsS8%2Fzu1jt3NmIsnpxp7B&webInteractiveContentId=375238103746&portalId=22817028) [![運営会社 humbulls — サービスサイトへ](https://hubspot-no-cache-na2-prod.s3.amazonaws.com/cta/default/22817028/interactive-375237823210.png)](https://cta-na2.hubspot.com/web-interactives/public/v1/track/redirect?encryptedPayload=AVxigLKYg6hR5LiZFPsrbBca%2FLFTvPAkaTn1qlM8rxRiYIg7%2F1CM12t5O08MhzH6MfV03yw3hEzanzjJtyPBLX24i9vRj9xtGx6w%2BiSUY3Ml5IZVuKzAQ0Q%2BfvMMpxxqd%2BU3x%2BhaYc%2BIBFPsEYEdy0JsxSIxDBzhYdV6&webInteractiveContentId=375237823210&portalId=22817028) ## こんな記事も読まれています - ### [![AI リテラシーの 4D — プロンプトは、4 分の 1 の内側にある](https://humbulls.com/hubfs/blog-covers/cover-ai-literacy-4d-framework.png) KNOWLEDGE 2026.8.20 AI リテラシーとは — 4D フレームワークで整理する 6 つの失敗と直し方](https://humbulls.com/knowledge/ai-literacy-4d-framework?hsLang=ja) - ### [![CMS はもう不要か — サイト運用を 5 層に分けて判断する](https://humbulls.com/hubfs/blog-covers/cover-cms-necessity-ai.png) KNOWLEDGE 2026.8.16 CMS はもう不要か — サイト運用を 5 層に分けて判断する](https://humbulls.com/knowledge/cms-necessity-ai?hsLang=ja) - ### [![EmDash とは？Cloudflare の WordPress 後継 CMS を機能比較で解説](https://humbulls.com/hubfs/blog-covers/cover-emdash-vs-wordpress.png) KNOWLEDGE 2026.8.15 EmDash とは？Cloudflare の WordPress 後継 CMS を機能比較で解説](https://humbulls.com/knowledge/emdash-vs-wordpress?hsLang=ja) - ### [![GA4 で BtoB サイトのリード計測 — イベント設計から設定まで 2 時間](https://humbulls.com/hubfs/blog-covers/cover-ga4-btob-lead-tracking.png) KNOWLEDGE 2026.8.6 GA4 で BtoB サイトのリード計測 — イベント設計から設定まで 2 時間](https://humbulls.com/knowledge/ga4-btob-lead-tracking?hsLang=ja) - ### [![ChatGPT 広告とは — 日本でいつから・仕組み・費用・出稿方法を解説](https://humbulls.com/hubfs/blog-covers/cover-chatgpt-ads.png) KNOWLEDGE 2026.7.31 ChatGPT 広告とは — 日本でいつから・仕組み・費用・出稿方法を解説](https://humbulls.com/knowledge/chatgpt-ads?hsLang=ja) - ### [![HubSpot Starter 完全ガイド — 機能・制限・活用の全ノウハウ](https://humbulls.com/hubfs/blog-covers/cover-hubspot-starter-guide.png) KNOWLEDGE 2026.7.31 HubSpot Starter 完全ガイド — 機能・制限・活用の全ノウハウ](https://humbulls.com/knowledge/hubspot-starter-guide?hsLang=ja) [humbulls](https://humbulls.com/?hsLang=ja) マーケティングの「実務」を、毎週 humbulls から。 [サービスサイト](https://humbulls.com/?hsLang=ja) [ナレッジ](https://humbulls.com/knowledge?hsLang=ja) [セミナー](https://humbulls.com/event?hsLang=ja) [資料DL](https://humbulls.com/download?hsLang=ja) [お問い合わせ](https://humbulls.com/contact?hsLang=ja) © 2026 humbulls — [Legal & Privacy](https://humbulls.com/legal?hsLang=ja) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "栗田一輝", "url" : "https://humbulls.com/knowledge/author/kazukikurita" }, "dateModified" : "2026-08-20T12:22:31.197Z", "datePublished" : "2026-08-20T12:22:31.000Z", "headline" : "UI/UX 設計の原則 100 項目 — 9 カテゴリで引ける大全｜humbulls", "image" : [ "https://humbulls.com/hubfs/blog-covers/cover-ui-ux-design-principles-100.png" ], "mainEntityOfPage" : { "@id" : "https://humbulls.com/knowledge/ui-ux-design-principles-100", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://humbulls.com/hubfs/brand/logo-black-lockup.png" }, "name" : "株式会社humbulls" } } ```