WindowsアプリUX設計 - 利用環境別の優先順位

Windows アプリの UX を考えるとき、最初に「モダンに見えるか」「余白がきれいか」から入ると、少し順番を間違えやすいです。

Windows デスクトップでは、UX は見た目だけでは決まりません。

• キーボードでどこまで完結できるか
• マウス前提なのか、タッチ前提なのか
• 長時間使うのか、たまに数分だけ使うのか
• 監視なのか、入力なのか、現場端末なのか
• 誤操作したときに、どのような影響や損失が生じるか
• 文字拡大、コントラストテーマ、スクリーンリーダーなどの支援技術を使っても問題なく操作できるか

このあたりが全部まとめて UX です。

flowchart TB
    accTitle: 見た目だけでは決まらないUX
    accDescr: キーボードで完結できるか、マウスかタッチか、利用時間と用途、誤操作したときの影響や損失、スクリーンリーダーなどの支援技術を使っても問題なく操作できるかまで全部まとめてUXであることを示す図。
    a1["入力方式と操作の完結度"] --> a4["全部まとめてUX"]
    a2["利用時間と用途"] --> a4
    a3["ミスのコストと支援技術"] --> a4
    a4 -.-> a5["「モダンに見えるか」から入ると順番を間違える"]

図1: WindowsデスクトップのUXは、見た目より先に利用文脈の束で決まる。

さらに厄介なのが、BtoC と BtoB で重心が違う ことです。 ただし、ここで「BtoB だから情報を詰め込めばよい」「BtoC だからふんわり軽く作ればよい」と考えると、だいたいどこかで事故ります。

たとえば同じ BtoB でも、

• 経理入力や受発注管理のような 事務系アプリ
• 工場、倉庫、受付、検査装置のような 現場端末
• 24 時間監視や保守対応の 運用画面

では、良い UX の条件がかなり違います。

逆に BtoC でも、

• 個人向けの小さなユーティリティ
• 画像編集、音楽制作、投資分析のような上級者寄りツール

では、UI の密度もショートカット操作への要求も全然違います。

flowchart TB
    accTitle: 同じラベルでも条件が違う
    accDescr: 同じBtoBでも事務系アプリ・現場端末・運用画面で良いUXの条件がかなり違い、BtoCでも小さなユーティリティと上級者寄りツールでは密度もショートカット操作への要求も全然違うことを示す図。
    b0["BtoBという同じラベル"] --> b1["事務系・現場端末・運用画面"]
    b1 --> b2["良いUXの条件がかなり違う"]
    c0["BtoCという同じラベル"] --> c1["ユーティリティ・上級者ツール"]
    c1 --> c2["密度もショートカット操作への要求も違う"]

図2: BtoC / BtoBという同じラベルの中でも、良いUXの条件は分かれる。

Microsoft の Windows 向け設計ガイダンスも、Windows アプリの設計は 直感的でアクセスしやすく、入力方式やフォームファクターをまたいで一貫して動くこと を重視しています。¹²

この記事では、Windows アプリの UX を 用途ごとの判断表 として整理します。 設計レビューや画面設計の初期段階で、「このアプリは何を優先するべきか」を切り分けやすくするのが目的です。

この記事の対象読者と前提

この記事で使う用語

1. まず結論

先に雑に言ってしまうと、こうです。

• BtoC では、まず 初回理解のしやすさ、安心感、設定の少なさ、導線の素直さ を優先します
• BtoB では、まず 継続効率、誤操作防止、キーボード対応、安定した配置 を優先します
• ただし BtoB の現場端末 は、密度より 明快さ、大きな操作対象、短い導線 が優先です
• ただし BtoC の上級者向けツール は、簡単さより 情報密度、ショートカット、カスタマイズ性 が優先です
• Windows アプリでは、キーボード / マウス / タッチ / テキスト拡大 / コントラストテーマ / 支援技術 まで含めて UX を考えたほうが、あとで設計が壊れにくいです¹³⁴⁵⁶⁷

最初に本当に決めるべきなのは、BtoC か BtoB かだけではありません。 先に言語化したいのは、この 5 つです。

1. 誰が使うか（初心者、熟練者、混在）
2. どこで使うか（机上、会議室、現場、工場、受付、屋外）
3. 何で操作するか（キーボード、マウス、タッチ、ペン、バーコード、支援技術）
4. どれくらい使うか（初回中心、たまに、毎日、1 日中）
5. ミスしたときのコストは何か（軽い、重い、危険、監査対象）

この 5 つが見えると、UI の密度、ナビゲーション、ショートカット、確認ダイアログ、カスタマイズ性の優先順位がぐっと決めやすくなります。

flowchart TB
    accTitle: 先に言語化する5つの問い
    accDescr: 誰が使うか、どこで使うか、何で操作するか、どれくらい使うか、ミスしたときのコストは何かの5つが見えると、UIの密度やナビゲーション、確認ダイアログなどの優先順位が決めやすくなることを示す図。
    q1["1. 誰が使うか"] --> q2["2. どこで使うか"]
    q2 --> q3["3. 何で操作するか"]
    q3 --> q4["4. どれくらい使うか"]
    q4 --> q5["5. ミスのコストは何か"]
    q5 --> q6["密度・ナビ・ダイアログの優先順位が決まる"]

図3: BtoCかBtoBかより先に、5つの問いを言語化すると優先順位が決まる。

この記事の知識マップ

この記事はWindowsアプリのUX設計を、BtoC/BtoBという分類だけでなく、誰が・どこで・何で操作するか・どれくらい使うか・ミスのコストは何かという利用文脈で判断すべきだと整理しています。BtoC向けユーティリティには上部ナビと初回理解のしやすさが向き、事務系BtoBにはリスト/詳細とキーボード操作性が、監視・運用には左側ナビと色だけに頼らない状態表示、複数経路のコマンド、不可逆操作への確認ダイアログが、現場端末には十分大きなタッチターゲットとhoverに依存しない設計が、専門家向けツールにはタブと厚いキーボード対応が向くとしています。あわせて、タッチターゲット7.5mm四方やコントラスト比4.5:1のような数値基準と、文字拡大やコントラストテーマに追随するレイアウトの重要性も扱っています。

