UI/UX 設計の原則 100 項目 — 9 カテゴリで引ける大全

本記事のポイント

• UI の良し悪しはセンスではなく、名前の付いた原則で説明できます。本記事は人間中心設計で共有されてきた 100 項目を、実務で引きやすい 9 カテゴリに組み直した一覧です
• 判断に使う数値は一次情報で裏を取りました。応答時間の 0.1 / 1 / 10 秒、押せる大きさの 24×24 CSS ピクセルと 44pt / 48dp、コントラスト比 4.5:1 は、そのまま検収基準に使えます
• 巻末に、画面のスクリーンショットを渡すと関係する原則だけを引いて指摘させる AI 実行キットを 3 本付けました。100 項目を暗記する必要はありません

「デザインの確認をお願いしますと言われても、なんとなく使いにくいとしか言えない」。サイトや LP を発注する側から、humbulls がよく聞く相談です。

原因は担当者にデザインの素養がないことではありません。指摘を原則の名前で言えないまま、好みの言い合いに落ちる感想レビューの構造にあります。

本記事では、画面設計の判断基準になる 100 の原則を 9 カテゴリに整理して解説します。特別な知識は要りません。項目の名前と見分け方さえ持っていれば、誰でも同じ指摘ができます。

100 項目は、上から読む必要はありません。いま手を動かしている場所から引いてください。

1. 全体を決める原則 — 何を減らし、誰に主導権を渡すか

「機能を足すほど良くなると思っていたのに、社内から『前のほうが使えた』と言われました」。サイトや管理画面を作り直すたびに項目が増えていく、という話はよく聞きます。

原因は機能の数そのものではなく、増えた複雑さを誰が引き受けるのかを決めていないことにあります。減らす対象を先に決めていないので、判断がそのまま画面の上に積み上がります。

もうひとつ、着手前に握っておきたい前提があります。画面のなかで最後に決めるのは、いつも使う人の側です。ここが曖昧だと、親切のつもりで組んだ自動処理が、そのまま押し付けとして届きます。

シンプルにする

画面に置くものを減らし、一度に判断させる量を小さくします。人は選択肢が並ぶほど見比べに時間を使うので、要素が増えるほど「どれを押せばいいのか」で手が止まります。BtoB サイトのトップに主要導線を十数本並べる構成はよく見かけますが、増やした分だけ一本あたりは目立たなくなります。消したら誰が困るかを聞いてみて、即答できない要素は整理の余地があります。

簡単にする

見た目が整っていることと、やり終えるまでが楽なことは別物です。要素を減らしても、入力のたびに調べものが要れば、その画面は簡単になっていません。問い合わせフォームで「ご希望のプラン」を選ばせると、プラン名を知らない見込み客はいったんサイトに戻って調べることになります。整った画面ほどこの手のつまずきは表に出ないので、作業を最後まで通せるかどうかで見てください。

複雑性保存の法則

どんな仕組みにも、それ以上は削れない複雑さが残ります。Xerox PARC の Larry Tesler が 1980 年代半ばに示した考え方で、削りきれない分は消えず、使う人が背負うか、作り手が設計と開発の段階で引き受けるかに分かれます (Laws of UX、2026 年 8 月取得)。郵便番号から住所を自動で埋める入力欄は、ユーザーの手間を開発側が引き取った例です。画面が楽になったと感じたら、その手間をどこが肩代わりしたのかを確かめてください。

単純なものは単純なままに

よくある用件は最短で終わらせ、込み入った用件も回り道すれば達成できるようにします。上級者向けの設定を全員に見せると初めて来た人が止まり、隠しすぎると使い慣れた人が毎回遠回りします。資料ダウンロードなら、名前とメールだけで完了する道を正面に置き、部署や導入時期は任意欄に下げる形になります。片方を立てるために、もう片方を犠牲にしていないか見てください。

一貫性

