Windows App UX Design - Priorities by Usage Environment

When thinking about UX for a Windows app, starting from “does it look modern” or “is the whitespace pretty” gets the order slightly wrong.

On the Windows desktop, UX is not settled by appearance alone.

• How far can the work be completed with the keyboard
• Whether it assumes a mouse or assumes touch
• Whether it is used for hours or only for a few minutes now and then
• Whether it is monitoring, data entry, or a shop-floor terminal
• What impact or loss a mis-operation produces
• Whether it still works cleanly under text scaling, contrast themes, and assistive technologies such as screen readers

All of that together is UX.

flowchart TB
    accTitle: UX is not settled by appearance alone
    accDescr: Diagram showing that UX is all of it taken together - how far the work can be completed with the keyboard, mouse or touch, usage time and purpose, the impact and loss of a mis-operation, and whether the app still works under assistive technologies such as screen readers.
    a1["Input method and how far the keyboard completes the work"] --> a4["All of it together is UX"]
    a2["Usage time and purpose"] --> a4
    a3["Cost of mistakes and assistive technology"] --> a4
    a4 -.-> a5["Starting from does it look modern gets the order wrong"]

Figure 1: UX on the Windows desktop is settled by a bundle of usage-context factors before appearance.

What makes it trickier is that B2C and B2B have different centers of gravity. But concluding from that “B2B means cram the information in” or “B2C means keep it soft and light” will trip you up somewhere.

For example, even within B2B:

• Office applications such as accounting entry or order management
• Shop-floor terminals in factories, warehouses, reception areas, and inspection equipment
• Operations screens for 24-hour monitoring and maintenance response

each have quite different conditions for good UX.

Conversely, even within B2C:

• A small personal utility
• Expert-leaning tools such as image editing, music production, or investment analysis

differ completely in UI density and in how much shortcut operation is expected.

flowchart TB
    accTitle: The same label, different conditions
    accDescr: Diagram showing that within the same B2B label, office applications, shop-floor terminals, and operations screens have quite different conditions for good UX, and that within B2C, small utilities and expert-leaning tools differ in both density and the demand for shortcut operation.
    b0["The same B2B label"] --> b1["Office apps, shop-floor terminals, operations screens"]
    b1 --> b2["Conditions for good UX differ considerably"]
    c0["The same B2C label"] --> c1["Utilities and expert tools"]
    c1 --> c2["Density and demand for shortcuts differ too"]

Figure 2: Even inside the same B2C / B2B label, the conditions for good UX split apart.

Microsoft’s design guidance for Windows likewise emphasizes that a Windows app should be intuitive, accessible, and consistent across input methods and form factors.¹²

This article organizes Windows app UX as a decision table by use case. The goal is to make it easy, during design review or the early stages of screen design, to pin down what a given app should prioritize.

Intended Readers and Assumptions

Terms Used in This Article

1. The Conclusion First

Put bluntly up front, it comes to this.

• For B2C, prioritize first-time comprehensibility, reassurance, few settings, and straightforward paths
• For B2B, prioritize sustained efficiency, mis-operation prevention, keyboard support, and stable layout
• However, on a B2B shop-floor terminal, clarity, large targets, and short paths matter more than density
• However, in a B2C expert tool, information density, shortcuts, and customizability matter more than simplicity
• In Windows apps, the design holds up better later if UX is considered all the way out to keyboard, mouse, touch, text scaling, contrast themes, and assistive technologies¹³⁴⁵⁶⁷

What really has to be decided first is not only B2C versus B2B. These five are what to put into words first.

1. Who uses it (beginners, experts, a mix)
2. Where it is used (a desk, a meeting room, the shop floor, a factory, a reception desk, outdoors)
3. What it is operated with (keyboard, mouse, touch, pen, barcode, assistive technology)
4. How much it is used (mostly first-time, occasionally, daily, all day)
5. What a mistake costs (minor, serious, dangerous, subject to audit)

Once those five are visible, the priorities for UI density, navigation, shortcuts, confirmation dialogs, and customizability become far easier to set.

flowchart TB
    accTitle: Five questions to put into words first
    accDescr: Diagram showing that once who uses it, where it is used, what it is operated with, how much it is used, and what a mistake costs are visible, the priorities for UI density, navigation, confirmation dialogs and the rest become easy to set.
    q1["1. Who uses it"] --> q2["2. Where it is used"]
    q2 --> q3["3. What it is operated with"]
    q3 --> q4["4. How much it is used"]
    q4 --> q5["5. What a mistake costs"]
    q5 --> q6["Priorities for density, navigation and dialogs get settled"]

Figure 3: Putting five questions into words settles the priorities, ahead of B2C versus B2B.

Knowledge map for this article

This article frames UX design for Windows apps as something to judge not only from the BtoC/BtoB classification but from the usage context of who operates the app, where, on what device, how often they use it, and what a mistake costs. It holds that a top navigation bar and easy first-time comprehension suit consumer-facing utilities, that list/detail layouts and keyboard operability suit back-office BtoB apps, that left-side navigation, status indication that does not rely on color alone, commands reachable through more than one path, and confirmation dialogs for irreversible operations suit monitoring and operations apps, that touch targets large enough to hit and a design that does not depend on hover suit shop-floor terminals, and that tabs with thorough keyboard support suit tools for experts. It also covers numeric criteria such as a 7.5 mm square touch target and a contrast ratio of 4.5:1, along with the importance of layouts that follow text scaling and contrast themes.