flowchart LR
    accTitle: WindowsアプリUX設計の判断軸の知識マップ
    accDescr: 誰が・どこで・何で操作するかという利用文脈がナビゲーションパターンやタッチターゲット、キーボード操作性、ダイアログの使い方といったUXの優先順位を決めることを示す図
    tob_field_device_ui["BtoB現場端末・装置UI・キオスク"]
    tob_back_office_app["BtoB事務入力・バックオフィスアプリ"]
    top_navigation["上部ナビゲーション"]
    toc_utility_app["BtoC向けユーティリティ/個人向けアプリ"]
    left_navigation["左側ナビゲーション"]
    tob_monitoring_app["BtoB監視・運用アプリ"]
    list_detail_navigation["リスト/詳細ナビゲーション"]
    tab_navigation["タブナビゲーション"]
    expert_tool_ui["専門家向け編集・分析ツール"]
    touch_target_size_guideline["タッチターゲットの最小サイズ基準"]
    color_only_state_indication["色だけによる状態表現"]
    hover_only_interaction["hover前提の操作"]
    multi_entry_commanding["コマンドの複数経路提供"]
    inline_validation_error["インライン検証エラー表示"]
    confirmation_dialog_for_irreversible_action["不可逆操作の確認ダイアログ"]
    keyboard_accessibility["キーボード操作性"]
    contrast_theme_support["コントラストテーマ対応"]
    fixed_size_layout["固定サイズレイアウト"]
    text_contrast_ratio_guideline["テキストのコントラスト比基準"]
    content_spacing_guideline["コンテンツ間隔の基準(8/12/16epx)"]
    tray_resident_app["常駐ツール・トレイアプリ"]
    custom_control_overuse["カスタムコントロールの作りすぎ"]
    top_navigation -->|"推奨される対応"| toc_utility_app
    left_navigation -->|"推奨される対応"| tob_monitoring_app
    left_navigation -->|"推奨される対応"| tob_back_office_app
    list_detail_navigation -->|"推奨される対応"| tob_back_office_app
    tab_navigation -->|"推奨される対応"| expert_tool_ui
    touch_target_size_guideline -->|"推奨される対応"| tob_field_device_ui
    color_only_state_indication -->|"用いるのは非推奨"| tob_monitoring_app
    hover_only_interaction -->|"用いるのは非推奨"| tob_field_device_ui
    hover_only_interaction -->|"用いるのは非推奨"| tob_monitoring_app
    multi_entry_commanding -->|"推奨される対応"| tob_monitoring_app
    multi_entry_commanding -->|"推奨される対応"| expert_tool_ui
    inline_validation_error -->|"推奨される対応"| tob_back_office_app
    confirmation_dialog_for_irreversible_action -->|"推奨される対応"| tob_monitoring_app
    keyboard_accessibility -->|"推奨される対応"| tob_back_office_app
    keyboard_accessibility -->|"推奨される対応"| expert_tool_ui
    keyboard_accessibility -->|"推奨される対応"| hover_only_interaction
    contrast_theme_support -->|"推奨される対応"| fixed_size_layout
    contrast_theme_support -.->|"前提とする"| text_contrast_ratio_guideline
    content_spacing_guideline -->|"推奨される対応"| fixed_size_layout
    confirmation_dialog_for_irreversible_action -->|"用いるのは非推奨"| tray_resident_app
    expert_tool_ui -.->|"両立しない"| toc_utility_app
    contrast_theme_support -->|"推奨される対応"| custom_control_overuse
    keyboard_accessibility -->|"推奨される対応"| custom_control_overuse

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全23件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. BtoC / BtoB は入口だが、答えではない

BtoC / BtoB という分け方は、最初の入口としては便利です。 ただし、UX の正解を決める力が強いのは、買い手の種類よりも、使い方の種類 です。

たとえば、ざっくり 2 軸で見るとこんな感じです。

つまり、

• BtoC = いつでも軽い UI
• BtoB = いつでも高密度 UI

ではありません。

Windows アプリの設計ガイダンスでも、デバイス、入力の種類、フォームファクターをまたいで一貫して使えること が重視されていますし、アクセシビリティの観点でも、障害の有無だけでなく、明るい屋外、共有スペース、静かな場所、騒がしい場所 のような環境制約まで含めて考えることが重要だとされています。¹²

flowchart TB
    accTitle: 買い手の種類より使い方の種類
    accDescr: BtoCはいつでも軽いUI、BtoBはいつでも高密度UIという等式は成り立たず、UXの正解を決める力が強いのは買い手の種類よりも使い方の種類であることを示す図。
    e1["BtoC = いつでも軽いUI"] --> e3["この等式は成り立たない"]
    e2["BtoB = いつでも高密度UI"] --> e3
    e3 --> e4["正解を決めるのは使い方の種類"]
    e4 -.-> e5["環境制約まで含めて考える"]

図4: UXの正解を決めるのは、買い手の種類より使い方の種類になる。

なので、BtoC / BtoB を見たあとに、さらに次の軸で切るのがおすすめです。

ここを先に切っておくと、会議中の「なんとなくモダン」「なんとなく業務っぽい」議論がかなり減ります。

3. 一枚で見る用途別の判断表

まずは、いちばん実務で使いやすい表を置きます。

この表だけでも、だいたいの方向は見えてきます。 特に大事なのは、BtoB でも現場端末は高密度 UI が正解ではない こと、そして BtoC でも上級者ツールは軽さより効率が正義になる ことです。

flowchart TB
    accTitle: ラベルと正解が逆転する2例
    accDescr: BtoBでも現場端末は高密度UIが正解ではなく、BtoCでも上級者ツールは軽さより効率が正義になるという、ラベルから想像する正解が逆転する2つの例を示す図。
    f1["BtoBの現場端末"] --> f2["高密度UIが正解ではない"]
    f3["BtoCの上級者ツール"] --> f4["軽さより効率が正義"]
    f2 --> f5["ラベルではなく用途で決める"]
    f4 --> f5

図5: 判断表で特に大事な、ラベルと正解が逆転する2つの行。

急いでいるなら、この章で止めて構いません。 次の 4 章は、この表の各行を「なぜそうなるのか」「具体的に何を置くのか」まで展開したものです。表と同じ結論は繰り返さず、表に書ききれなかった判断材料だけを読む、という使い方ができます。

4. 用途別の設計方針

4.1 BtoC 向けユーティリティ / 個人向けアプリ

BtoC の小さな Windows アプリでは、まず 「起動してすぐ使える」 が何より強いです。

特に重視したいのは、このあたりです。

• 最初の 1 画面で、何をするアプリか分かる
• 主要操作が 1 つか 2 つに絞られている
• 空状態が不親切ではない
• 危ない操作が取り消せる
• 設定項目を最初から全部見せない