同じ意味のものは同じ見た目と同じ言葉で示し、違う意味のものは見分けがつくようにします。ユーザーは自社サイトより他社のサイトで過ごす時間のほうが長く、すでに知っているサイトと同じ挙動を好みます (Laws of UX の Jakob's Law、2026 年 8 月取得)。世の中で通っている作法から外れると、それだけで操作を覚え直させることになります。同じ機能が「送信」「確定」「登録」と呼び分けられていたら、まず用語の一覧をつくって揃えてください。

ユーザーの主導権

進める・戻る・やめるの判断を、ユーザーの手に残します。Jakob Nielsen が 1994 年に公開した 10 項目のユーザビリティ原則でも、誤って入り込んだ操作から抜け出せる「非常口」を用意することが挙げられています (Nielsen Norman Group、2026 年 8 月取得)。フォームの途中で勝手に次のページへ送られる、閉じられないモーダルが出るといった作りは、この主導権を奪っています。やっぱりやめたと言える出口があるか確認してください。

タスクコヒーレンス

同じ人が同じ操作を繰り返す、という前提で画面を組みます。前回の絞り込み条件、前回選んだ拠点、前回使った出力形式は、たいてい今回も同じものが選ばれます。Alan Cooper は『About Face』で、ユーザーが入力する価値のあるものはプログラムが覚える価値がある、と書いています。管理画面で毎回同じ期間指定をやり直させているなら、初期値を前回値にするだけで作業が一段短くなります。

メジャーなタスクに最適化する

すべての用件を平等に扱わず、多く起きる用件を一番速い経路に置きます。BtoB サイトなら資料請求と問い合わせが上位に来て、採用情報やニュースはその下に回ります。ここを横並びにすると多数派が毎回同じだけ探すことになり、少数派への公平さが全体の速度を落とします。アクセス解析で上位に来ているページと、画面のなかで一番目立っている要素が食い違っていたら、優先順位を組み替える合図です。

カスタマイズ機能に頼らない

設定で切り替えられるようにする前に、初期状態を正しくします。150 以上の設定を持つ Microsoft Word の利用者を調べた調査では、何かひとつでも設定を変更していた人は 5% 未満でした (UIE、2011 年 9 月公開、2026 年 8 月取得)。届いた状態には理由があると考えて、ほとんどの人は触りません。社内で意見が割れたときに設定項目を足して決着させているなら、決めきれなかった分がそのままユーザーの手間になります。

ここまでの 9 項目は、個別の画面をいじる前に、プロダクト全体の方針として決めておくものです。ここが決まっていないと、次章以降の判断はその場しのぎになります。

次の章では、この方針を実際の情報の並べ方に落としていきます。

2. 人の頭の中に合わせる — 認知の制約を設計条件として扱う

「ボタンはちゃんと置いてあるのに、ユーザーテストで誰も押さなかった」。サイトを作り直した直後の検証で、担当の方からよく聞く報告です。設計の抜けを探しても、ボタン自体は要件どおりの位置に置かれています。

押されなかった理由は、利用者の注意力の不足ではありません。

画面のほうが、人の頭の働き方に逆らって組まれています。知覚・記憶・注意の限界を先に設計条件として固定すると、レイアウトも文言も判断できるようになります。

メンタルモデル

利用者は画面を開く前から、これはこう動くはずだという自分なりの見取り図を持って来ます。設計がその見取り図とずれていると、機能が足りていても操作を間違えます。資料請求のボタンを押した人がその場で PDF を待っていると、フォーム送信後にメールで届く設計では手が止まります。「どこから申し込めるのか分からない」という連絡が窓口に届いているなら、説明文を足すより先に、この見取り図とのずれを探すほうが早く直ります。

シグニファイア

押せる、入力できる、掴んで動かせるといった操作の可能性を利用者に知らせる、目に見える手がかりを指します。ドナルド・ノーマンは、行為そのものの可能性と、それを伝える印を切り分けるためにこの語を持ち込みました (ACM Interactions、2008 年)。装飾を減らす途中でボタンの枠線と影を消し、テキストリンクの下線も外した画面は、押せる場所を伝える印をまとめて落としています。白黒のスクリーンショットを初見の人に渡し、押せる場所を指してもらうと手早く確かめられます。

マッピング

操作するものと、その結果が現れる場所を、どう対応づけるかという話です。人は空間的な並びから対応を読み取るので、操作と結果の並びが一致していれば、説明がなくても正しく手が動きます。管理画面で一覧の行が縦に並んでいるのに、操作ボタンだけ画面上部に横並びでまとまっていると、どのボタンがどの行に効くのかが毎回分からなくなります。対応関係を注記や吹き出しで補っている箇所は、本来なら配置だけで解けていたはずの場所です。

視覚ゲシュタルト

人はものを 1 つずつ見るのではなく、近いもの、似ているもの、囲まれているものをひとまとまりとして受け取ります。問い合わせフォームでは、ラベルと入力欄の間隔より入力欄と次のラベルの間隔のほうが狭いというだけで、ラベルと欄の対応が 1 段ずれて見えます。区切り線や背景色を足す前に、画面を縮小するか目を細めて、見えている塊の数と境目が設計意図と合っているかを見ます。

ユーザーの言葉を使う

画面に置く語は、利用者が普段使っている言い方に寄せます。社内の呼び名をそのままナビゲーションに出すと、外から来た人はどこを押せばよいのか判断できません。BtoB サイトなら、検索キーワードと商談の議事録が語彙の出所になり、営業が電話口で使っている言い回しはそのまま使えます。ナビゲーション項目を声に出して読み、社外の人が意味を言い当てられないものが混じっていたら、そこが言い換えの対象です。

ユーザーの記憶に頼らない

覚えていないと次に進めない画面を作らない、という原則です。短期記憶に保てる塊の数は 7±2 とされ (Miller、1956 年)、記憶術の助けを除くと 4 つ前後だとする整理もあります (Cowan、2001 年)。ただしこの数字をメニュー項目数の上限にするのは誤用で、画面に表示されているものは覚える必要がありません (Nielsen Norman Group、2009 年)。原則が効くのは、長い申込フォームの確認画面で前の画面の入力内容を見せ直すような場面です。

コンストレイント

間違った操作をそもそもできないように、選べる範囲をあらかじめ狭めておく考え方です。人は禁止事項を読んで覚えるのが苦手なので、事後にエラーメッセージで叱るより、はじめから選べなくするほうが負担は軽くなります。打ち合わせの日程調整で過去の日付を選べなくする、数量欄で数値キーボードだけを出す、といった細工がこれにあたります。入力エラーの多い項目は、書き方の説明を足す前に、間違った値をそもそも入れられる作りになっていないかを見ます。

直観的より慣用的に

利用者が速く扱えるのは、すでに別の場所で覚えを済ませた見慣れた形です。初見で意味の分かる斬新な形よりも、手が早く動きます。ロゴを押すとトップに戻る、ログインや問い合わせは右上にあるといった配置を、多くの人は他社のサイトを回るうちに覚えてきました。ここを自社らしさの表現として動かすと覚え直す手間を負わせるので、一般的な位置から外すなら、見合う理由があるかを公開前に確かめてください。

空間的に記憶できるようにする

人は情報の中身だけでなく、それが画面のどこにあったかという位置でも覚えています。同じ操作を毎日繰り返す管理画面ほどこの記憶が効き、慣れた利用者は文字を読まずに場所へ手を伸ばします。よく使う順に自動で並べ替わるメニューや、ページごとに項目数が変わるナビゲーションは、こうして積み上げた記憶を毎回無効にします。利用頻度に応じて順序が動く要素があれば、その便利さと引き換えに何を壊しているのかを見直してください。

プロスペクティブメモリー

あとでこれをやろう、という将来の予定を覚えておく働きを、心理学ではプロスペクティブメモリーと呼びます。この記憶は途中で別の作業が挟まると、予定ごと抜け落ちます。長い申込フォームで残りは後で入力しようと離脱した人が戻ってこないのは、興味が薄れたからとは限りません。「あとで」を利用者の頭に預けている導線を見つけたら、途中保存と再開リンク、通知メールのように、思い出す仕組みを設計側で用意します。

フィッツの法則

対象に手を伸ばして届くまでの時間は、距離が遠いほど、対象が小さいほど伸びます。Paul Fitts が 1954 年に MT = a + b × log₂(2D/W) と定式化した関係で、D が対象までの距離、W が対象の幅にあたります。画面の端や四隅ではポインタが縁で止まるため、そこに置いた要素は片方向に無限の幅を持つ標的として働きます。主要な CTA を小さく作って余白に浮かせた画面や、削除ボタンを保存ボタンの真横に並べた画面は、この法則に逆らっています。

ヒックの法則

選択肢の数が増えると、選び終わるまでの時間が対数的に伸びます。Hick (1952 年) と Hyman (1953 年) が RT = a + b × log₂(n+1) として整理した関係で、n が選択肢の数にあたります。ただし順不同のリストを 1 項目ずつ目で追う場面には当てはまらず、分類や並び順のある選択に適用範囲が限られます。問い合わせフォームの業種プルダウンに 60 件の選択肢を並べているなら、大分類を 1 段挟めないかをまず検討してください。

錯視を考慮する

座標や寸法の数値をそろえても、目にはずれて見えることがあります。円や三角形は同じ高さの四角形より小さく見えるので、アイコンを並べるときはわずかに大きく作って釣り合わせます。文字の左端も、括弧や引用符が付くと数値上の位置より内側に引っ込んで見えるため、目で合わせ直したほうが整います。CSS 上は中央にそろえたのにずれて見えるという指摘が出たら、実装ミスを探す前に錯視を疑ってください。

まずは自社で一番使われている導線を 1 本開き、13 項目のうち破っているものに印を付けてみてください。印が重なった画面は、細部を磨くより並べ方から組み直すほうが早く直ります。

→ 手元の画面がここまでの原則を満たしているかは、巻末の実行キット①でそのまま点検できます。

3. オブジェクトと操作の文法 — 「何を」選んでから「どうする」

「管理画面のメニューが『〜を登録する』『〜を編集する』だらけで、目的の一覧にたどり着けない」。ツールを導入して運用が始まった会社から、数週間もすると出てくる声です。同じことは、資料請求の導線が「申し込む」「送信する」ばかりになった BtoB サイトでも起きます。

この画面が使いにくいのは、説明書が足りないからではありません。手続きを画面の入口に据えたせいで、扱いたい対象そのものが画面から消えているのです。作る側は業務を作業の連なりとして把握しているので、その並びをそのままメニューに写してしまいます。

オブジェクト指向 UI と呼ばれる設計では、この順番を逆さにします。先に対象を並べて見せ、選んだあとから何ができるかを示す形に組み替えます。以下の 10 項目は、画面から名詞を取り戻すための道具立てです。

オブジェクトベースにする

画面の単位を、作業の手続きではなく業務が扱う対象に置き換えます。人は自分の仕事を「先週の問い合わせ」「あの見積書」のように対象で覚えていて、「新規登録処理」という手続き名からは記憶を引き出せません。メニュー項目がすべて動詞で終わっていたら、設計が手続きの側から始まった合図です。「問い合わせ」「資料」「担当者」と名詞に並べ替えると、登録画面と編集画面がひとつにまとまり、画面の数も減ります。

ビューはオブジェクトを表象する

ビュー、つまりひとつの画面は、その裏にある対象の姿を映したものにします。問い合わせ一覧という画面に映っているのは問い合わせの集まりであって、検索という機能ではありません。ビューと対象が素直に対応していれば、利用者は自分が今どこにいるかを画面の名前だけで言い表せますし、URL を共有するだけで話が通じます。タイトルを読んでも居場所を説明できない画面や、ひとつの画面に別々の対象が同居している画面では、この対応が崩れかけています。

オブジェクトは自身の状態を体現する

状態は、対象そのものの見た目に出します。下書きの記事は下書きらしく、送信済みの資料請求は送信済みと分かる形で、一覧のその行の中に状態が現れているのが理想です。状態をステータス欄の文字だけに閉じ込めると、利用者は上から一行ずつ舐めるように読むしかなくなり、件数が増えたところで対応漏れが出ます。色や余白や並び順に状態が出ていない一覧は、見落としを利用者の注意力で埋めさせている画面なので疑ってください。

名詞→動詞の操作順序

先に対象を選ばせ、そのあとで操作を選ばせます。この順番なら、選んだものを目で確かめてから操作を決められるので、違う相手に処理を当てる事故が減ります。動詞から入る画面では、今どれを相手にしているのかを頭の中だけで保持したまま進むことになり、途中で電話や別の依頼が挟まると取り違えます。「削除モードに入ってから対象を選ぶ」という流れが残っていたら、順番が入れ替わっているので組み直せます。

直接操作

対象そのものをつかんで動かせるようにします。Ben Shneiderman は 1983 年に IEEE Computer 誌へ寄せた論文で、対象が常に画面に見えていること、操作の結果がすぐ返ること、素早く取り消せることを直接操作の条件に挙げました。管理画面の一覧で表示順を変えるのに設定画面を開かせているなら、行をつかんでそのまま動かせないか検討する価値があります。

モードレス

同じ操作がいつでも同じ結果を返す状態を、モードレスと呼びます。編集モードと閲覧モードのように画面の状態で意味が変わると、利用者は自分が今どちらにいるかを覚え続けることになり、覚え違えがそのまま誤操作になります。モードをなくす設計を広めた Larry Tesler は、個人サイトのドメインに nomodes.com を使っていました。同じボタンが場面によって違う働きをする画面は、モードをひとつ抱えています。

ジェスチャはコマンド式ではなく直接操作式にする

スワイプやドラッグは、隠しコマンドではなく物を動かす感覚に対応させます。「三本指で左に払うと前の画面に戻る」は覚えないと使えませんが、「つまんだカードを引っ張って別の列に移す」は見れば分かります。前者は説明を読むまで存在にすら気づけないので、知っている人だけが速く使える画面になります。触っても何も動かず、決まった動きをしたときだけ反応するなら、ジェスチャがコマンドになっています。

ナビゲーション項目は名詞にする

メニューやタブのラベルは、対象の名前で書きます。「資料をダウンロードする」より「資料一覧」、「お問い合わせする」より「お問い合わせ」と置くほうが、その先に何があるかを想像しやすくなります。動詞のラベルからは、押した先が入力フォームなのか説明ページなのか判別できず、押す前の身構えが変わってしまいます。BtoB サイトのグローバルナビが「〜する」で揃っていたら、案内ではなく勧誘の言葉になっていないか見直してください。

アイコンは名詞または形容詞を表す

アイコンには対象か性質を担わせ、操作そのものは託しません。ゴミ箱の絵が通じるのは、それが「ゴミ箱」という物を指しているからで、「削除する」という動詞を絵にできているわけではありません。Nielsen Norman Group も 2014 年 7 月の記事で、大半のアイコンには定まった意味がなく、常時表示のテキストラベルを添える必要があると述べています。ラベルのないアイコンだけが並ぶツールバーは、社内でも読み方が割れます。

すべての操作可能な要素は意味を持つ

押せる見た目のものには、必ず働きを持たせます。働きのないものを押せる見た目で置くと、利用者はカーソルを合わせて反応がないことに気づき、壊れていると受け取ります。BtoB サイトの実績ロゴやカード型の見出し、装飾のつもりで角丸と影を付けた囲みでよく起きる崩れ方です。押してみないと分からない要素がひとつあると、利用者はほかの要素も試すようになり、画面全体の操作が探り探りになります。

名詞を先に立てるだけで、画面の数も、利用者が覚えることも減ります。ここまでが「何を扱うか」の文法で、次の章ではそれをどう見せるかに移ります。

4. 入力とフォーム — 離脱はデザインではなく設問で起きる

「問い合わせフォームの項目を 3 つ減らしてくれと営業に言われたのですが、どれを削るべきか根拠がありません」

離脱が起きる原因は項目の多さではなく、答えるためにいったん手を止めて考えこむ設問が混ざっていることにあります。項目数は、その症状として表に出ているだけです。

「年間予算」を自由入力で書かせる欄が 1 つあるだけで、社内確認が必要になって送信が止まります。選ぶだけで終わる設問なら、10 個並んでいても指は止まりません。削る候補は、その場で即答できない設問から選びます。

入力フォームにはストーリー性を持たせる

フォームは、書き終わるまで続く一本の会話だと考えてください。前の質問と次の質問がつながっていれば先を予測でき、予測できるあいだは手が止まりません。資料請求なら、会社名から部署、役職、いま抱えている課題へと、面談で聞く順番のまま進む並びにします。所属を聞いた直後に予算を尋ね、そのあとまた部署名に戻る並びは、書き手に「まだ終わらないのか」と思わせます。

操作の流れを作る

入力欄の並びは、そのまま指と視線の移動経路になります。左右にジグザグさせたり、縦一列の途中で 2 カラムに割ったりすると、次にどこを埋めるのかを毎回探すことになります。ラベルは欄の上に置いて縦一列に積むのが最短で、スマートフォンでも同じ形のまま幅を縮められます。姓と名、市区町村と番地のように必ず対で埋める項目だけ、横並びを許します。

前提条件は先に提示する

「送信後に営業から電話が来る」「登録には法人のメールアドレスが必要」といった条件は、設問の前に出します。書き終わってから条件を知らされると、それまでの入力が無駄になり、印象も悪くなります。WCAG 2.2 も、入力を求める場面ではラベルか説明を提供することを達成基準 3.3.2 (レベル A) として定めています。条件をフォームの末尾に小さくぶら下げていたら、位置が逆です。

よいデフォルト

初期値には、たいていの人がそう答える値を入れておきます。国名が日本、問い合わせ種別が「サービスについて」のように多数派の選択が入っていれば、その欄は読むだけで通過でき、考える回数が 1 つ減ります。ただし、金額や送信先のように誤ったまま通ると困る項目に初期値は置きません。デフォルトは手間を省くための道具であって、利用者の判断を代行させるものではありません。

制限コントロールを活用する

選べる値をあらかじめ絞った部品を使い、間違った値をそもそも入れられなくします。日付をテキスト欄で受け取ると「2026/08/07」「2026年8月7日」が混ざり、受け取ったあとの整形と、書き手へのエラー表示が両方必要になります。カレンダーから選ばせれば、表記は最初から 1 つに揃います。エラーメッセージを増やす前に、その欄が本当に自由入力でなければならないのかを確かめます。

選択肢の文言は肯定文にする

選択肢に否定を入れると、読み手は頭のなかで打ち消し算をすることになります。「メールマガジンを受け取らない」にチェックが入った状態は、受け取るのか受け取らないのかを一瞬考えさせます。「メールマガジンを受け取る」に直せば、チェックの有無がそのまま意思になります。「〜しない」「〜を希望しません」で始まる選択肢や、二重否定の同意チェックは、裏返して書けないか試します。

値を入力させるのではなく結果を選ばせる

利用者に計算や換算をさせず、こちらで候補を用意して選ばせます。「希望日時を入力」の欄を空き枠のボタンに替える、従業員数を数字で書かせずに規模の区分から選ばせる、といった置き換えです。書き手が電卓や社内資料を開いた時点でその場の送信は難しくなり、あとで戻ってくる人はほとんどいません。設問に答えるのに別の画面が要るなら、直すべきは入力欄の見た目ではなく設問の側です。

入力欄を構造化する

長いフォームは、意味のまとまりごとに区切って見出しを付けます。連絡先、会社情報、相談内容と 3 つに割るだけで全体量が把握でき、どこまで進んだかも分かります。区切りのない 20 行のフォームは、項目数が同じでも実際の作業量より重たく見えます。まとまりは 3〜5 個に収め、1 まとまりが 1 画面に入る量にすると、スクロールと理解の単位が揃います。

デフォルトボタンには具体的な動詞を用いる

ボタンの文字には、押した結果をそのまま書きます。「送信」や「OK」を「資料をダウンロードする」「無料相談を申し込む」に替えれば、押す前に何が起きるか分かります。Microsoft の Windows 向けガイドラインも、OK のような汎用ラベルを避け、問いかけへの具体的な応答をボタン文言に使うよう案内しています (Microsoft Learn、2026 年 8 月閲覧)。ボタンだけを読んで意味が通らなければ、書き直してください。

ラジオボタンは単数選択、チェックボックスはオンオフ

形が役割を伝えます。丸いラジオボタンは「並んだ選択肢からひとつ」、四角いチェックボックスは「この項目を入れるか外すか」と、利用者は押す前に形だけで見分けています。この対応が崩れると、複数選べるのかどうかを試しにクリックして確かめることになります。1 つだけ置かれたラジオボタンは、押したあと解除できないので、チェックボックスに替えます。

フリップフロップ問題を避ける

オンとオフを 1 つのボタンで切り替えるとき、そのラベルが現在の状態を指すのか、押した後の状態を指すのかが読み取れなくなります。「通知オン」と書かれたボタンでは、いま通知が有効なのか、押すと有効になるのかが判別できません。状態はスイッチや表示で示し、ボタンには操作だけを書きます。管理画面の一括設定やメール配信の停止ボタンのように、押す頻度が低い操作ほど起こしやすくなります。

ユーザーに厳密さを求めない

表記のゆれは、受け取る側で吸収します。電話番号のハイフン、全角と半角、郵便番号の桁区切りを理由にエラーを返すのは、システムの都合を書き手に押し付けているだけです。WCAG 2.2 も同じ方向を向いていて、同じ手続きのなかで一度入力させた情報をもう一度求めるなら、自動で埋めるか選べるようにすることを求めています (達成基準 3.3.7、レベル A)。エラーが出た項目を並べてみると、その多くは受け取ってから整形すれば済む種類です。

入力サジェスチョンを提示する

過去の入力やブラウザの自動入力が効くようにしておくと、氏名や住所の欄は数タップで埋まります。HTML の autocomplete 属性を正しく指定すれば有効になり、WCAG 2.2 の達成基準 1.3.5 (レベル AA) が求める「入力欄の目的を機械的に判別できる状態」にもなります。郵便番号から住所を補完する、社名の先頭数文字で候補を出すといった補助も同じ発想です。自動入力が効かないフォームは、name 属性が独自の命名になっていないかを疑ってください。

肯定／否定ボタンの順序はプラットフォームのルールに従う

確認ダイアログのボタンの並びは、OS ごとに逆です。macOS では追加したボタンが右端から左へ並び、実行を促す既定のボタンが右に来ます (Apple Developer Documentation、2026 年 8 月閲覧)。Windows の現行ガイドラインは向きが反対で、肯定側を左、キャンセルを右に置くよう案内しています (Microsoft Learn、2026 年 8 月閲覧)。自社の好みで決めず、その画面が動く環境の慣習に合わせます。

14 項目の多くは、画面の見た目より設問の書き方に関わります。CSS を触る前に 1 問ずつ音読して答えられない設問を洗い出し、そのうえで、送信した後に画面が何を返すのかを見直してください。

→ 自社フォームの設問を 4 分類する作業は、巻末の実行キット②でそのまま実行できます。 設問を減らした効果は、GA4 で BtoB サイトのリード計測 の手順で公開前後を比べられます。

5. エラーと安全設計 — 起こさせない、起きても壊さない

「送信でエラーになった瞬間、書いた問い合わせ内容が全部消えた」。フォーム改修の相談で、いちばんよく聞く話です。同じ内容をもう一度書き直してもらえることは、まずありません。

入力が消える事故を利用者の操作ミスとして扱うのは筋違いです。原因は失敗したときに何を守るのかを決めないまま画面を作ったことにあります。

打ち手は二層で持ちます。エラーを起こさせない設計と、起きた後に利用者の時間を守る設計を分けて考えてください。守るものが決まれば、この章の 9 項目のどれを先に手当てするかも決まります。

エラーを回避する

エラーメッセージの文言を磨く前に、エラーになる状態そのものをなくします。Nielsen のユーザビリティ 10 原則も、良い文言より問題の未然防止を先に置いています (Nielsen Norman Group, 2026-08)。問い合わせフォームなら、電話番号のハイフンを弾かずに、受け取った側で外してしまえば済みます。入力欄の注記が「半角英数字で入力してください」だらけになっていたら、システムの都合を利用者に肩代わりさせていないか疑ってください。

フールプルーフよりフェールセーフ

誤操作を起こさせない工夫がフールプルーフ、失敗しても被害の小さい側へ倒れる仕組みがフェールセーフです。製造現場のポカヨケは前者の代表格ですが、人の操作を封じきることはできません。管理画面の一括削除なら、ボタンを隠すよりも、削除を一定期間だけ取り消せる形にしておくほうが効きます。禁止事項の数と復旧手段の数を並べて、前者ばかりが増えていないか数えてみてください。

エラー表示は建設的にする

エラー後の画面には、何が起きたかを伝える仕事と、次の一手を示す仕事があります。同じ 10 原則は、エラーコードを使わず平易な言葉で問題を正確に指し示し、解決策まで示すべきだと整理しています。「入力内容に誤りがあります」とだけ出る赤字は、どの欄が何と衝突しているのかを利用者に探させています。該当欄の直下に「郵便番号は 7 桁の数字で入れてください」と書けているかを確かめてください。

可能性と確率を区別する

起こりうることと、実際によく起こることを、同じ重みで扱わないための戒めです。すべての可能性に確認ダイアログを立てると、利用者は中身を読まずに「はい」を押す習慣を覚え、本当に危険な一回でも手が止まりません。資料ダウンロードの入力ミスと、顧客データの一括削除を同じ強さで警告している画面は、起こる頻度と失う大きさの掛け算をしていません。警告を減らす作業は、危険な操作を目立たせる作業でもあります。

ユーザーが入力したものはユーザーのもの

利用者が時間をかけて打ち込んだ文章は、打ち込んだ本人のものです。送信に失敗した瞬間に本文が消えるフォームも、編集中にセッションが切れて白紙に戻る管理画面も、この所有権を無視しています。エラーで画面を戻すなら入力値を詰め直し、長文欄は下書きを一時保存し、登録済みのデータは書き出せるようにしてください。要望欄のような長文は、二度目を書いてもらえない前提で守ります。

整合性を損なうような操作をユーザーに求めない

同じ値を二度入力させたり、片方だけ更新できてしまったりする操作を、利用者に押しつけない原則です。会社名を契約管理と請求先で別々に持っている管理画面が典型で、更新のたびに片側が古くなり、書類の社名が食い違います。矛盾を防ぐための手順が社内マニュアルに書き足されていたら、画面が果たすべき仕事を人に外注した合図だと考えてください。整合性の維持は、本来システム側の担当です。

エスケープハッチ

どの画面からでも、途中でやめて元の場所へ戻れる出口を用意します。10 原則の 3 つめは、誤って入り込んだ状態から長い手続きなしで抜け出せる「非常口」を求め、戻る・キャンセル・閉じる・取り消しを具体例に挙げています。5 ステップの申し込みフォームで 2 ステップ目から前に戻れない作りは、非常口がない状態です。閉じる・戻る・ブラウザバックが効くかを、公開前に実機で押してください。

ガッツを見せる

システムの側が簡単に音を上げない、という姿勢の話です。検索して「該当する結果はありません」とだけ返す画面は、一度の照合で降参しています。表記ゆれを吸収する、近い候補を出す、条件をひとつ外した結果を添えるといった粘りがあれば、利用者はもう一度そのサービスを使ってくれます。ゼロ件の画面や 404 の画面に次の一手が置かれていなければ、踏ん張りが足りていないと考えてください。

ゼロ・ワン・インフィニティ

数を制限するなら 0 個・1 個・無制限のどれかにして、中間の半端な上限を作りません。プログラミング言語の設計論に由来する原則で、Bruce MacLennan が 1970 年代前半に定式化し、1983 年の著書に記しています (Wikipedia, 2026-08)。添付ファイルは 3 つまで、担当者は 5 人まで、といった上限は、6 人目が現れた日に壊れます。制限を置くなら、その数字の根拠を言えるかを確かめてください。

エラー設計の良し悪しは、うまく操作できたときの画面には出ません。わざと間違えて押したときに何が残っているかで決まるので、次の章も「うまくいかないとき」の目で読み進めてください。

6. 反応・時間・状態遷移 — 待たせ方が体感品質を決める

「保存ボタンを押しても何も起きないように見えるので、みんな 3 回押している」。管理画面の運用でよく聞く話です。処理そのものは数秒で終わっていても、押した瞬間に画面が静止していれば、届いていないと判断されます。

原因は処理の遅さではなく、押した事実が画面に返っていないことにあります。体感の速さと実測の速さは、別々に設計できます。

反応が 0.1 秒以内なら人はシステムが即座に応じたと感じ、1 秒までは考えの流れが途切れず、10 秒を超えると注意が別のことへ移ります (Nielsen Norman Group, 2026-08 取得。原典は Miller 1968 と Card ら 1991 の研究)。この章の 14 項目は、その境界のあいだをどう埋めるかを集めたものです。

ユーザーの操作に対して 0.1 秒以内に反応を返す

押した瞬間に、画面のどこかが目に見えて変わるようにします。0.1 秒以内に変化が返ると、人はシステムが即座に応じたと感じ、自分の手で動かしている実感を保てます。処理そのものに 1 秒かかっても構わないので、ボタンの見た目が沈む、ラベルが「送信中」に変わる、その反応だけを先に返してください。押しても静止したままの画面は連打を招き、申込データの二重登録や自動返信メールの重複という形で後から現れます。

操作の近くでフィードバックする

反応は、操作した場所のそばに出します。人の視線は押した指先やカーソルの周りに留まっているので、画面上端に出た通知バーは、色を変えたところで読まれないまま消えていきます。フォームの必須項目が空だったなら、ページの先頭にまとめるのではなく、その入力欄の真下に理由を置きます。エラーの件数だけを冒頭に出す作りは、どこを直せばいいのか分からず、入力し直す気力を奪ったまま離脱につながります。

黙って実行する

できる処理は、確認を挟まず静かに済ませます。「本当によろしいですか」を毎回出していると、読まずに OK を押す習慣が付き、いざ危険な操作のときにも確認として働きません。下書きの自動保存や検索条件の記憶は、告知なしで行い、結果だけを残せば十分です。取り消しがきく操作なら、確認ダイアログを出すより、あとから戻せる手段をひとつ用意しておくほうが、作業は速く進みますし事故も減ります。

UI をロックしない

処理の間、画面全体を覆って操作を止めないようにします。CSV の書き出しに 30 秒かかるとしても、その間ユーザーが別の一覧を見たり検索したりできない理由はありません。進行中の処理は画面の一角に小さく表示し、終わったところで知らせる形にすれば、待っているあいだも別の仕事が進みます。半透明の膜が全面にかかるローディングを見つけたら、本当に画面全部を止める必要があるのか疑ってください。

ユーザーが自分のペースで作業できるようにする

待ち時間も進み方も、システム側の都合で決めつけません。自動で切り替わるスライドショー、数秒で消える通知、時間切れで落ちる入力画面は、読むのが遅い人や途中で電話に出た人を切り捨てます。急がせないだけで、拾えるユーザーの幅は広がります。資料ダウンロードのフォームでセッションが 10 分で切れる設定になっていたら、入力途中の内容が消えていないか確かめてください。

回答の先送り

すべての情報を最初に聞かず、必要になった時点で尋ねます。問い合わせフォームで従業員規模や予算を冒頭に置くと、答えに迷った人はそこで手が止まります。まず名前とメールで送信させ、詳細は次の画面や後日のメールで補えば、聞ける情報の量を保ったまま、途中離脱を抑えられます。入力欄が 10 個並んでいるなら、いま本当に必要なのはどれかを数え直してみてください。

即座の喜びを与える

価値を先に見せて、手続きは後に回します。診断ツールや見積もりシミュレーターで、結果を出す前にメール登録を求めると、まだ価値を知らない人は離れていきます。概算だけ先に画面へ出し、詳細版の送付先としてメールを聞けば、登録する理由が本人にとってはっきりします。自社のツールを開いてみて、得られるものより先に負担が来る順序になっていたら、前後を入れ替える余地があります。

プリコンピュテーション

待ち時間になりそうな処理を、先に済ませておきます。次のページの画像を裏で読み込む、一覧の続きを先に取得しておく、といった準備をしておけば、ユーザーが操作した時点では表示するだけで済みます。BtoB サイトなら、ナビゲーションにカーソルが乗った時点で遷移先の読み込みを始めておく、資料ダウンロードの PDF を入力画面の表示中に用意しておく、といった使い方ができます。処理を速くするより、順番を前倒しするほうが効く場面は多くあります。

ユーザーがとれる操作がひとつしかないなら自動化する

選択肢が実質ひとつしかない場面では、選ばせずに実行します。検索結果が 1 件だけなら一覧を挟まず詳細を開く、拠点がひとつなら拠点選択のプルダウンを出さない、選べる支払方法がひとつなら選択画面ごと省く、といった判断です。選ぶという行為そのものが、読んで理解して決めるという負担を発生させます。項目がひとつしかないセレクトボックスや、押す先がひとつしかない確認画面は、消す候補です。

データをバインドする

同じ数値が複数の場所に出るなら、片方を直したときもう片方も同時に変わるようにします。人が手で写し替えている限り、更新のたびに写し漏れの機会が生まれ、いつか食い違います。管理画面で単価を変更したのに合計金額が古いままだと、ユーザーはどちらの数字を信じればいいのか迷い、そこで操作を止めて問い合わせに回ります。更新ボタンを押さないと合計が変わらない画面や、一覧と詳細で在庫数が食い違う画面は、この原則が守られていない印です。

画面の変化をアニメーションで表す

要素が突然現れたり消えたりせず、動いて変わるようにします。人は画面のどこが変わったかを瞬時には把握できないため、予告なく切り替わった部分は見落とされます。一覧から 1 行を削除したときに、その行が縮んで消えていけば、どこが減ったのかを言葉なしで伝えられます。動きの長さは 100〜400 ミリ秒が目安で、500 ミリ秒に達すると動作そのものが煩わしく感じられます (Nielsen Norman Group, 2026-08 取得)。

トランジションは両方向につける

開くときに動くなら、閉じるときも動かします。開くのは滑らかなのに閉じるのは一瞬で消えるパネルは、同じ部品として認識されず、どこへ戻ったのか分からなくなります。往路と復路の動きを対にしておくと、いま自分がどの階層にいて、どこへ戻れば元の一覧にたどり着くのかを覚えていられます。モーダルやサイドメニューを作ったら、閉じる側の動きが省かれていないか確認してください。

動かしたままに動くのではなく動かしたいように動く

動きを設計するときは、物理的な正確さではなく、意図が伝わるかどうかを基準にします。等速で動くパネルは機械的に見えますが、はじめに速く動いて最後にゆっくり減速する動きは、手で押して止めたときのように自然に感じられます。実物の挙動を正しく再現しているかどうかは、ここでは問われません。動きに求められているのは、要素がどこから来てどこへ行ったのかを、説明文なしで理解させることです。

ショートカットを用意する

同じ操作を一日に何度も繰り返す人には、近道を用意します。管理画面で毎日 100 件の申込を処理する担当者にとって、1 件あたり 3 クリックか 1 クリックかは、そのまま作業時間の差になります。キーボード操作、一括選択、前回の検索条件の再利用、よく使う絞り込みの保存などが該当し、どれも通常の導線を残したまま足せます。はじめて使う人の分かりやすさと、毎日使う人の速さは両立するので、片方だけを見て設計しないようにします。

ここに並べた原則は、処理を速くする話ではありません。待っている時間をどう扱うかの話で、サーバーに手を入れずに直せる箇所がいくつも含まれています。

7. 画面の見せ方とレイアウト — 情報を減らさずに見た目を減らす

「ダッシュボードに指標を 20 個並べたら、誰も見なくなった」。管理画面のリニューアルで、担当者からよく聞く話です。

画面を見づらくしているのは、載せた情報の量ではありません。意味を持たない見た目の差が、画面のなかに多すぎることが原因です。

人は位置や色や太さの違いに意味を読み取るので、揃っていない余白はそのままノイズになります。同じ意味のものは同じ見た目にして、差をつけるのは意味が違うところだけにします。この 1 本の方針で、この章の 14 項目はほとんど説明がつきます。

整然とレイアウトする

要素の左端や幅、余白の刻みを、画面のなかで数種類に絞って揃えます。人は近さと並びで「これは同じ仲間だ」と判断するため、数ピクセルのずれが意味の差として伝わってしまいます。制作物を確認するときは、画面に縦線を 1 本引いてみてください。見出し・本文・ボタンの左端が 3 か所以上でばらついていたら、直すべきずれです。

色やフォントを使いすぎない

画面で使う色と文字サイズの種類を、あらかじめ決めた数に閉じ込めます。色や太さは「重要」「警告」「無効」といった意味の記号として働くので、種類が増えるほど記号としての力が落ちます。強調色が 2 つ以上ある画面では、どちらが本当に押してほしいボタンなのか利用者には判断できません。書体は 1 種類に絞り、文字サイズは見出しから注記まで段階を決め打つと、画面全体が落ち着きます。

グラフィックのトーン＆マナーを揃える

アイコン、図版、写真の作りかたを 1 つの流儀に統一します。線だけのアイコンと塗りつぶしのアイコンが混ざった画面は、それぞれが別の出どころを持つように見えて、まとまりを失います。資料ダウンロードのページでよくあるのが、配布素材のイラストと自社で作った図が同居している状態です。線の太さ、角の丸み、使う色の数、この 3 つを先に決めてから作り始めると崩れません。

データよりも情報を伝える

手元の数値をそのまま並べるのではなく、受け手が判断できる形に加工して見せます。人は数字そのものではなく、前と比べてどうか、目標に対してどうかを知りたがっています。管理画面でありがちなのが、今月の件数だけが大きく置かれていて、増えたのか減ったのか誰にも分からない状態です。差分・比率・基準線のどれかを添えるだけで、数値は情報に変わります。

プログレッシブ・ディスクロージャ

最初は主要な選択肢だけを見せ、詳細は求められたときに開きます。Jakob Nielsen が 2006 年に Nielsen Norman Group で整理した手法です。問い合わせフォームなら、必須項目を先に出して、任意の補足欄はたたんでおきます。すべてを最初から並べた画面は、はじめての人の手を止めるだけです。

スクロール画面では続きがありそうに見せる

画面の下端で内容がきれいに終わっていると、利用者はそこがページの終わりだと判断します。次のブロックの上部をわずかに覗かせたり、区切り線を画面の途中で断ち切ったりして、続きの存在を伝えます。BtoB サイトのファーストビューを大きな画像で埋めて下端でぴたりと切ると、その下の実績や料金まで読んでもらえません。画面が短いスマートフォンほど、この差がはっきり出ます。

プロパティの選択肢でプレビューを見せる

設定を選ばせる画面では、選択肢そのものに結果の見本を表示します。「ゴシック」「明朝」と文字で書かれても、どう変わるかは選んで戻すまで分かりません。メール配信ツールのテンプレート選択が名称の一覧になっていると、利用者は片っ端から開いて確認する作業を強いられます。色は色見本で、書体は書体見本で、レイアウトは縮小図で見せてください。

ハイライト表現は構成要素をひとつだけ変化させる

選択中や現在地を示すときは、背景色なら背景色だけ、太さなら太さだけを変えます。色も大きさも書体も同時に変えると、選ばれた項目が別の種類の要素に見えてしまい、並びの対応関係が読めなくなります。サイドメニューで選択中の項目だけ文字が大きくなっている作りは、この失敗にあたります。変えるのは 1 つ、というルールを先に決めておくと迷いません。

メニュー項目の位置を変化させない

メニューの並び順を、利用頻度や状況に応じて動かさないようにします。使い慣れた人は項目名ではなく位置で覚えているので、順番が変わるたびに読み直しが発生します。よく使う項目を上へ自動で繰り上げる仕組みは、親切に見えて習熟を妨げます。今は選べない項目も、消さずに無効の見た目のままその場に残してください。

ウェイファインディング

利用者が今どこにいて、どこから来て、次にどこへ行けるのかを画面の上で分かるようにします。Kevin Lynch が 1960 年の『The Image of the City』で論じた都市の「読み取りやすさ」と同じ話で、目印と道筋があれば人は迷いません。Web サイトならパンくず、現在地が分かるナビゲーション、フォームの残りステップ表示がこれにあたります。戻ったあとにどの画面が出るのか想像できない作りなら、直す対象です。

ペンは紙の近くに置く

操作するための道具は、操作される対象のそばに置きます。離れていると視線とマウスが往復する分だけ手数が増え、どの行に対する操作なのかも曖昧になります。一覧表の編集ボタンが画面いちばん上のツールバーにしかない管理画面では、行を選んでから上に戻る往復が毎回発生します。行ごとの操作は行のなかに、全体の操作は全体の枠に置くのが基本です。

視覚的に何であるかを示し文字で説明する

形や色で何のことかを一瞬で伝え、その意味を文字で確定させます。絵記号は目に速く入るかわりに解釈の幅が広く、文字は正確なかわりに読む時間がかかります。両方を重ねると、互いの弱いところを補い合えます。アイコンだけが並ぶツールバーは、作った人以外に意味が伝わらないと考えてください。

パースエージョン

画面の作りかたは、人の行動を後押しする力を持ちます。B.J. Fogg が 2003 年の『Persuasive Technology』でこの領域を整理していて、推奨の初期値や進み具合の可視化がその道具にあたります。相手の得になる後押しなら設計、事業者の得のために判断を歪めるならダークパターンです。通信販売では、2022 年 6 月施行の改正特定商取引法が、最終確認画面での 6 項目の表示を義務づけ、誤認させる表示を禁じています。

ゲームを持ち込まない

作業のための画面に、遊びとしての仕掛けを持ち込まないようにします。ゲームは過程を楽しませるために難しさや演出を足しますが、業務では同じ足し算がそのまま手数と待ち時間に変わります。入力を終えるたびに祝福のアニメーションが挟まるフォームは、同じ作業を何十件も繰り返す担当者にとって邪魔でしかありません。動機づけが必要なら、進み具合を静かに示すところまでにとどめます。

見た目の差を意味の差だけに絞れば、情報を削らないまま画面は静かになります。次の章に進む前に、手元の画面に縦線を 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 に合わせます。

ホットスポットを広げる

見た目を大きくしなくても、指が反応する範囲だけなら広げられます。アイコンの周囲に透明な余白を持たせる、表の行全体をリンクにする、チェックボックスのラベル文字を押しても切り替わるようにする、といった作りです。広げた範囲どうしが接すると誤タップが増えるため、Material Design は隣り合う対象を 8dp 以上あけることも勧めています。資料ダウンロードの一覧で、リンク文字の上でしか指が反応しないなら、まだ広げる余地があります。

ドリルダウンは上→下、左→右

階層を掘り下げる操作は、進む向きを画面の上でも一定にします。日本語の UI は上から下、左から右へ読み進むので、掘り下げた先を下か右に置くと、いま何段目にいるかが位置で分かります。管理画面のメニューでサブ項目が親の上に開いたり、右から左へ展開したりすると、読む順序と進む順序がねじれます。パンくずの並びも同じ向きに揃えておくと、戻る道筋を見失いません。

左が戻るで右が進む

前後に動くボタンは、左を戻る、右を進むで固定します。横書きの UI では時間の流れを左から右に置く感覚が働きますし、スマホの左端スワイプで前の画面に戻る挙動もこの向きに揃っています。画面ごとに並びが入れ替わると、読み手は毎回ボタンの文字を読み直すことになります。問い合わせフォームの確認画面で「入力内容を修正する」が右、「送信する」が左に並んでいたら、押し間違いの温床になっています。

モバイルでは包括的より階層的に

1 画面にすべてを並べる作りより、段階的に潜らせる作りのほうが狭い画面には向きます。スマホは横に情報を置けないぶん、選択肢を一度に見せると縦に長いリストになり、端から端まで目で走査する手間が増えるからです。潜る回数が増えるほど離脱も起きるので、資料ダウンロードのような導線は階層の底に埋めません。PC のグローバルナビをそのまま縦に積んで 20 行のメニューにしているなら、上位カテゴリでいったん受け止める設計に組み直します。

音声読み上げに対応する

画面を見ずに音で操作する人にも、同じ情報が届くようにします。WCAG 2.2 は、画像などへの代替テキストを達成基準 1.1.1 で、部品の名前と役割をプログラムから判別できることを 4.1.2 で、どちらもレベル A として求めています。div にクリック処理を付けただけのボタン、alt のない図版、ラベルと結び付いていない入力欄は、読み上げでは素通りするか、意味の取れない音になります。外注しているなら、この 3 点を検収項目に入れてください。

文字の拡大に対応する

読み手が文字を大きくしても、内容と機能が欠けないようにします。WCAG 2.2 は、支援技術なしで 200% まで拡大できることを達成基準 1.4.4 に、幅 320 CSS px 相当で縦横 2 方向のスクロールが要らないことを 1.4.10 に置き、いずれもレベル AA としています。ブラウザのズームを 200% にして、ボタンの文字が枠からはみ出したり横スクロールが出たりするなら、高さや幅を固定しすぎている合図です。

色に依存させない

色の違いだけで意味を伝えない、という原則です。WCAG 2.2 は達成基準 1.4.1 のレベル A、つまり最低限の要件に置いていて、色覚特性のある人に限らず、屋外の強い光の下や白黒印刷でも効いてきます。フォームのエラーを赤字だけで示していたり、グラフの系列を色の凡例だけで見分けさせていたりしたら、文言・記号・線の種類のどれかを足してください。見分けがつくかは、画面をグレースケール表示に切り替えれば数秒で判定できます。

◯✕△等の記号を安易に使わない

記号は短くて便利ですが、意味の読み取り方が読み手ごとに割れます。日本では◯が可、✕が不可、△が条件付きという了解がありますが、英語圏で正を表すのはチェックで、記入欄の✕は「ここを選んだ」の意味にも読まれます。音声読み上げでも記号の名前が読まれるだけで、対応の可否までは伝わりません。サービス比較表で△を使うなら凡例を添え、できれば「一部対応」と文字で書くほうが確実です。

アイコンのモチーフは特定の文化に依存させない

絵柄が通じるかどうかは、読み手の生活習慣に左右されます。郵便ポストや家の形は国ごとに違いますし、親指を立てる仕草は地域によって侮辱と受け取られます。フロッピーディスクで保存を表す例のように、実物を知らない世代には由来の伝わらない絵柄もあります。英語版と同じ画像を使い回す前提があるなら、通貨記号や〒のような国内固有のモチーフを避け、アイコンには短いラベルを添えておくと安全です。

多言語化を想定した UI ではラベルの長さの違いを考慮する

同じ意味でも、言語が変われば文字数は大きく変わります。W3C の国際化ガイドは、英語から欧州言語へ訳すと、元が 10 文字以下なら 200〜300%、70 文字を超える文でも 130% ほどに伸びるという目安を示しています (W3C Internationalization、2026-08 取得)。ボタンやタブの幅を日本語の文字数ぴったりに切っていると、英語版で表示が崩れます。伸びしろを見込んだ可変幅にしておけば、翻訳のたびに作り直さずに済みます。

ここまでの 11 項目は、実機を 1 台手に取り、ブラウザのズームを 200% にするだけで大半が確認できます。次の章でも、作り手の手元だけで良し悪しを決めないという姿勢が効いてきます。

→ コントラスト比とタップ領域の実測には、巻末の実行キット①の数値基準がそのまま使えます。

9. 道具としての思想 — 誰の作業を、誰のものにするか

「操作を覚えてもらうために、初回チュートリアルを 12 画面つくりました」。管理画面を作り直すときに、よく出てくる打ち手です。ここまでの 8 章では画面の組み立て方を見てきましたが、この章で扱うのは、その画面が誰のものかを決める 6 つの基準です。

チュートリアルが厚くなるのは、画面が使う人の手に馴染んでいないサインです。

原因は説明が足りないことではなく、画面の主語が提供側になっていることにあります。

ユーザーの道具にする

画面は、使う人が自分の仕事を片づけるための道具です。提供側の都合を通す場所ではありません。管理画面に運営側の見たい数字を並べたり、資料ダウンロードのフォームに営業が欲しい項目を足したりすると、ひと続きで終わるはずの作業が遠回りになります。要素をひとつずつ指さして「これは誰の得ですか」と聞き、提供側の得しか出てこない要素が並んでいたら疑ってください。

ユーザーが自分なりの方法で作業を遂行でき、それを改善できるようにする

同じ業務でも、段取りは会社ごと人ごとに違います。手順を 1 本道に固定すると、その道から外れた人の作業が一気に重くなります。一覧の絞り込み条件を保存できる、CSV でまとめて登録できる、といった逃げ道を残しておくと、使い込んだ人ほど速く終わらせられます。ウィザード形式しか用意されていない画面は、毎日何十件も処理する担当者にとって、最初の一週間だけ親切な設計です。

ユーザーを教育するのではなくユーザーが学習できるようにする

人は説明を読んで覚えるのではありません。やってみて、結果を見て覚えます。初回に 12 画面のチュートリアルを流しても、実際に操作するころには忘れていますから、押す前に何が起きるかを想像できる一行をボタンの横に置くほうが効きます。改善案として「操作説明の動画をつくりましょう」が最初に出てきたら、画面そのものが説明を必要としている合図です。

ユーザーイリュージョンをもたらす

使う人が向き合っているのは、デスクトップやゴミ箱のような比喩でできた、一貫した見立ての世界です。Xerox PARC で GUI をつくった Alan Kay は、この状態をユーザーイリュージョンと呼びました。「下書き・公開・アーカイブ」で通していた画面に急に「ステータス 3」と出てくれば、その世界は破れます。文言だけを抜き出して読み返すと、社内用の言葉が漏れている箇所が見つかります。

デザインは新しい意味を提案する

使いやすさを磨く仕事の隣に、それが何であるかを提案し直す仕事があります。Roberto Verganti は 2009 年の著書『Design-Driven Innovation』で、これを意味のイノベーションとして整理しました。問い合わせフォームを「営業に捕まる場所」から「相談を整理して持ち帰れる場所」へ読み替えると、置く項目も文言も送信後の画面も変わります。使う人に聞いて出てくる答えではないので、こちらが仮説を立てて差し出す仕事になります。

人類にポジティブな影響を与える

設計の影響は、その画面を使う人だけで終わりません。ISO 9241-210:2019 は人間中心設計を、人の健やかさ、満足、アクセシビリティ、持続可能性を高め、健康や安全への悪影響を打ち消す取り組みだと説明しています。同じ規格が「利用者中心」ではなく「人間中心」という語を選んだのも、利用者以外の関係者への影響まで含めるためです。解約の導線を隠したり、同意を取ったことにしたりすれば短期の数字は上がりますが、外で説明できない設計は誰かに不利益を押しつけています。

9 カテゴリ 100 項目は、言い方こそ違っても同じ一点に帰っていきます。使う人が背負うはずだった手間を、つくる側がどこまで引き受けるのかということです。発注レビューでも自己点検でも、迷ったらこの物差しを最後に当ててください。

まとめ

100 項目を暗記する必要はありません。レビューの場で要るのは、気になった箇所に原則の名前をひとつ付けられることです。名前が付いた瞬間に、指摘は好みの話から直せる話に変わります。

手を付ける順番も決まっています。読めない・押せないを先に潰し (第 8 章)、次に入力の設問を減らし (第 4 章)、そのあとで待ち時間と見た目に移ります (第 6・7 章)。

直したときに数字が動く順番も、だいたいこの順です。

まずは 1 画面だけ選び、この記事を横に置いて通しで当ててみてください。粒のそろった指摘一覧が、その日のうちにできあがります。

→ 点検結果を制作会社に渡す形にまとめるところまでは、巻末の実行キット③で作れます。

あわせて読みたい記事を 3 本挙げておきます。

• BtoB ペルソナの作り方 — 第 2 章「ユーザーの言葉を使う」を、実際の語彙リストに落とすところまで
• OGP 画像の参考サイト 5 選 — 第 7 章のトーン＆マナーを、SNS で共有される画面まで広げる話
• サービスサイトの段階公開 — 100 項目を一度に満たそうとせず、公開しながら直していく進め方

humbulls の Growth Partner では、画面の点検から改善の実装、効果の計測までを伴走しています。自社サイトのどこから直すべきかを一緒に決めたい場合はご相談ください。

🤖 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 — Nielsen Norman Group (取得: 2026-08)
• Understanding SC 2.5.8: Target Size (Minimum) — W3C WAI / WCAG 2.2 (取得: 2026-08)
• Accessibility — Human Interface Guidelines — Apple (取得: 2026-08)
• Touch Target — Material Design (取得: 2026-08)
• 10 Usability Heuristics for User Interface Design — Nielsen Norman Group (取得: 2026-08)
• Understanding SC 1.4.1: Use of Color — W3C WAI / WCAG 2.2 (取得: 2026-08)