flowchart LR
    accTitle: Decision axes for Windows app UX design
    accDescr: Diagram showing how the usage context of who operates the app, where, and on what device sets the UX priorities such as the navigation pattern, touch target size, keyboard operability, and the use of dialogs
    tob_field_device_ui["B2B Field Terminal and Kiosk UI"]
    tob_back_office_app["B2B Back-Office Data Entry App"]
    top_navigation["Top Navigation"]
    toc_utility_app["B2C Utility and Personal App"]
    left_navigation["Left Navigation"]
    tob_monitoring_app["B2B Monitoring and Operations App"]
    list_detail_navigation["List/Detail Navigation"]
    tab_navigation["Tab Navigation"]
    expert_tool_ui["Expert Editing and Analysis Tools"]
    touch_target_size_guideline["Minimum Touch Target Size Guideline"]
    color_only_state_indication["Color-only state indication"]
    hover_only_interaction["Hover-Only Interaction"]
    multi_entry_commanding["Multiple Entry Points per Command"]
    inline_validation_error["Inline Validation Error Display"]
    confirmation_dialog_for_irreversible_action["Confirmation dialog for irreversible actions"]
    keyboard_accessibility["Keyboard Accessibility"]
    contrast_theme_support["Contrast theme support"]
    fixed_size_layout["Fixed-Size Layout"]
    text_contrast_ratio_guideline["Text Contrast Ratio Guideline"]
    content_spacing_guideline["Content spacing guideline (8/12/16 epx)"]
    tray_resident_app["Tray-Resident Background App"]
    custom_control_overuse["Overusing custom controls"]
    top_navigation -->|"recommended for"| toc_utility_app
    left_navigation -->|"recommended for"| tob_monitoring_app
    left_navigation -->|"recommended for"| tob_back_office_app
    list_detail_navigation -->|"recommended for"| tob_back_office_app
    tab_navigation -->|"recommended for"| expert_tool_ui
    touch_target_size_guideline -->|"recommended for"| tob_field_device_ui
    color_only_state_indication -->|"not recommended for"| tob_monitoring_app
    hover_only_interaction -->|"not recommended for"| tob_field_device_ui
    hover_only_interaction -->|"not recommended for"| tob_monitoring_app
    multi_entry_commanding -->|"recommended for"| tob_monitoring_app
    multi_entry_commanding -->|"recommended for"| expert_tool_ui
    inline_validation_error -->|"recommended for"| tob_back_office_app
    confirmation_dialog_for_irreversible_action -->|"recommended for"| tob_monitoring_app
    keyboard_accessibility -->|"recommended for"| tob_back_office_app
    keyboard_accessibility -->|"recommended for"| expert_tool_ui
    keyboard_accessibility -->|"recommended for"| hover_only_interaction
    contrast_theme_support -->|"recommended for"| fixed_size_layout
    contrast_theme_support -.->|"requires"| text_contrast_ratio_guideline
    content_spacing_guideline -->|"recommended for"| fixed_size_layout
    confirmation_dialog_for_irreversible_action -->|"not recommended for"| tray_resident_app
    expert_tool_ui -.->|"incompatible with"| toc_utility_app
    contrast_theme_support -->|"recommended for"| custom_control_overuse
    keyboard_accessibility -->|"recommended for"| custom_control_overuse

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (23 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. B2C / B2B Is the Entry Point, Not the Answer

Splitting by B2C and B2B is convenient as a first entry point. But what most strongly determines the right UX is the type of use, not the type of buyer.

Viewed roughly along two axes, it looks like this.

In other words,

• B2C = a light UI at all times
• B2B = a dense UI at all times

does not hold.

Windows design guidance also emphasizes being usable consistently across devices, input types, and form factors, and from an accessibility standpoint it stresses considering not only disability but also environmental constraints such as bright sunlight, shared spaces, quiet places, and noisy places.¹²

flowchart TB
    accTitle: Type of use beats type of buyer
    accDescr: Diagram showing that the equations B2C means a light UI at all times and B2B means a dense UI at all times do not hold, and that what most strongly determines the right UX is the type of use rather than the type of buyer.
    e1["B2C = a light UI at all times"] --> e3["This equation does not hold"]
    e2["B2B = a dense UI at all times"] --> e3
    e3 --> e4["What determines the answer is the type of use"]
    e4 -.-> e5["Include environmental constraints in the thinking"]

Figure 4: What determines the right UX is the type of use rather than the type of buyer.

So after looking at B2C versus B2B, it helps to cut further along these axes.

Cutting along these first removes a great deal of the “vaguely modern” and “vaguely enterprise-looking” discussion in meetings.

3. The Decision Table by Use Case, on One Page

Here is the table that is most usable in practice.

This table alone already points in roughly the right direction. Two points matter most: even in B2B, a dense UI is not the right answer for shop-floor terminals, and even in B2C, efficiency beats lightness in expert tools.

flowchart TB
    accTitle: Two rows where label and answer invert
    accDescr: Diagram showing two examples where the answer suggested by the label inverts - in B2B a dense UI is not the right answer for shop-floor terminals, and in B2C efficiency beats lightness for expert tools.
    f1["B2B shop-floor terminal"] --> f2["A dense UI is not the right answer"]
    f3["B2C expert tool"] --> f4["Efficiency beats lightness"]
    f2 --> f5["Decide by use case, not by label"]
    f4 --> f5

Figure 5: The two rows of the decision table where label and answer invert.

If you are in a hurry, stopping at this chapter is fine. Chapter 4 expands each row of the table into why it works that way and what to place concretely. It does not repeat conclusions the table already states, so you can read only the judgment material that would not fit into the table.

4. Design Policy by Use Case

4.1 B2C Utilities / Personal Apps

In a small B2C Windows app, usable the moment it launches is by far the strongest requirement.

The points worth the most attention are these.

• The first screen makes it clear what the app does
• The primary operations are narrowed to one or two
• The empty state is not unhelpful
• Dangerous operations can be undone
• Not every setting is shown from the start

The common failure here is laying out everything that is technically possible. But in a lightweight B2C tool, being usable right away is often worth more than having many features.

Windows navigation guidance also states that there is no single right answer for every app, and puts consistency, simplicity, and clarity first. Using standard controls in standard places makes an app easier to predict.⁸

So for B2C,

• A single screen if the app is small
• Top navigation if the sections are peers
• Settings revealed progressively
• Primary actions bright, everything else quiet

is often organization enough.

flowchart TB
    accTitle: How to organize a B2C app
    accDescr: Diagram showing that for B2C apps, organizing around usable the moment it launches - a single screen when small, top navigation when sections are peers, settings revealed progressively, and primary actions bright with the rest quiet - is often enough.
    g1["Usable the moment it launches"] --> g2["A single screen if small"]
    g1 --> g3["Top navigation if sections are peers"]
    g1 --> g4["Reveal settings progressively"]
    g4 -.-> g5["Primary actions bright, the rest quiet"]

Figure 6: A lightweight B2C tool is organized around usable right away rather than feature-rich.

That said, once a B2C app becomes an expert tool for photo editing, video editing, music composition, investment analysis, or development support, the story changes. In that case, looking at proficiency and time spent in the app gets closer to the right answer than the B2C label does.

4.2 B2B Office Entry / Back Office

What matters in an office-oriented B2B app is not visual lightness but work that never stalls.

Users who work in it daily get used to the UI within a few days. What pays off after that is this kind of thing.

• How far the keyboard alone can take you
• How easy it is to move back and forth between list and detail
• Whether important columns and states are visible at a glance
• Whether filters and sort order are preserved
• Whether errors can be fixed on the spot

Microsoft’s keyboard accessibility guidance likewise treats reaching every feature by keyboard as important, and recommends implementing tab order, focus, activation via Enter and Space, and shortcuts.³

Access keys also help beyond accessibility: they improve efficiency for power users who prefer the keyboard. Supporting access keys where appropriate, including in custom controls, is recommended.⁹

For office entry, list/detail is a solid navigation choice. The Windows navigation guide states that list/detail suits switching between items frequently while viewing or updating details, and fits cases such as an email inbox, a contact list, or data entry.⁸

So a straightforward structure looks like this.

• Functional categories on the left
• The list in the center
• Detail and editing on the right or below
• Search, filters, and primary commands along the top
• Shortcuts for frequently used operations

flowchart TB
    accTitle: A straightforward structure for office entry
    accDescr: Diagram showing a straightforward office-entry structure with search, filters and primary commands on top, functional categories on the left, the list in the center, detail and editing on the right or below, and shortcuts for frequently used operations.
    h1["Top: search, filters, primary commands"] --> h2["Left: functional categories"]
    h2 --> h3["Center: the list"]
    h3 --> h4["Right or below: detail and editing"]
    h4 -.-> h5["Shortcuts for frequently used operations"]

Figure 7: A straightforward office-entry screen structure built around list/detail.

The patterns to avoid are worth listing too.

• A dialog for every single operation
• Too few columns, so the list shows too little
• Primary operations available only deep inside a right-click menu
• Trying to convey meaning with icons alone
• Chaotic tab order where neither Enter nor Space does anything

For input errors as well, validation errors tied to a field belong in the screen rather than in a dialog. The Windows dialog guide also recommends not using a dialog for validation errors bound to context, such as a password field, and using inline display instead.¹⁰

4.3 B2B Monitoring / Operations

For monitoring and operations screens, not missing things, not making mistakes, not stalling comes before “easy to use.”

The priorities here usually work out as follows.

• Whether something is wrong is visible at a glance
• The severity of the anomaly is clear
• Not just the current value, but change over time, can be followed
• The path to a dangerous operation is not too easy
• Logs, history, and root-cause investigation are one hop away

On this kind of screen, state representation is the center of the UX. State is safer when expressed with several elements at once: color plus text plus icon plus timestamp. Conveying state by color alone invites missed and misread signals, and it is weak from an accessibility standpoint as well.¹¹

flowchart TB
    accTitle: Express state with several elements
    accDescr: Diagram showing that state representation is the center of UX on monitoring and operations screens, and that because color alone invites missed and misread signals, expressing state with color, text, icon and timestamp together is safer.
    i1["Express state with color alone"] --> i2["Missed and misread signals become likely"]
    i2 -.->|"instead"| i3["Express it with color plus text plus icon plus timestamp"]
    i3 --> i4["Fewer misses, fewer misreads, safer"]

Figure 8: State on a monitoring screen is expressed as a combination of elements, not color alone.

For navigation, left navigation when there are many monitored objects, drill-down for digging into an individual object, and logs or time series for the detail is an easy structure to work with. The Windows navigation guide likewise says left navigation suits cases with many top-level items and structures where page switching is not constant.⁸

On the operations side, putting a command in only one place is also risky. The Windows commanding guide recommends making commands available from multiple surfaces such as buttons, context menus, shortcuts, and gestures, and including all related commands in a context menu or CommandBarFlyout. Relying on actions that appear only on hover makes them unusable on touch devices and with assistive technologies.¹²¹³

Confirmation dialogs for dangerous operations matter here too. But “confirm everything just in case” backfires. What genuinely deserves confirmation are irreversible-leaning operations: stopping, deleting, switching over, disconnecting, overwriting. If you do show a dialog,

• State clearly in the first line what will happen
• Make the button label specific, such as Delete / Stop / Disconnect rather than OK / Yes
• Always include a button on the safe side

are three minimums worth keeping.¹⁰

flowchart TB
    accTitle: Three principles for confirmation dialogs
    accDescr: Diagram showing that what genuinely deserves confirmation are irreversible-leaning operations such as stopping, deleting or disconnecting, and that a dialog should state what will happen in its first line, use specific button labels, and always include a button on the safe side.
    j1["Confirm only irreversible-leaning operations"] --> j2["State what will happen in the first line"]
    j1 --> j3["Make button labels specific"]
    j1 --> j4["Always include a button on the safe side"]
    j2 -.-> j5["Confirming everything just in case backfires"]

Figure 9: Confirmation dialogs are limited to irreversible operations and keep three minimums.

4.4 B2B Shop-Floor Terminals / Equipment UI / Kiosks

Shop-floor terminals are a rather different species within Windows app UX.

• Nobody is sitting down
• Gloves may be involved
• Only one hand may be free
• Nobody studies the screen carefully
• There is time pressure
• It is used in bright areas or noisy places

These conditions are entirely normal.

Microsoft’s accessibility guidance also stresses that a good Windows app accounts for environmental constraints beyond disability, including bright sunlight, shared spaces, noise, silence, and situations such as cooking.²

Touch design also differs in that:

• Touch has no hover
• Fingers and hands occlude the UI
• Parts of the screen are hard to reach given hand posture
• Visual feedback matters

are all in play.⁴

flowchart TB
    accTitle: Four differences in touch design
    accDescr: Diagram showing the design differences of touch - there is no hover, fingers and hands occlude the UI, parts of the screen are hard to press given hand posture, and visual feedback matters.
    k1["Touch interaction"] --> k2["There is no hover"]
    k1 --> k3["Fingers and hands occlude the UI"]
    k1 --> k4["Some places are hard to reach given posture"]
    k4 -.-> k5["Visual feedback becomes important"]

Figure 10: Touch has different premises for hover and occlusion, which makes feedback the crux.

So shop-floor terminals generally lean this way.

• Buttons and list items large enough
• Close to one purpose per screen
• Clear response after each action
• Flows broken into stages
• Input leaning toward selection, scanning, and fixed forms rather than free text
• State shown clearly at the top or center of the screen

Conversely, what to avoid is:

• Small text
• Small hit areas
• Dependence on hover-only tooltips
• Deep hierarchies
• Huge amounts of information on one screen
• Long free-text input

The crude assumption that B2B means higher density is easiest to get wrong precisely in this area. This is, if anything, the part of business software where clarity takes priority above all.

flowchart TB
    accTitle: Shop-floor terminals prioritize clarity
    accDescr: Diagram showing that shop-floor terminals move toward one purpose per screen, input leaning to selection, scanning and fixed forms rather than free text, and a clear response after each action, making them the part of business software where clarity takes priority above all.
    l1["Shop-floor terminal and equipment UI"] --> l2["Move toward one purpose per screen"]
    l1 --> l3["Lean input toward selection, scanning and fixed forms"]
    l1 --> l4["Show a clear response after each action"]
    l2 --> l5["The part of business software where clarity matters most"]
    l3 --> l5
    l4 --> l5

Figure 11: Shop-floor terminals lean toward clarity, large targets, and short paths rather than density.

4.5 Expert Editing / Analysis Tools

In expert tools, “please make it easier to understand” sometimes loses to “please do not interrupt me.”

For example:

• CAD
• Waveform analysis
• Video editing
• Image processing
• Music production
• Development support
• Data analysis
• Audit and diagnostic tools

This kind of app benefits from:

• Information density
• Multiple panes
• Tabs
• Context menus
• Shortcuts
• Saved layouts
• Customizable columns and displayed fields
• Undo / Redo
• Restoring work state

The Windows navigation guide notes that tabs suit cases where you want to open, close, and reorder multiple pages or documents.⁸ Windows commanding design also recommends sharing commands across several UI surfaces so that the same operation is reachable regardless of input method.¹²

The common trap with this kind of tool is trying to be kind to beginners by hiding everything in deep menus. But experts perform the same operation hundreds of times a day. For them, still not being worn out after 100 hours matters more than gentleness in the first five minutes.

So for expert-facing tools,

• Keep high-frequency operations close
• Put supporting features a little further back
• Organize advanced features rather than removing them
• Save the display layout
• Make keyboard support thick

tends to be the design that works.

flowchart TB
    accTitle: How to place features for experts
    accDescr: Diagram showing that because experts perform the same operation hundreds of times a day, not being worn out after 100 hours matters more than gentleness in the first five minutes, so high-frequency operations go close, supporting features a little further back, and advanced features are organized rather than removed.
    n1["Experts repeat the same operation hundreds of times a day"] --> n2["Keep high-frequency operations close"]
    n1 --> n3["Put supporting features a little further back"]
    n1 --> n4["Organize advanced features rather than remove them"]
    n2 -.-> n5["Not the first five minutes but hour 100 without fatigue"]

Figure 12: Expert tools place features at a distance matched to how often they are used.

4.6 Resident Tools / Tray Apps

For resident apps, not making their presence felt too strongly is itself the UX.

For example, in apps such as:

• Sync status
• Connection status
• Backup
• Audio / camera / device switching
• VPN / agent / launcher
• Notification hub

the main window is often not where users actually spend their time.

What to prioritize is:

• Reachable immediately from the tray or a small menu
• Current state is visible
• Notify only when necessary
• Go straight from the notification to the needed action
• The main window does not steal the foreground

What to avoid is:

• Showing a dialog over trivia
• Opening the main window on every launch
• Leaving the state of background work invisible
• So many notifications that all of them get ignored

For this kind of app, whether it stays out of the way swings the UX more than how many features it has.

flowchart TB
    accTitle: For resident tools, staying out of the way is the UX
    accDescr: Diagram showing that resident apps prioritize being reachable immediately from the tray or a small menu, making the current state visible, and notifying only when necessary, and that too many notifications lead to all of them being ignored.
    r1["Reachable immediately from the tray"] --> r4["Staying out of the way is the UX"]
    r2["Current state is visible"] --> r4
    r3["Notify only when necessary"] --> r4
    r4 -.-> r5["Too many notifications and all of them get ignored"]

Figure 13: For resident tools, not making their presence felt too strongly is the UX itself.

5. A Decision Table for Navigation

The Windows navigation guide states that no single navigation design works for every app, and builds on consistency, simplicity, and clarity as principles. Placing standard controls where users expect them also makes the UI predictable.⁸

flowchart TB
    accTitle: Principles of navigation design
    accDescr: Diagram showing that no single navigation design works for every app, and that consistency, simplicity and clarity are the principles, with standard controls placed where users expect them to make the UI predictable.
    s0["There is no single correct pattern"] --> s1["Consistency"]
    s0 --> s2["Simplicity"]
    s0 --> s3["Clarity"]
    s3 -.-> s4["Put standard controls where they are expected"]

Figure 14: Navigation has no single right answer; three principles and standard placement make it predictable.

In practice, cutting along this table makes it easier to think about.

The Windows navigation guide draws these distinctions in particular.⁸

• Top navigation: when you want every navigation item visible on screen
• Left navigation: when there are many top-level items and page switching is not constant
• List / detail: when item switching is frequent and details need to be viewed or updated
• Tabs: when documents or pages are opened and closed dynamically
• Breadcrumbs: when a deep hierarchy needs a clear way back

5.1 Wireframes, Skeleton Only

Words alone make it hard to picture, so here are four representative skeletons. Ignore the details and look only at what goes where.

[ Top navigation ]  when you want every peer-level page visible
+-------------------------------------------------------------
| AppName        Home | Convert | History | Settings
+-------------------------------------------------------------
|
|    Main content
|    Lean toward one purpose per screen
|
+-------------------------------------------------------------


[ Left navigation ]  when there are many top-level items
+-------------------------------------------------------------
| AppName                                 Search [          ]
+-------------------------------------------------------------
| Dashboard    |
| Devices      |    Main content
| Alerts       |
| Jobs         |
| Reports      |
| Settings     |
+-------------------------------------------------------------


[ List / detail ]  switch between items while viewing and updating detail
+-------------------------------------------------------------
| Search [         ]  Filter: Open / All          [New] [Delete]
+-------------------------------------------------------------
| List             |  Detail / edit
|  > Slip 1001     |    Slip number  1001
|    Slip 1002     |    Customer     ...
|    Slip 1003     |    Line items   ...
|    Slip 1004     |
|                  |    [ Save ]   [ Cancel ]
+-------------------------------------------------------------


[ Dashboard + drill-down ]  find the anomaly and dig in
+-------------------------------------------------------------
| Overall   OK 22    Warning 3    Error 1      Updated 0.5 s ago
+-------------------------------------------------------------
| Errors: 1
|   ! Line B inspection unit   No response   48 s ago   [ Detail ]
| Warnings: 3
|   - Line A camera            Stale value   12 s ago   [ Detail ]
|   ...
+-------------------------------------------------------------
              |
              |  press [ Detail ]
              v
+-------------------------------------------------------------
| < Back to list     Line B inspection unit / no response
+-------------------------------------------------------------
| Current value | Time series | Event log | Actions
+-------------------------------------------------------------

Lining up all four makes the selection criteria clear.

• What separates top navigation from left navigation is the number of top-level items. If they all fit across the top, use top navigation; if they do not, use left navigation
• In list/detail, the list on the left carries the design, not the detail on the right. If the list carries too little information, users end up reopening details over and over
• A dashboard puts how many anomalies exist in its first line. Once users dig deeper, always give them a way back

In short, navigation is not a matter of visual taste; it is a reflection of the information structure and the work structure.

flowchart TB
    accTitle: What separates top navigation from left navigation
    accDescr: Diagram showing that what separates top navigation from left navigation is the number of top-level items - top navigation if they all fit across, left navigation if they do not - and that navigation reflects the information structure and the work structure.
    t1{"Do the top-level items all fit across the top"} -->|"they fit"| t2["Top navigation"]
    t1 -->|"they do not fit"| t3["Left navigation"]
    t2 -.-> t4["Navigation reflects information and work structure"]
    t3 -.-> t4

Figure 15: The choice of skeleton follows from the information structure, not from visual taste.

6. A Decision Table for Input Devices and Command Design

A Windows app becomes more flexible and more usable the more input methods it supports. Microsoft’s guidance recommends accounting for as many inputs as possible, including gestures, voice, touch, touchpad, mouse, and keyboard.¹⁴

Also, Windows platform controls absorb a fair amount of the difference between input methods, so using standard controls straightforwardly is the strongest first move.⁴⁸

flowchart TB
    accTitle: Standard controls are the strongest first move
    accDescr: Diagram showing that accounting for as many inputs as possible such as gestures, voice, touch, mouse and keyboard is recommended, and that because platform standard controls absorb much of the difference between input methods, using them straightforwardly is the strongest first move.
    u1["Support for diverse input methods"] --> u2["Standard controls absorb much of it"]
    u2 --> u3["Using standard controls straightforwardly is the strongest first move"]

Figure 16: Letting standard controls absorb diverse input methods is the shortcut.

Turned into a form that is usable in practice, it looks like this.

The keyboard points that matter most are these.³⁹

• Every feature is reachable with the keyboard alone
• Tab order does not diverge much from visual order
• Elements that should respond to Enter / Space actually do
• Important features have shortcuts
• High-frequency operations have access keys or accelerators

Touch has these characteristics.⁴

• There is no hover
• Fingers and hands occlude the UI
• Pressable areas feel narrower than they look
• Visual feedback is required
• UI suited to direct manipulation differs from UI suited to indirect input

6.1 Decide with Numbers, Not with “Big Enough”

What tends to cause friction in design review is stopping at “big enough” and “clear enough”. Where Microsoft’s guidance gives a number, using that number directly as the pass/fail criterion keeps the discussion short.

Once the numbers are fixed, the wording in review changes too. Being able to say “this button is 32 px, so it does not reach the 7.5 mm baseline” instead of “isn’t this button a bit small?” settles the fix-or-not decision on the spot.

flowchart TB
    accTitle: Numbers make review fast
    accDescr: Diagram showing that stopping at big enough or clear enough causes friction in review, and that using the numbers from the guidance directly as pass or fail criteria ends the discussion at whether the criterion is met and settles the fix decision on the spot.
    v1["Stopping at big enough"] --> v2["Friction in review"]
    v2 -.->|"instead"| v3["Use the numbers directly as pass or fail criteria"]
    v3 --> v4["The discussion becomes whether the criterion is met"]
    v4 --> v5["The decision is settled on the spot"]

Figure 17: Making numbers the pass/fail criterion ends the argument about size on the spot.

Note that WinUI standard controls are built to follow these target sizes by default.¹⁵ Put the other way around, only hand-built controls and custom drawing are the risky parts.

For command design, the Windows commanding guide is a good reference. The key point is making a command usable from several UI surfaces.¹²

• It can be pressed from a button
• It is also in the context menu
• It can be invoked with a shortcut
• Swipe or gesture as well, if needed

And including all related commands in the context menu or CommandBarFlyout is recommended. Depending on actions that appear only during hover leaves users stuck on touch-only devices.¹²

flowchart TB
    accTitle: Commands from several surfaces
    accDescr: Diagram showing that a command should be usable from several UI surfaces - pressable from a button, present in the context menu, and invokable by shortcut - and that depending on actions visible only during hover leaves users stuck on touch-only devices.
    w1["The same command"] --> w2["Button"]
    w1 --> w3["Context menu"]
    w1 --> w4["Shortcut"]
    w2 --> w5["Reachable from any input method"]
    w3 --> w5
    w4 --> w5
    w1 -.-> w6["Hover dependence leaves touch users stuck"]

Figure 18: Important commands go on several UI surfaces, avoiding hover dependence.

7. The UX Items You Least Want to Miss in a Windows App

From here on, the minimum items worth covering regardless of use case.

7.1 Can It Be Completed with the Keyboard

On the Windows desktop, the keyboard is not a nice-to-have; it is a primary input method.

Microsoft’s keyboard accessibility guide also states that keyboard support matters not only for users with visual or motor constraints, but for users who choose the keyboard for efficiency.³

The five things to check at minimum are these.

• Is the tab order natural
• Is focus visualized
• Can elements be activated with Enter / Space
• Are there shortcuts
• Can the right-click equivalent be invoked from the keyboard

It looks unglamorous, but when this breaks, B2B UX hurts badly.

7.2 Text Scaling, Contrast Themes, and Accessibility

In a Windows app, simply following text size and contrast properly makes the UX considerably more stable.

Microsoft’s guidance recommends a contrast ratio of at least 4.5:1 for visible text, and requires that controls and containers resize and reflow along with the text when it is scaled up.⁵⁶

For contrast themes, it further recommends:

• Do not hardcode colors
• Use SystemColor / Brush resources
• Test with all four contrast themes

as practice.⁷

What tends to break here is:

• Labels that assume a fixed width
• Button heights fixed in pixels
• Designs that convey meaning by color alone
• Custom-drawn UI that does not follow the theme

This lands better when thought of not as “accessibility work” but as the groundwork for a Windows UI that will not break over time.

flowchart TB
    accTitle: Groundwork that survives scaling and themes
    accDescr: Diagram showing that fixed-width labels, pixel-fixed heights, meaning carried by color alone and custom drawing that ignores the theme all break easily, and that not hardcoding colors, using resources and testing with contrast themes is the groundwork for a Windows UI that lasts.
    y1["Fixed-width labels and pixel-fixed heights"] --> y3["Break under scaling or a theme switch"]
    y2["Meaning by color alone and custom drawing"] --> y3
    y3 --> y4["Use resources instead of hardcoded colors"]
    y4 --> y5["Test with all four contrast themes"]
    y5 -.-> y6["Groundwork for a UI that does not break over time"]

Figure 19: Following text scaling and contrast themes is the groundwork of the UI.

7.3 Do Not Overuse Dialogs

Dialogs are convenient, but overusing them turns them into the enemy of getting work done.

The Windows dialog guide describes a dialog as modal UI for cases that require notification, approval, or additional input, and recommends including at least one safe, nondestructive action such as Close or Cancel. It also states that button labels are better as specific responses.¹⁰

The important part is not turning everything into a dialog.

In particular,

• Per-field input errors
• Format errors that can be fixed on the spot
• Transient notices

sit more naturally inline in the screen wherever possible.¹⁰

7.4 Important Commands Have Multiple Routes

Windows commanding design emphasizes that important commands should be invokable from various input methods and UI surfaces.¹²¹³

This works well in practice too.

For Delete, for instance,

• The toolbar
• The context menu
• The Delete key
• Swipe, if appropriate

having multiple routes keeps the experience stable.

Conversely, designs such as:

• It appears at the right edge only on hover
• It is available only via right-click
• The keyboard can never reach it

suddenly become weak the moment the input method changes.

7.5 Check with Test Tools

For accessibility, looking at it with a tool beats deciding in your head that it is probably fine.

Microsoft’s accessibility testing guide covers Live Inspect, FastPass, and Troubleshooting using Accessibility Insights for Windows, and the SDK’s Inspect tool for checking UI Automation properties and navigation structure.¹⁷

At minimum,

• A quick scan with Accessibility Insights
• Checking name, role, and patterns for key elements with Inspect
• Walking the primary flows with the keyboard alone
• Trying text scaling and contrast themes

is worth doing, and it cuts down on rework.

flowchart TB
    accTitle: Steps for checking accessibility
    accDescr: Diagram showing the checking flow - scan with Accessibility Insights, verify name, role and patterns of key elements with Inspect, walk the primary flows with the keyboard alone, and try text scaling and contrast themes.
    z1["Scan with Accessibility Insights"] --> z2["Check name, role and patterns with Inspect"]
    z2 --> z3["Walk the primary flows with the keyboard alone"]
    z3 --> z4["Try text scaling and contrast themes"]
    z4 -.-> z5["Faster than deciding in your head that it is probably fine"]

Figure 20: Scan accessibility with tools first, then confirm the primary flows by hand.

7.6 Build In Recoverability

This is less a one-line Microsoft checklist item than something that pays off heavily in Windows desktop practice.

UX is not only about buttons that feel good to press; it is settled by being able to get back after something goes wrong.

For example:

• Undo / Redo
• Autosave
• Preserving in-progress edits
• Restoring filters, sort order, and column widths
• Suspending and resuming
• Progress and cancellation for long operations

matter to UX far more than their visual weight suggests.

In B2B and expert tools especially, the stress of redoing work translates directly into bad UX.

flowchart TB
    accTitle: Recoverability determines UX
    accDescr: Diagram showing that UX is settled not only by buttons that feel good to press but by being able to get back after something goes wrong, and that undo and redo, autosave, restored state and progress with cancellation reduce the stress of redoing work.
    ba1["Undo / Redo and autosave"] --> ba4["You can get back after something goes wrong"]
    ba2["In-progress edits and restored views"] --> ba4
    ba3["Progress display and cancellation"] --> ba4
    ba4 -.-> ba5["The stress of redoing work becomes bad UX directly"]

Figure 21: UX is settled not only by ease of pressing but by the recoverability that lets you get back after something goes wrong.

8. Common Design Mistakes

8.1 Assuming B2B Means Higher Density Is Better

This is only half right.

For experienced users working in the app daily, high density does sometimes pay off. But on shop-floor terminals, reception terminals, and equipment UIs, density is the enemy.

You are less likely to get it wrong by looking at proficiency, input method, and usage environment than by looking at the B2B label.

8.2 Assuming B2C Means Hiding Too Much

Even in consumer software, efficiency comes first for an expert tool.

Pushing everything toward “make it look simple” starts a quiet hell:

• High-frequency operations are far away
• Users dig through menus for everything
• Screens keep switching

flowchart TB
    accTitle: Two traps of label-driven assumptions
    accDescr: Diagram showing two traps - the assumption that B2B means higher density fails on shop-floor terminals, and hiding features because it is B2C pushes high-frequency operations away from experts.
    ca1["B2B means high density"] --> ca2["On shop-floor terminals density is the enemy"]
    ca3["B2C means hide it"] --> ca4["High-frequency operations move away from experts"]
    ca2 --> ca5["Look at proficiency, input method and environment"]
    ca4 --> ca5

Figure 22: The assumptions that B2B means dense and B2C means simple both miss in opposite directions.

8.3 Building Hover-Dependent Interactions

Touch has no hover. Beyond that, UI that appears only under a pointer tends to work poorly with assistive technologies.⁴¹²

Important operations are safer when always visible, or at least reachable through multiple routes.

Before: actions appear at the right edge only on the hovered row
  Slip 1001   2026-03-18   Open                          <- nothing is visible
  Slip 1002   2026-03-18   Open        [ Edit ][ Delete ] <- only the row under the mouse

After: always visible + more routes
  Slip 1001   2026-03-18   Open        [ Edit ][ Delete ]
  Slip 1002   2026-03-18   Open        [ Edit ][ Delete ]
     Right-click -> Edit / Delete
     Keyboard    -> Enter to edit, Delete to delete

8.4 Conveying State by Color Alone

This is especially common on monitoring screens, but conveying meaning with red / yellow / green alone is risky.

Combining text, icon, timestamp, count, and description reduces both missed and misread signals.¹¹

8.5 Turning Every Validation Error into a Dialog

This is common in office entry. When a dialog appears on every input, the rhythm of the work is destroyed completely.

Errors that are local to their context sit more naturally right there in the screen.¹⁰

Before: a modal per field
  Postal code [ 1234       ]        +------------------------------+
  Address     [            ]        | Postal code format is invalid
                                    |                       [ OK ]
                                    +------------------------------

After: inline, right where it happened
  Postal code [ 1234       ]
              ! Enter 7 digits. Example 1234567
  Address     [            ]

8.6 Building with Fixed-Size Layouts

It may look clean in a development environment at 100% scaling, but under

• Text scaling
• High DPI
• Contrast themes
• Localization

it falls apart immediately.⁶⁷

Before: fixed-width labels + fixed-height buttons. Scale the text up and
  [ Ship date... ][ 2026-03-1  ]     <- the label is clipped and the value overflows
  [ Sa ][ Ca ]                       <- the button text is cut off top and bottom

After: a layout that grows with its content
  Scheduled ship date
  [ 2026-03-18              ]
  [ Save ]   [ Cancel ]              <- height comes from content + padding

The more you polish the visual finish, the more poisonous fixed sizing becomes.

8.7 Building Too Many Custom Controls

Windows standard controls carry far more behavior than their appearance suggests.

• Focus
• Keyboard
• Theme following
• UI Automation
• Connection to assistive technologies

are all taken care of, so rebuilding everything without a reason piles up UX and accessibility debt.⁸³

9. Eight Questions to Answer Before You Start

Finally, here are eight questions that are useful to place at the start of a design review.

Answering these eight up front makes the following fall into place naturally:

• Whether navigation should be shallow
• Whether list + detail is the right shape
• Whether shortcut support should be thick
• Where dialogs should be used
• How far customization should be allowed

flowchart TB
    accTitle: What the eight questions settle
    accDescr: Diagram showing that answering the eight questions before starting settles the depth of navigation, the list and detail structure, how thick shortcut support should be, where dialogs belong, and how far customization goes.
    da1["Answer the eight questions before starting"] --> da2["Navigation depth and the list and detail structure"]
    da1 --> da3["How thick shortcut support should be"]
    da1 --> da4["Where dialogs belong and how far customization goes"]
    da2 --> da5["They fall into place naturally"]
    da3 --> da5
    da4 --> da5

Figure 23: Answering the eight questions first settles the main design choices naturally.

10. Summary

What matters in Windows app UX design is deciding whether that person, in that place, with that input method, can work without stalling before deciding whether it looks nice.

flowchart TB
    accTitle: What to decide before appearance
    accDescr: Diagram showing that what matters in UX design is deciding whether that person, in that place, with that input method, can work without stalling before deciding whether it looks nice, and that UX is not decoration but a contract of operation.
    ea1["That person"] --> ea2["In that place"]
    ea2 --> ea3["With that input method"]
    ea3 --> ea4["Can work without stalling"]
    ea4 -.-> ea5["UX is not decoration but a contract of operation"]

Figure 24: Decide the person, the place, and the input method before deciding whether it looks nice.

Roughly organized, it comes to this.

• B2C prioritizes first-time comprehension and reassurance
• B2B office work prioritizes sustained efficiency and keyboard support
• B2B monitoring prioritizes not missing anomalies and safe operations
• B2B shop-floor terminals prioritize large targets and short paths
• Expert tools prioritize density, shortcuts, and customization
• Resident tools prioritize staying out of the way

And the six that pay off regardless of use case are these.

1. Use standard controls straightforwardly
2. Primary operations complete on the keyboard
3. Nothing dead-ends under touch or assistive technologies
4. Nothing breaks under text scaling or contrast themes
5. Important commands have multiple routes
6. You can get back after something goes wrong

UX is not decoration; it is a contract of operation. The better that contract meshes with the user, the environment, and the input method, the more quietly - but strongly - usable a Windows app becomes.

11. References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Should a B2B business app use a dense UI packed with information?

That is only half right. For office-entry work used daily by experienced staff, high-density lists and keyboard-only completion do pay off in sustained efficiency. But on shop-floor terminals and equipment UIs in factories, warehouses, and reception areas, density is the enemy: large targets, short paths, and clarity should come first. You are less likely to get it wrong by looking at proficiency, input method, and usage environment than by looking at the B2B label. Conversely, even in B2C, expert tools such as image editing or investment analysis prioritize information density, shortcuts, and customizability over simplicity.

What should you decide first in Windows app UX design?

B2C versus B2B is not enough. Put five questions into words first: who uses it (beginners, experts, or a mix), where it is used (a desk, the shop floor, outdoors, a reception desk), what it is operated with (keyboard, mouse, touch, scanner, assistive technology), how much it is used (mostly first-time, daily, all day), and what a mistake costs (minor, serious, dangerous, subject to audit). Once those five are visible, it becomes far easier to set priorities for UI density, navigation, shortcuts, confirmation dialogs, and customizability.

How should you choose a navigation pattern?

There is no single navigation design that works for every app; the principles are consistency, simplicity, and clarity. As rough guidance, top navigation suits cases where you want every navigation item visible on screen, left navigation suits a large number of top-level items, list/detail suits data-entry work that switches between items frequently while viewing or updating details, tabs suit dynamically opening and closing multiple documents, and breadcrumbs suit deep hierarchies where users lose track of where they are. Navigation is not a matter of visual taste; it reflects the information structure and the work structure.

How far should confirmation dialogs go?

The important thing is not to turn everything into a dialog. Per-field input errors and format errors that can be fixed on the spot sit more naturally inline in the screen than in a dialog. What genuinely deserves confirmation are irreversible-leaning operations: stopping, deleting, disconnecting, overwriting. If you do show a dialog, three things are the minimum: state clearly in the first line what will happen, make the button labels specific such as Delete or Stop rather than OK/Yes, and always include a safe, nondestructive button.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.