ここでやりがちなのが、技術的にはできることを全部並べてしまうことです。 でも BtoC の軽いツールでは、多機能であること より すぐ使えること のほうが価値になる場面が多いです。

Windows のナビゲーション設計でも、すべてのアプリに共通の正解はなく、まずは 一貫性、シンプルさ、明快さ が重視されています。標準コントロールや標準的な場所を使うと、予測しやすくなります。⁸

なので BtoC 向けでは、

• 小さければ単一画面
• セクションが並列なら上部ナビ
• 設定は段階的に見せる
• 主要アクションは明るく、その他は静かに

くらいの整理で十分なことが多いです。

flowchart TB
    accTitle: BtoC向けの整理の方向
    accDescr: BtoC向けでは、起動してすぐ使えることを軸に、小さければ単一画面、セクションが並列なら上部ナビ、設定は段階的に見せ、主要アクションは明るくその他は静かに、という整理で十分なことが多いことを示す図。
    g1["起動してすぐ使える"] --> g2["小さければ単一画面"]
    g1 --> g3["並列なら上部ナビ"]
    g1 --> g4["設定は段階的に見せる"]
    g4 -.-> g5["主要アクションは明るく、その他は静かに"]

図6: BtoCの軽いツールは「多機能」より「すぐ使える」に寄せて整理する。

ただし、BtoC でも 写真編集、動画編集、作曲、投資分析、開発支援 のような上級者向けアプリになると話が変わります。 その場合は、BtoC というラベルより 熟練度 と 利用時間 を見たほうが、正解に近づきます。

4.2 BtoB 事務入力・バックオフィス

事務系 BtoB アプリで重要なのは、見た目の軽やかさより 作業が止まらないこと です。

毎日使うユーザーは、数日で UI に慣れます。 その後に効いてくるのは、こういう部分です。

• キーボードだけでどこまで行けるか
• 一覧と明細を往復しやすいか
• 重要な列や状態が一目で分かるか
• フィルタや並び替えを保持できるか
• エラーがその場で直せるか

Microsoft のキーボードアクセシビリティ ガイダンスでも、アプリは キーボードで全機能へ到達できること が重要とされ、Tab 順、フォーカス、Enter / Space による操作、ショートカットの実装が推奨されています。³

また、アクセス キーはアクセシビリティだけでなく、キーボードを好むパワーユーザーの効率向上にも有効です。適切な場所では、カスタム コントロールも含めてアクセス キーをサポートすることが推奨されています。⁹

事務入力系では、ナビゲーションとして リスト/詳細 が手堅いです。 Windows のナビゲーション ガイドでも、リスト/詳細は 項目を頻繁に切り替えながら、詳細の表示や更新を行う用途 に向いており、メール受信箱、連絡先リスト、データ入力 のようなケースに適しているとされています。⁸

つまり、こんな構成が素直です。

• 左に機能分類
• 中央に一覧
• 右か下に明細 / 編集
• 上に検索、フィルタ、主要コマンド
• よく使う操作はショートカット対応

flowchart TB
    accTitle: 事務入力の素直な構成
    accDescr: 上に検索・フィルタ・主要コマンド、左に機能分類、中央に一覧、右か下に明細と編集を置き、よく使う操作はショートカットに対応させる事務入力系の素直な構成を示す図。
    h1["上: 検索・フィルタ・主要コマンド"] --> h2["左: 機能分類"]
    h2 --> h3["中央: 一覧"]
    h3 --> h4["右か下: 明細・編集"]
    h4 -.-> h5["よく使う操作はショートカット対応"]

図7: リスト/詳細を軸にした、事務入力系の素直な画面構成。

逆に、避けたいパターンも挙げておきます。

• 1 操作ごとにダイアログ
• 列が少なすぎて一覧性が低い
• 主要操作が右クリックの奥にしかない
• アイコンだけで意味を表そうとする
• タブ順がめちゃくちゃで Enter も Space も効かない

入力エラーについても、フィールドに紐づく検証エラーはダイアログでなく画面内で出す ほうが自然です。Windows のダイアログ ガイドでも、パスワード欄などの 文脈に結びついた検証エラーにはダイアログを使わず、インライン表示を使う ことが推奨されています。¹⁰

4.3 BtoB 監視・運用

監視・運用画面の UX は、「使いやすい」より先に 見逃さない、誤らない、止まらない が重要です。

ここでの優先順位は、だいたいこうなります。

• 異常の有無が一目で分かる
• 異常の重要度が分かる
• 現在値だけでなく、変化や時系列が追える
• 危険操作の導線が軽すぎない
• ログ、履歴、原因調査へすぐ飛べる

この種の画面では、状態表現 が UX の中心です。 状態は、できるだけ 色 + 文字 + アイコン + 時刻 の複数要素で表したほうが安全です。 色だけで状態を表すと、見落としや識別ミスが起きやすくなりますし、アクセシビリティ上も弱くなります。¹¹

flowchart TB
    accTitle: 状態は複数要素で表す
    accDescr: 監視・運用画面では状態表現がUXの中心で、色だけで表すと見落としや識別ミスが起きやすいため、色・文字・アイコン・時刻の複数要素で表すほうが安全であることを示す図。
    i1["色だけで状態を表す"] --> i2["見落とし・識別ミスが起きやすい"]
    i2 -.->|"代わりに"| i3["色+文字+アイコン+時刻で表す"]
    i3 --> i4["見逃しも誤認も減って安全"]

図8: 監視画面の状態は、色だけでなく複数要素の組で表す。

ナビゲーションは、監視対象が多いなら左側ナビ、個別対象の掘り下げはドリルダウン、詳細はログや時系列で出す、という整理が扱いやすいです。 Windows のナビゲーション ガイドでも、左側ナビは 最上位項目が多い場合 や、ページ切り替えがひっきりなしではない構成に向いています。⁸

操作面では、コマンドを 1 か所にしか置かないのも危険です。 Windows のコマンド設計ガイドでは、コマンドは ボタン、コンテキストメニュー、ショートカット、ジェスチャなど複数の面から利用できる ようにし、すべての関連コマンドをコンテキストメニューか CommandBarFlyout に含める ことが推奨されています。hover だけで出る操作に依存すると、タッチ端末や支援技術で使えなくなるからです。¹²¹³

危険操作の確認ダイアログも、ここでは重要です。 ただし「とりあえず何でも確認する」は逆効果です。 本当に確認したいのは、止める、削除する、切り替える、遮断する、書き換える といった不可逆寄りの操作です。 ダイアログを出すなら、

• 何が起きるかを最初の 1 行で明確に書く
• ボタン文言は OK / Yes ではなく、削除 / 停止 / 遮断 のように具体的にする
• 安全側のボタンを必ず置く

の 3 つは最低限守ったほうがよいです。¹⁰

flowchart TB
    accTitle: 確認ダイアログの3原則
    accDescr: 本当に確認したいのは止める・削除する・遮断するなどの不可逆寄りの操作で、出すなら何が起きるかを最初の1行で書き、ボタン文言を具体的にし、安全側のボタンを必ず置くことを示す図。
    j1["不可逆寄りの操作だけ確認する"] --> j2["何が起きるかを最初の1行で"]
    j1 --> j3["ボタン文言は具体的に"]
    j1 --> j4["安全側のボタンを必ず置く"]
    j2 -.-> j5["「とりあえず何でも確認」は逆効果"]

図9: 確認ダイアログは不可逆操作に絞り、3つの最低限を守って出す。

4.4 BtoB 現場端末・装置 UI・キオスク

現場端末は、Windows アプリ UX の中でもかなり別種です。

• 座っていない
• 手袋をしているかもしれない
• 片手しか空いていない
• 画面をじっくり見ない
• 時間圧がある
• 明るい現場や騒がしい場所で使う

という条件が普通にあります。

Microsoft のアクセシビリティ ガイダンスでも、良い Windows アプリは障害の有無だけでなく、明るい日差し、共有スペース、騒音、静寂、調理中のような状況 を含む環境制約を考慮することが重要だとされています。²

また、タッチの設計では、

• タッチには hover がない
• 指や手で UI が 隠れる（occlusion）
• 画面の一部は 手の姿勢的に押しにくい
• 視覚的フィードバックが重要

といった差があります。⁴

flowchart TB
    accTitle: タッチ設計の4つの差
    accDescr: タッチにはhoverがなく、指や手でUIが隠れ、画面の一部は手の姿勢的に押しにくく、視覚的フィードバックが重要という、設計上の差を示す図。
    k1["タッチ操作"] --> k2["hoverがない"]
    k1 --> k3["指や手でUIが隠れる"]
    k1 --> k4["姿勢的に押しにくい場所がある"]
    k4 -.-> k5["視覚的フィードバックが重要になる"]

図10: タッチはhoverと遮蔽の前提が違い、フィードバックの見せ方が要になる。

なので現場端末では、だいたいこの方向に寄せます。

• ボタンやリスト項目は十分大きく
• 1 画面 1 目的に近づける
• 操作後の反応をはっきり見せる
• フローを段階化する
• 入力はなるべく 自由入力より選択、スキャン、定型 に寄せる
• 状態は画面の上部か中央で明快に出す

逆に避けたいのは、

• 小さな文字
• 小さなヒット領域
• hover 前提のツールチップ依存
• 深い階層
• 1 画面に大量の情報
• 長い自由入力

です。

BtoB だから密度が高いほうがよい、という雑な発想がいちばん外しやすいのは、この領域です。 ここはむしろ、業務アプリの中でも特に明快さ優先 の世界です。

flowchart TB
    accTitle: 現場端末は明快さ優先
    accDescr: 現場端末では1画面1目的に近づけ、入力は自由入力より選択・スキャン・定型に寄せ、操作後の反応をはっきり見せるという、業務アプリの中でも特に明快さ優先の方向を示す図。
    l1["現場端末・装置UI"] --> l2["1画面1目的に近づける"]
    l1 --> l3["入力は選択・スキャン・定型に寄せる"]
    l1 --> l4["操作後の反応をはっきり見せる"]
    l2 --> l5["業務アプリの中でも特に明快さ優先"]
    l3 --> l5
    l4 --> l5

図11: 現場端末は密度ではなく、明快さ・大きな操作対象・短い導線に寄せる。

4.5 専門家向け編集・分析ツール

専門家向けのツールでは、「分かりやすくしてほしい」より「手を止めないでほしい」が勝つことがあります。

たとえば、

• CAD
• 波形解析
• 映像編集
• 画像処理
• 音楽制作
• 開発支援
• データ分析
• 監査 / 診断ツール

のようなものです。

この種のアプリでは、こういう要素が効きます。

• 情報密度
• 複数ペイン
• タブ
• コンテキストメニュー
• ショートカット
• レイアウト保存
• 列や表示項目のカスタマイズ
• Undo / Redo
• 作業状態の復元

Windows のナビゲーション ガイドでも、タブ は複数のページやドキュメントを開閉・並べ替えしたいケースに向いています。⁸ また、Windows のコマンド設計では、コマンドは複数の UI 面で共有し、入力方式が違っても同じ操作へ到達できるようにすることが推奨されています。¹²

この種のツールでやりがちなのは、初心者に優しくしようとして 全部を深いメニューに隠す ことです。 でも、熟練者は毎日何百回も同じ操作をします。 その人たちにとって重要なのは、最初の 5 分のやさしさより、100 時間使ったあとも疲れにくいこと です。

なので、上級者向けでは

• 高頻度操作は近く
• 補助機能はやや奥
• 高度機能は消さずに整理する
• 表示レイアウトを保存する
• キーボード操作を厚くする

という設計が効きやすいです。

flowchart TB
    accTitle: 熟練者向けの配置の考え方
    accDescr: 熟練者は毎日何百回も同じ操作をするため、最初の5分のやさしさより100時間使ったあとも疲れにくいことが重要で、高頻度操作は近く、補助機能はやや奥、高度機能は消さずに整理することを示す図。
    n1["熟練者は毎日何百回も同じ操作"] --> n2["高頻度操作は近くに置く"]
    n1 --> n3["補助機能はやや奥に"]
    n1 --> n4["高度機能は消さずに整理"]
    n2 -.-> n5["最初の5分より100時間後の疲れにくさ"]

図12: 専門家向けツールは、操作頻度に合わせた距離で機能を配置する。

4.6 常駐ツール・トレイアプリ

常駐系は、アプリの存在感を出しすぎないことが、むしろ UX です。

たとえば、

• 同期状態
• 接続状態
• バックアップ
• 音声 / カメラ / デバイス切り替え
• VPN / エージェント / ランチャー
• 通知ハブ

のようなアプリでは、メイン画面が主役ではないことが多いです。

優先したいのは、

• トレイや小さなメニューからすぐ触れる
• 今の状態が分かる
• 必要なときだけ通知する
• 通知から直接必要操作へ行ける
• メイン画面が前面を奪いすぎない

です。

避けたいのは、

• 些細なことでダイアログを出す
• 起動のたびにメイン画面を開く
• 背景動作の状態が見えない
• 通知が多すぎて全部無視される

です。

この種のアプリは、「機能をたくさん持つか」より 邪魔しないか のほうが UX を左右しやすいです。

flowchart TB
    accTitle: 常駐ツールは邪魔しないことがUX
    accDescr: 常駐系はトレイや小さなメニューからすぐ触れ、今の状態が分かり、必要なときだけ通知することを優先し、通知が多すぎると全部無視されることを示す図。
    r1["トレイからすぐ触れる"] --> r4["邪魔しないことがUX"]
    r2["今の状態が分かる"] --> r4
    r3["必要なときだけ通知"] --> r4
    r4 -.-> r5["通知が多すぎると全部無視される"]

図13: 常駐ツールは存在感を出しすぎないことが、そのままUXになる。

5. ナビゲーションの判断表

Windows のナビゲーション ガイドでは、すべてのアプリに効く 1 つのナビゲーションデザインはない としたうえで、一貫性、シンプルさ、明快さ を原則にしています。さらに、ユーザーが期待する場所に標準コントロールを置くことで、予測しやすい UI になります。⁸

flowchart TB
    accTitle: ナビゲーション設計の原則
    accDescr: すべてのアプリに効く1つのナビゲーションデザインはなく、一貫性・シンプルさ・明快さを原則に、ユーザーが期待する場所に標準コントロールを置いて予測しやすいUIにすることを示す図。
    s0["唯一の正解パターンはない"] --> s1["一貫性"]
    s0 --> s2["シンプルさ"]
    s0 --> s3["明快さ"]
    s3 -.-> s4["標準コントロールを期待される場所に置く"]

図14: ナビゲーションに唯一の正解はなく、3つの原則と標準の場所で予測しやすくする。

実務では、だいたいこの表で切ると考えやすくなります。

Windows のナビゲーション ガイドでは、特に次のような使い分けが示されています。⁸

• 上部ナビ: すべてのナビゲーション項目を画面に表示したいとき
• 左側ナビ: 最上位項目が多いとき、頻繁にページ切り替えしないとき
• リスト/詳細: 項目切り替えが多く、詳細表示や更新が必要なとき
• タブ: 複数のドキュメントやページを動的に開閉したいとき
• パンくず: 深い階層で、戻り道を分かりやすくしたいとき

5.1 骨格だけのワイヤーフレーム

言葉だけだと像が結びにくいので、代表的な 4 つの骨格を並べておきます。 細部は無視して、何がどこに置かれるか だけ見てください。

[ 上部ナビゲーション ]  同じレベルのページを全部見せたいとき
+-------------------------------------------------------------
| AppName        ホーム | 変換 | 履歴 | 設定
+-------------------------------------------------------------
|
|    主コンテンツ
|    1 画面 1 目的に寄せる
|
+-------------------------------------------------------------


[ 左側ナビゲーション ]  最上位項目が多いとき
+-------------------------------------------------------------
| AppName                                 検索 [           ]
+-------------------------------------------------------------
| ダッシュボード  |
| 装置一覧        |    主コンテンツ
| アラート        |
| ジョブ          |
| レポート        |
| 設定            |
+-------------------------------------------------------------


[ リスト/詳細 ]  項目を切り替えながら、詳細を見る・更新する
+-------------------------------------------------------------
| 検索 [          ]  絞り込み: 未処理 / すべて      [新規] [削除]
+-------------------------------------------------------------
| 一覧             |  詳細 / 編集
|  > 伝票 1001     |    伝票番号   1001
|    伝票 1002     |    取引先     ...
|    伝票 1003     |    明細行     ...
|    伝票 1004     |
|                  |    [ 保存 ]   [ 取消 ]
+-------------------------------------------------------------


[ ダッシュボード + ドリルダウン ]  異常を見つけて掘る
+-------------------------------------------------------------
| 全体   正常 22    注意 3    異常 1        更新 0.5 秒前
+-------------------------------------------------------------
| 異常 1 件
|   ! ラインB 検査装置    応答なし    48 秒前    [ 詳細 ]
| 注意 3 件
|   - ラインA カメラ      値が古い    12 秒前    [ 詳細 ]
|   ...
+-------------------------------------------------------------
              |
              |  [ 詳細 ] を押す
              v
+-------------------------------------------------------------
| < 一覧へ戻る       ラインB 検査装置 / 応答なし
+-------------------------------------------------------------
| 現在値 | 時系列グラフ | イベントログ | 操作
+-------------------------------------------------------------

4 つを並べると、選び方の軸がはっきりします。

• 上部ナビと左側ナビの分かれ目は、最上位項目の数 です。全部を横に並べきれるなら上部、並べきれないなら左側です
• リスト/詳細の主役は右側ではなく左側の一覧 です。一覧の情報量が足りないと、詳細を何度も開き直すことになります
• ダッシュボードは「異常が何件あるか」を最初の 1 行に出す のが要点です。掘る先へ行ったら、必ず戻り道を用意します

要するに、ナビゲーションは「見た目の好み」ではなく、情報構造と作業構造の反映 です。

flowchart TB
    accTitle: 上部ナビと左側ナビの分かれ目
    accDescr: 上部ナビと左側ナビの分かれ目は最上位項目の数で、全部を横に並べきれるなら上部、並べきれないなら左側になり、ナビゲーションは情報構造と作業構造の反映であることを示す図。
    t1{"最上位項目を横に並べきれるか"} -->|"並べきれる"| t2["上部ナビ"]
    t1 -->|"並べきれない"| t3["左側ナビ"]
    t2 -.-> t4["ナビは情報構造と作業構造の反映"]
    t3 -.-> t4

図15: 骨格の選択は見た目の好みではなく、情報構造から決まる。

6. 入力デバイスとコマンド設計の判断表

Windows アプリは、できるだけ多くの入力方式に対応するほうが柔軟で使いやすくなります。Microsoft のガイドでも、ジェスチャ、音声、タッチ、タッチパッド、マウス、キーボード など、できる限り多くの入力を考慮することが推奨されています。¹⁴

また、Windows のプラットフォームコントロールは複数の入力方式をある程度吸収してくれるので、標準コントロールを素直に使う のがまず強いです。⁴⁸

flowchart TB
    accTitle: 標準コントロールがまず強い
    accDescr: ジェスチャ・音声・タッチ・マウス・キーボードなどできる限り多くの入力を考慮することが推奨され、プラットフォームの標準コントロールは複数の入力方式をある程度吸収するため、素直に使うのがまず強いことを示す図。
    u1["多様な入力方式への対応"] --> u2["標準コントロールがある程度吸収する"]
    u2 --> u3["標準コントロールを素直に使うのがまず強い"]

図16: 多様な入力方式は、標準コントロールに吸収させるのが近道になる。

実務で使いやすい形にすると、こうなります。

キーボードまわりで特に重要なのは、以下の点です。³⁹

• キーボードだけで全機能へ到達できること
• Tab 順が視覚順と大きくズレないこと
• Enter / Space で押せるべき要素が押せること
• 重要機能にショートカットがあること
• 高頻度操作にはアクセス キーやアクセラレータを用意すること

タッチまわりには、こんな特性があります。⁴

• hover はない
• 指や手で UI が隠れる
• 押せる場所は見た目より狭く感じる
• 視覚的フィードバックが必要
• 直接操作に合う UI と、間接入力に合う UI は違う

6.1 「十分大きく」ではなく数字で決める

設計レビューで揉めやすいのは、「十分大きく」「はっきり」で止めてしまう ところです。 Microsoft のガイドが数値を出している項目は、その数値をそのまま合否の基準にしたほうが、議論が短く済みます。

数値が決まると、レビューの言い方も変わります。 「このボタン小さくないですか」ではなく「このボタンは 32px なので、7.5mm の基準に届いていません」と言えるようになると、直すかどうかの判断がその場で終わります。

flowchart TB
    accTitle: 数値で決めるとレビューが速い
    accDescr: 「十分大きく」「はっきり」で止めるとレビューで揉めるため、ガイドの数値をそのまま合否基準にすると、基準に届いているかどうかで話が終わり、直すかどうかの判断がその場で終わることを示す図。
    v1["「十分大きく」で止める"] --> v2["レビューで揉める"]
    v2 -.->|"代わりに"| v3["数値をそのまま合否基準にする"]
    v3 --> v4["基準に届くかどうかで言える"]
    v4 --> v5["判断がその場で終わる"]

図17: 数値を合否基準にすると、サイズの議論がその場で終わる。

なお、WinUI の標準コントロールは既定でこのターゲットサイズに沿うように作られています。¹⁵ 逆に言うと、自作コントロールとカスタム描画のところだけが危ない ということです。

コマンド設計では、Windows のコマンド ガイドがよい参考になります。 特に重要なのは、コマンドを複数の UI 面から使えるようにする ことです。¹²

• ボタンから押せる
• コンテキストメニューにもある
• ショートカットでも呼べる
• 必要ならスワイプやジェスチャもある

そして、すべての関連コマンドをコンテキストメニューや CommandBarFlyout に入れる ことが推奨されています。hover 中だけ見える操作に依存すると、タッチ専用端末で詰まります。¹²

flowchart TB
    accTitle: コマンドは複数の面から
    accDescr: コマンドはボタンから押せ、コンテキストメニューにもあり、ショートカットでも呼べるように複数のUI面から使えるようにし、hover中だけ見える操作に依存するとタッチ専用端末で詰まることを示す図。
    w1["同じコマンド"] --> w2["ボタン"]
    w1 --> w3["コンテキストメニュー"]
    w1 --> w4["ショートカット"]
    w2 --> w5["どの入力方式でも到達できる"]
    w3 --> w5
    w4 --> w5
    w1 -.-> w6["hover依存はタッチで詰まる"]

図18: 重要なコマンドは複数のUI面に置き、hover依存を避ける。

7. Windows アプリで最低限外したくない UX 項目

ここからは、用途を問わず最低限押さえたいものをまとめます。

7.1 キーボードで完結できるか

Windows デスクトップでは、キーボードは「あると便利」程度のものではなく、本筋の入力手段です。

Microsoft のキーボードアクセシビリティ ガイドでも、キーボード対応は、視覚や運動能力に制約のあるユーザーのためだけでなく、効率目的でキーボードを選ぶユーザー にとっても重要だとされています。³

最低限見たいのは、この 5 点です。

• Tab 順は自然か
• フォーカス可視化はあるか
• Enter / Space で押せるか
• ショートカットはあるか
• 右クリック相当の操作をキーボードでも呼べるか

地味ですが、ここが崩れると BtoB の UX はかなり痛みます。

7.2 文字拡大、コントラストテーマ、アクセシビリティ

Windows アプリでは、文字サイズやコントラストにちゃんと追随するだけで UX がずいぶん安定します。

Microsoft のガイドでは、可視テキストのコントラスト比は少なくとも 4.5:1 が推奨され、文字が拡大されたときには コントロールやコンテナも合わせてリサイズ・再配置される ことが求められています。⁵⁶

さらにコントラストテーマでは、

• 色をハードコードしない
• SystemColor / Brush リソースを使う
• 4 種類のコントラストテーマで試す

ことが推奨されています。⁷

ここで崩れやすいのは、

• 固定幅前提のラベル
• ピクセル固定のボタン高さ
• 色だけで意味を伝える設計
• カスタム描画でテーマ追随しない UI

です。

このへんは「アクセシビリティ対応」というより、長く壊れない Windows UI を作る基礎工事 と考えたほうがしっくりきます。

flowchart TB
    accTitle: 拡大とテーマに耐える基礎工事
    accDescr: 固定幅前提のラベルやピクセル固定の高さ、色だけの意味づけ、テーマ追随しないカスタム描画は崩れやすく、色をハードコードせずリソースを使い、コントラストテーマで試すことが長く壊れないWindows UIの基礎工事であることを示す図。
    y1["固定幅ラベル・ピクセル固定の高さ"] --> y3["拡大やテーマ切替で崩れる"]
    y2["色だけの意味づけ・独自描画"] --> y3
    y3 --> y4["色をハードコードせずリソースを使う"]
    y4 --> y5["4種類のコントラストテーマで試す"]
    y5 -.-> y6["長く壊れないUIの基礎工事"]

図19: 文字拡大とコントラストテーマへの追随は、UIの基礎工事にあたる。

7.3 ダイアログを乱用しない

ダイアログは便利ですが、使いすぎると作業の敵になります。

Windows のダイアログ ガイドでは、ダイアログは 通知、承認、追加情報の入力 が必要なときの モーダルな UI とされ、少なくとも 1 つは 安全で非破壊的な操作（Close, Cancel など）を置くことが推奨されています。さらに、ボタン文言は 具体的な応答 にするほうがよいとされています。¹⁰

大事なのは、何でもダイアログにしない ことです。

特に、

• フィールド単位の入力エラー
• その場で直せる形式エラー
• 一時的な注意

は、できるだけインライン表示に寄せたほうが自然です。¹⁰

7.4 重要なコマンドは複数の経路を持つ

Windows のコマンド設計では、重要コマンドは さまざまな入力方式や UI 面から呼べること が重視されています。¹²¹³

これは実務でもよく効きます。

たとえば「削除」なら、

• ツールバー
• コンテキストメニュー
• Delete キー
• 必要ならスワイプ

のように複数ルートがあると、使い勝手が安定します。

逆に、

• hover したときだけ右端に出る
• 右クリックでしか出ない
• キーボードでは一生たどり着けない

のような設計は、入力方式が変わると急に弱くなります。

7.5 テストツールで確認する

アクセシビリティは、頭の中で「たぶん大丈夫」と考えるより、ツールで見たほうが速いです。

Microsoft のアクセシビリティ テスト ガイドでは、Accessibility Insights for Windows を使った Live Inspect、FastPass、Troubleshooting が紹介されており、さらに SDK の Inspect で UI Automation の属性やナビゲーション構造を確認できます。¹⁷

最低限でも、

• Accessibility Insights でざっと走査
• Inspect で主要要素の名前、ロール、パターン確認
• キーボードだけで主要フローを通す
• テキスト拡大とコントラストテーマを試す

くらいはやっておくと、後戻りが減ります。

flowchart TB
    accTitle: アクセシビリティの確認手順
    accDescr: Accessibility Insightsでざっと走査し、Inspectで主要要素の名前・ロール・パターンを確かめ、キーボードだけで主要フローを通し、テキスト拡大とコントラストテーマを試すという確認の流れを示す図。
    z1["Accessibility Insightsで走査"] --> z2["Inspectで名前・ロール・パターン確認"]
    z2 --> z3["キーボードだけで主要フローを通す"]
    z3 --> z4["拡大とコントラストテーマを試す"]
    z4 -.-> z5["頭の中の「たぶん大丈夫」より速い"]

図20: アクセシビリティはツールで走査してから、手で主要フローを確かめる。

7.6 回復性を入れる

これは Microsoft の 1 行チェックリストというより、Windows デスクトップの実務でかなり効く話です。

UX は「気持ちよく押せるボタン」だけではなく、事故っても戻れること で決まります。

たとえば、

• Undo / Redo
• 自動保存
• 編集中状態の保持
• フィルタ / ソート / 列幅の復元
• 中断と再開
• 長い処理の進捗とキャンセル

は、見た目よりずっと UX に効きます。

特に BtoB や専門家向けでは、再操作のストレス がそのまま UX の悪さになります。

flowchart TB
    accTitle: 回復性がUXを決める
    accDescr: UXは気持ちよく押せるボタンだけでなく事故っても戻れることで決まり、UndoやRedo、自動保存、状態の復元、長い処理の進捗とキャンセルが再操作のストレスを減らすことを示す図。
    ba1["Undo / Redo・自動保存"] --> ba4["事故っても戻れる"]
    ba2["編集中状態・表示の復元"] --> ba4
    ba3["進捗表示とキャンセル"] --> ba4
    ba4 -.-> ba5["再操作のストレスがそのままUXの悪さになる"]

図21: UXは押しやすさだけでなく、事故っても戻れる回復性で決まる。

8. よくある設計ミス

8.1 BtoB だから高密度にすればよい、と思い込む

これは半分だけ正しいです。

毎日使う熟練者向けなら高密度が効くことはあります。 でも現場端末、受付端末、装置 UI では、むしろ密度は敵です。

BtoB というラベルではなく、熟練度、入力方式、利用環境 を見たほうが外しにくいです。

8.2 BtoC だから機能を隠しすぎる

個人向けでも、熟練者向けツールなら効率が最優先です。

何でも「簡単に見せる」方向へ振ると、

• 高頻度操作が遠い
• いちいちメニューを掘る
• 画面を切り替え続ける

という、静かな地獄が始まります。

flowchart TB
    accTitle: ラベル思い込みの2つの罠
    accDescr: BtoBだから高密度にすればよいという思い込みは現場端末で外れ、BtoCだから機能を隠しすぎると熟練者の高頻度操作が遠くなる、という2つの罠を示す図。
    ca1["BtoBだから高密度"] --> ca2["現場端末では密度は敵"]
    ca3["BtoCだから隠す"] --> ca4["熟練者は高頻度操作が遠くなる"]
    ca2 --> ca5["熟練度・入力方式・利用環境で見る"]
    ca4 --> ca5

図22: 「BtoBは高密度」「BtoCは簡単に」という思い込みが、逆方向に外れる。

8.3 hover 前提の操作を作る

タッチには hover がありません。 さらに、ポインタでしか出ない UI は支援技術との相性も悪くなりやすいです。⁴¹²

重要操作は、常時見えるか、少なくとも複数の経路を持たせるほうが安全です。

Before: hover した行だけ、右端に操作が現れる
  伝票 1001   2026-03-18   未処理                        <- 何も見えない
  伝票 1002   2026-03-18   未処理        [ 編集 ][ 削除 ] <- マウスを乗せた行だけ

After: 常に見える + 経路を増やす
  伝票 1001   2026-03-18   未処理        [ 編集 ][ 削除 ]
  伝票 1002   2026-03-18   未処理        [ 編集 ][ 削除 ]
     右クリック  -> 編集 / 削除
     キーボード  -> Enter で編集、Delete で削除

8.4 色だけで状態を伝える

監視画面で特に多いですが、赤 / 黄 / 緑だけで意味を伝えるのは危ないです。

文字、アイコン、時刻、件数、説明を合わせたほうが、見逃しも誤認も減ります。¹¹

8.5 検証エラーを全部ダイアログにする

事務入力系でよくあります。 入力するたびにダイアログが出ると、作業リズムが完全に壊れます。

文脈に閉じたエラーは、画面内でその場に出すほうが自然です。¹⁰

Before: フィールドごとにモーダル
  郵便番号  [ 1234        ]        +------------------------------+
  住所      [             ]        | 郵便番号の形式が正しくありません
                                   |                       [ OK ]
                                   +------------------------------

After: その場にインライン
  郵便番号  [ 1234        ]
            ! 7 桁の数字で入力してください。例 1234567
  住所      [             ]

8.6 固定サイズのレイアウトで作る

100% 表示の開発環境ではきれいでも、

• 文字拡大
• 高 DPI
• コントラストテーマ
• ローカライズ

であっさり崩れます。⁶⁷

Before: 固定幅ラベル + 固定高ボタン。テキストを拡大すると
  [ 出荷予定... ][ 2026-03-1  ]      <- ラベルが切れ、値もはみ出す
  [ 登 ][ 取 ]                        <- ボタンの文字が上下で切れる

After: 内容にあわせて伸びるレイアウト
  出荷予定日
  [ 2026-03-18              ]
  [ 登録 ]   [ 取消 ]                 <- 高さは内容 + 余白で決める

見た目の完成度を上げるほど、固定前提は毒になりやすいです。

8.7 カスタムコントロールを作りすぎる

Windows の標準コントロールは、見た目以上に多くの振る舞いを持っています。

• フォーカス
• キーボード
• テーマ追随
• UI Automation
• 支援技術との接続

まで含めて面倒を見てくれるので、理由なく全部自作すると、UX とアクセシビリティの負債が増えます。⁸³

9. 着手前に決める 8 問

最後に、設計レビューの最初に置くと便利な 8 問を置きます。

この 8 問を先に答えておくと、

• ナビゲーションが浅いほうがよいのか
• 一覧 + 明細がよいのか
• ショートカットを厚くするべきか
• ダイアログをどこで使うべきか
• カスタマイズをどこまで許すか

が自然に決まっていきます。

flowchart TB
    accTitle: 8問から決まっていくもの
    accDescr: 着手前の8問に先に答えておくと、ナビゲーションの深さ、一覧と明細の構成、ショートカットの厚さ、ダイアログの使いどころ、カスタマイズの範囲が自然に決まっていくことを示す図。
    da1["着手前の8問に答える"] --> da2["ナビの深さと一覧・明細の構成"]
    da1 --> da3["ショートカットの厚さ"]
    da1 --> da4["ダイアログとカスタマイズの範囲"]
    da2 --> da5["自然に決まっていく"]
    da3 --> da5
    da4 --> da5

図23: 8問に先に答えると、設計上の主要な選択が自然に決まる。

10. まとめ

Windows アプリの UX 設計で大事なのは、 「きれいか」より先に「その人が、その場所で、その入力方式で、止まらず使えるか」 を決めることです。

flowchart TB
    accTitle: きれいさより先に決めること
    accDescr: UX設計で大事なのは、きれいかより先に、その人が、その場所で、その入力方式で、止まらず使えるかを決めることであり、UXは装飾ではなく操作の契約であることを示す図。
    ea1["その人が"] --> ea2["その場所で"]
    ea2 --> ea3["その入力方式で"]
    ea3 --> ea4["止まらず使えるか"]
    ea4 -.-> ea5["UXは装飾ではなく操作の契約"]

図24: 「きれいか」より先に、人・場所・入力方式で止まらないかを決める。

ざっくり整理すると、こうです。

• BtoC は初回理解と安心感を優先
• BtoB 事務系 は継続効率とキーボード対応を優先
• BtoB 監視 は見逃し防止と安全操作を優先
• BtoB 現場端末 は大きな操作対象と短い導線を優先
• 専門家向けツール は密度、ショートカット、カスタマイズを優先
• 常駐ツール は邪魔しないことを優先

そして、用途を問わず共通で効くのは以下の 6 つです。

1. 標準コントロールを素直に使う
2. キーボードで主要操作が完結する
3. タッチや支援技術で詰まらない
4. 文字拡大やコントラストテーマで崩れない
5. 重要コマンドに複数の経路を用意する
6. 事故っても戻れる

UX は装飾ではなく、操作の契約 です。 その契約が利用者、環境、入力方式と噛み合っているほど、Windows アプリは地味に、でも強く使いやすくなります。

11. 参考資料

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

BtoBの業務アプリは情報を詰め込んだ高密度UIにすべきですか？

半分だけ正しいです。毎日使う熟練者向けの事務入力系では、高密度な一覧性やキーボード完結が継続効率に効きます。しかし工場・倉庫・受付などの現場端末や装置UIでは密度はむしろ敵で、大きな操作対象、短い導線、明快さを優先すべきです。BtoBというラベルではなく、熟練度、入力方式、利用環境を見たほうが外しにくいです。逆にBtoCでも画像編集や投資分析のような上級者向けツールでは、簡単さより情報密度・ショートカット・カスタマイズ性が優先になります。

WindowsアプリのUX設計で最初に決めるべきことは何ですか？

BtoCかBtoBかだけでは足りず、5つの問いを先に言語化します。誰が使うか（初心者・熟練者・混在）、どこで使うか（机上・現場・屋外・受付）、何で操作するか（キーボード・マウス・タッチ・スキャナ・支援技術）、どれくらい使うか（初回中心・毎日・1日中）、ミスしたときのコストは何か（軽い・重い・危険・監査対象）です。この5つが見えると、UIの密度、ナビゲーション、ショートカット、確認ダイアログ、カスタマイズ性の優先順位が決めやすくなります。

ナビゲーションのパターンはどう選べばよいですか？

すべてのアプリに効く1つのナビゲーションデザインはなく、一貫性・シンプルさ・明快さが原則です。使い分けの目安としては、上部ナビはナビゲーション項目をすべて画面に表示したいとき、左側ナビは最上位項目が多いとき、リスト/詳細は項目を頻繁に切り替えながら詳細の表示や更新を行うデータ入力系、タブは複数のドキュメントを動的に開閉したいとき、パンくずは深い階層で現在地を見失いやすいときに向きます。ナビゲーションは見た目の好みではなく、情報構造と作業構造の反映です。

確認ダイアログはどこまで出すべきですか？

何でもダイアログにしないことが大事です。フィールド単位の入力エラーやその場で直せる形式エラーは、ダイアログではなく画面内のインライン表示に寄せるほうが自然です。本当に確認したいのは、止める・削除する・遮断する・書き換えるといった不可逆寄りの操作です。ダイアログを出すなら、何が起きるかを最初の1行で明確に書き、ボタン文言はOK/Yesではなく削除・停止のように具体的にし、安全で非破壊的なボタンを必ず置く、の3つは最低限守るべきです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。