Design concepts
Effective menus that promote a good user experience:

Use a command presentation that matches your program type, window types, command usage, and target users.
Are well organized, using standard menu organization when appropriate.
Use menu bars, toolbars, and context menus effectively.
Use icons effectively.
Use access keys and shortcut keys effectively.

• Hide the menu bar by default if your toolbar design makes having a menu bar redundant.
• Hide the menu bar instead of removing it completely, because menu bars are more accessible for keyboard users.

Menu categories

• Choose single word names for menu categories. Using multiple words makes the separation between categories confusing.
• For programs that create or view documents, use the standard menu categories such as File, Edit, View, Tools, and Help. Doing so makes common menu items predictable and easier to find.
• Within a menu, put the groups in their logical order. If there is no logical order, place the most commonly used groups first.
• Within a group, put the items in their logical order. If there is no logical order, place the most commonly used items first. Put numeric items (such as zoom percentages) in numeric order.

Submenus

• Avoid using submenus unnecessarily. Submenus require more physical effort to use and generally make the menu items more difficult to locate.
• Don't put frequently used menu items in a submenu. Doing so would make using these commands inefficient. However, you can put frequently used commands in a submenu if they are normally accessed more directly, such as with a toolbar.

Consider using a submenu if:

Doing so simplifies the parent menu because it has many items (20 or more), or the submenu is part of a group of more than seven items.
The items in the submenu are used less frequently than those in the parent menu.
The submenu would have three or more items.
There are three or more commands that begin with the same word. In this case, use that word as the submenu label.

Context menus

• Use context menus only for contextual commands and options. The menu items should apply only to the selected (or clicked upon) object or window region, not the entire program.

Present menu items using the following order:

Primary (most frequently used) commandsOpen Run Play Print

Secondary commands supported by the object

Transfer commandsCut Copy Paste

Object settings

Object commandsDelete Rename Properties

Menu items that are options may use bullets and checkmarks. Commands may not.

Icons

• Consider providing menu item icons for:
• The most commonly used menu items.
• Menu items whose icon is standard and well known.
• Menu items whose icon well illustrates what the command does.
• If you use icons, don't feel obligated to provide them for all menu items. Cryptic icons aren't helpful, create visual clutter, and prevent users from focusing on the important menu items.

• Prefer characters with wide widths, such as w, m, and capital letters.
• Prefer a distinctive consonant or a vowel, such as "x" in "Exit."

• Don't try to assign system-wide program shortcut keys. Your program's shortcut keys will have effect only when your program has input focus.
• Document all shortcut keys. Doing so helps users learn the shortcut key assignments.
• Exception: Don't display shortcut key assignments within context menus. Context menus don't display the shortcut key assignments because they are optimized for efficiency.

• Use function keys for commands that have a small-scale effect, such as commands that apply to the selected object. For example, F2 renames the selected item.
• Use Ctrl key combinations for commands that have a large-scale effect, such as commands that apply to an entire document. For example, Ctrl+S saves the current document.
• Use Shift key combinations for commands that extend or complement the actions of the standard shortcut key.

While menu commands are used for immediate actions, more information might be needed to perform the action. Indicate a command that needs additional information (including a confirmation) by adding an ellipsis at the end of the label.

Proper use of ellipses is important to indicate that users can make further choices before performing the action, or even cancel the action entirely. The visual cue offered by an ellipsis allows users to explore your software without fear.

This doesn't mean you should use an ellipsis whenever an action displays another window only when additional information is required to perform the action. For example, the commands About, Advanced, Help, Options, Properties, and Settings must display another window when clicked, but don't require additional information from the user. Therefore they don't need ellipses.

Menu category names

• Use menu category names that are single word verbs or nouns. A multiple-word label might be confused for two one-word labels.
• Prefer verb-based menu names. However, omit the verb if it is Create, Show, View, or Manage. For example, the following menu categories don't have verbs:
• Table
• Tools
• Window

The verb is the same as the menu category name to avoid repetition. For example, in the Insert menu category, use Text, Table, and Picture instead of Insert text, Insert table, and Insert picture.

Use specific verbs. Avoid generic, unhelpful verbs, such as Change and Manage.
Use singular nouns for commands that apply to a single object, otherwise use plural nouns.
Use modifiers as necessary to distinguish between similar commands. Examples: Insert row above, Insert row below.
For pairs of complementary commands, choose clearly complementary names. Examples: Add, Remove; Show, Hide; Insert, Delete.
Choose menu item names based on user goals and tasks, not on technology.

Ribbons

Do users have trouble understanding the program's commands? Do they often resort to "trial and error" to select the right command or determine how commands work? If so, using a ribbon with results-oriented commands based on galleries and live previews makes commands easier to understand.

Make using the commands efficient:
Users should spend most of their time on the Home tab.
Users should rarely have to change tabs during common tasks.
When the window is maximized and users are on the correct tab, the most frequently used commands have the most visual emphasis and users can invoke them with a single click. Users can perform all other commands on the tab with at most four clicks.
Users shouldn't have to open dialog boxes to give commands and change attributes in common tasks.
Help users choose commands and options confidently and minimize the need for trial-and-error. Use results-oriented commands whenever appropriate, often in the form of galleries and live previews.
Make sure the ribbon scales well from the largest window sizes to the smallest.

Ribbons have the most value when used to present immediate, results-oriented commands, often in the form of galleries and live previews.

Ribbon commands require more space than toolbar commands, so they use tabs to scale. This use of tabs makes ribbons modal, requiring users to change modes occasionally to find commands. However, within a tab most commands are either direct or use a single split button or menu button, not a hierarchy.

Rich commands have these characteristics:

Labeling. All commands are given self-explanatory labels, with exceptions only when the icons are extremely well known and space is at a premium.

Here are some common pitfalls to avoid:

Avoid generic tab and group names. A good tab or group name must accurately describe its specific contents, preferably using task- and goal-based language. Avoid generic tab and group names, as well as technology-based names. For example, almost any command in a document creating and authoring program could belong in tabs labeled Edit, Format, Tools, Options, Advanced, and More. Rely on specific, descriptive labels, not memorization.

Users often look for things using the process of elimination, so prevent them from overlooking your tabs or groups because the name is misleading.

Avoid multiple paths to the same command especially if the path is unexpected or the command requires many clicks to invoke. It may seem like a convenience to find a command through multiple paths. But keep in mind that when users find what they are looking for, they stop looking.

Standard grouping. While there are significant differences in commands across programs, there are standard groups that are common across many programs. Having these commands appear with the same names and similar locations greatly improves discoverability.

Editing commands group has been split into sections that are too granular. Avoid groups with only one or two commands.

This group name is too vague to be helpful. A better approach would be to reorganize these commands into more specific groups.

Order. People read in a left-to-right order (in Western cultures), so you might think that groups on the far left are the most noticeable. However, the highlighted tab name and the window content tend to act as focal points, so groups in the center of the tab usually receive more attention than the left-most group. Place the most commonly used groups in the most prominent locations, and make sure there is a logical flow for the groups across the tab.

• Uniformity. It can be hard to recognize commands when the command presentation all looks the same. Using icons with different shapes and colors, groups with varying formats, and commands with different sizes makes it easier for users to recognize command groups. Commands should have uniform sizing only when the ribbon is scaled down to its smaller sizes.

Use a variety of icon sizes to improve recognizability

These commands look too similar to each other because they are all the same size.

Live previews are a powerful feature that can really improve your users' productivity, but even simple static previews can be a big help.

• To close a modal tab, put the Close command as the last command on the tab. Use the Close icon to make the command easy to find. Give the mode in the command to prevent confusion about what is being closed.

• In this example, explicitly labeling the Close command with the mode removes any doubt about what is being closed.

• The group has many commands of different sizes and needs organization.

Ideally, users should be able to perform common tasks without using any dialog boxes.

Avoid placing destructive commands next to frequently used commands. A command is considered destructive if its effect is widespread and either it cannot be easily undone or the effect isn't immediately noticeable.

Expose direct commands using the following controls in the following order of preference

Command buttons, check boxes, radio buttons, and in-place galleries. These are always direct.
Split buttons. Direct for the most common command, but indirect for the command variations.
Menu buttons. These are indirect, but present many commands that are easy to find.
Text boxes (with spin controls). Text input generally requires more effort than the other control types.

There is a well-defined, related set of choices from which users typically choose. There may be an unbounded number of variations, but the likely selections should be well contained.

If the user clicks the main window to dismiss the drop-down gallery, just dismiss the gallery without selecting or modifying the contents of the main window.

Use previews to show the effect of a command without users having to perform it first. By using helpful previews, you can improve the efficiency and ease of learning of your program, and reduce the need for trial-and-error.

Users must be able to evaluate different options rapidly for live previews to have their full benefit.
Avoid using text in previews. Otherwise, the preview images will have to be localized.

When practical, completely describe the command using a concise description.
Link to Help only if further explanation is really necessary.
In this example, the command doesn't need Help. Incorrect:

• Prefer concise, single word labels. While multi-word labels are acceptable, they take more space and are harder to localize.
• Do not use group names such as "Basic" and "Advanced." They require users to determine if the command they are looking for is basic or advanced.

Start the description with a verb. Use the description to help users determine whether a specific feature is the one they are looking for.

• Keep the description short. Get right to the point. Lengthy text discourages reading.

Disable individual toolbar buttons if clicking on them would directly result in an error. Doing so is necessary to maintain a direct feel.

Don't change toolbar button labels dynamically. Doing so is confusing and unexpected. However, you can change the icon to reflect the current state.

Avoid placing destructive commands next to frequently used commands. Use either order or grouping to get separation. Also, consider not placing destructive commands in the toolbar, but only in the menu bar or context menus instead.

Acceptable:

Better:

In the better example, the Delete command is physically separated from Print.

Принципы хорошей навигации

Начнем с базовых принципов разработки удобной навигации:

• Согласованность: соответствуйте ожиданиям пользователя.
• Простота: не делайте больше, чем нужно сделать.
• Понятность: предоставляйте понятные пути навигации и варианты выбора.

Общие рекомендации

1. Подумайте о пользователях. Подумайте над тем, какие пути пользователи могут часто использовать для навигации в вашем приложении, а также для каждой страницы, поразмышляйте о том, почему пользователь находится на конкретной странице и куда он собирается перейти в последствии.
2. Избегайте глубоких навигационных иерархий. Если уровней навигации будет больше трех, вы рискуете тем, что пользователь застрянет в многоуровневой иерархии, которую ему сложно будет покинуть.
3. Избегайте прыжков вверх и вниз. Прыжки вверх и вниз возникают, когда есть связанное содержимое, но для перехода к нему необходимо, чтобы пользователь перешел на один уровень вверх, а затем снова вниз.

навигация https://docs.microsoft.com/ru-ru/windows/uwp/design/basics/navigation-basics

Если размер экрана больше 640 пикселей, при нажатии кнопки меню область навигации сворачивается в полосу.

Если размер экрана меньше 640 пикселей, то область навигации полностью сворачивается. ( в бургер )

Панель команд

Может возникнуть потребность предоставить пользователям удобный доступ к самым распространенным задачам приложения.

Панель команд можно разместить в верхней или нижней части страницы, в зависимости от того, что лучше подходит для вашего приложения.

Методы создания отзывчивого дизайна

Оптимизация использования пространства и уменьшение потребности в навигации

• Выводя больший объем содержимого на экран, вы сокращаете количество действий, которые пользователю необходимо совершать для навигации.

Использование возможностей устройств

Оптимизация для ввода

Например, если вы размещаете элементы навигации в нижней части экрана, владельцам телефонов будет удобно пользоваться ими, однако большинство пользователей ПК ожидают увидеть элементы навигации в верхней части экрана.

Например, элементы управления проигрывателя мультимедиа уменьшают набор кнопок на небольших экранах и увеличивают его на больших экранах. Например, на большом экране проигрыватель мультимедиа может задействовать намного больше экранных функциональных возможностей, чем в небольшом окне.

Соответствие

Выравнивание делает внешний вид пользовательского интерфейса аккуратным, упорядоченным и сбалансированным, а также может использоваться для создания визуальной иерархии и связей между элементами.

Поле и заполнение

Свойства полей и отбивки помогают избежать перегруженности или излишней разреженности элементов пользовательского интерфейса, а также упростить использование некоторых типов ввода, таких как перо и сенсорный ввод.

TEXT

During focused, immersive reading, people read in a left-to-right, top-to-bottom order (in Western cultures).
When using software, users aren't immersed in the UI itself but in their work. Consequently, users don't read UI text they scan it.
When scanning a window, users may appear to be reading text when in reality they are filtering it. They often don't truly comprehend the UI text unless they perceive the need to.
Within a window, different UI elements receive different levels of attention. Users tend to read control labels first, especially those that appear relevant to completing the task at hand. By contrast, users tend to read static text only when they think they need to.

Rather, assume that users start by quickly scanning the whole window, then read UI text in roughly the following order:

Interactive controls in the center
The commit buttons
Interactive controls found elsewhere
Main instruction
Supplemental explanations
Window title
Other static text in main body
Footnotes

As you think about UI text and its placement on your UI surfaces, consider these facts:

Redundant text not only takes valuable screen space, but weakens the effectiveness of the important ideas or actions that you are trying to convey. It is also a waste of the reader's time, and all the more so in a context where scanning is the norm. Windows strives to explain what users need to do once well and concisely.

If you do only five things...

Work on text early because text problems often reveal design problems.
Design your text for scanning.
Eliminate redundant text.
Use easy-to-understand text; don't over-communicate.
When necessary, provide links to Help content for more detailed information.

Remove redundant text. Look for redundant text in window titles, main instructions, supplemental instructions, content areas, command links, and commit buttons. Generally, leave full text in main instructions and interactive controls, and remove any redundancy from the other places.

• In this example, there's a chance that users won't read the text that explains what they're confirming.
• Better:

• Use one space between sentences. Not two.

Be aware that using too much bold lessens its impact.

For mostly self-explanatory data, use plain labels and bold data so that users can focus on the data itself.

Alternatively, you can use dark gray text to de-emphasize less important information instead of using bold to emphasize the more important information.

Labels: Indicate that a task is in progress (for example, "Searching...").

Don't make ellipses interactive. To show truncated text, let users resize the control to see more text or use a progressive disclosure control instead.

To refer to text literally, use italic formatting rather than quotation marks.

In this example, the long date format helps users organize tasks and deadlines.

Use the main instruction to explain concisely what users should do in a given window or page. Good main instructions communicate the user's objective rather than focusing just on manipulating the UI.

Express the main instruction in the form of an imperative direction or specific question.

Exceptions: Error messages, warning messages, and confirmations may use different sentence structures in their main instructions.

Incorrect:

Correct:

Incorrect:

Correct:

Use the Windows tone to inspire confidence by communicating to users on a personal level by being accurate, encouraging, insightful, objective, and user focused. The Windows tone also strives to be light, inspiring, straightforward, and trustworthy.

Tone in your program should be:

• Accurate. Users should feel reassured that the information is technically accurate. If the information isn't accurate, the user's experience with that specific task is spoiled, and he loses faith in any other assistance he reads from that source.
• Encouraging. Use language that conveys that the software empowers users to do things, rather than allows them to do things. For example, use "you can" rather than "Windows lets you" or "this feature allows you." (Exception: it's okay to use "allow" when referring to features—such as security features—that permit or deny an action.)
• Insightful. Users should believe that you (and by extension your application) know when a certain task is complicated and that you will guide them through it. At the same time, treat users as intelligent people who happen to need help with a particular problem.
• Objective. Sometimes users want a richer explanation; often though they just want to know what they need to move on. This requires objectivity—to recognize that the goal (productivity, curiosity, enjoyment) is the user's goal, not the writer's. It also requires that you shed any predisposed notions about the user.
• User-focused. Write from the user's perspective and preferably from the perspective of what you can do for the user. Users should feel that they will find information that is relevant and accessible to them.

Use short, plain words whenever possible. Shorter words are more conversational, save space on screen, and are easier to scan.

Be precise

Choose words with a clear meaning.
Omit needless words—don't use two or three words when one will do.
Avoid unnecessary adverbs.
Choose single-word verbs over multi-word verbs.
Don't convert verbs to nouns and nouns to verbs.

Use sorry only in error messages that result in serious problems for the user (for example, data loss, the user can't continue to use the computer, or the user must get help from a technical representative). Don't apologize if the issue occurred during the normal functioning of the program (for example, if the user needs to wait for a network connection to be found).

ERRORS

Effective error messages inform users that a problem occurred, explain why it happened, and provide a solution so users can fix the problem. Users should either perform an action or change their behavior as the result of an error message.

Well-written, helpful error messages are crucial to a quality user experience. Poorly written error messages result in low product satisfaction, and are a leading cause of avoidable technical support costs. Unnecessary error messages break users' flow.

Can the problem be prevented without causing confusion? If so, prevent the problem instead. For example, use controls that are constrained to valid values instead of using unconstrained controls that may require error messages.

Are users likely to perform an action or change their behavior as the result of the message? If not, the condition doesn't justify interrupting the user so it's better to suppress the error.

Is the problem relevant when users are actively using other programs? If so, consider showing the problem using a notification area icon.

Is the problem not related to the current user activity, does it not require immediate user action, and can users freely ignore it? If so, use an action failure notification instead.

Does the problem relate to the status of a background task within a primary window? If so, consider showing the problem using a status bars.

The characteristics of good error messages

In contrast to the previous bad examples, good error messages have:

• A problem. States that a problem occurred.
• A cause. Explains why the problem occurred.
• A solution. Provides a solution so that users can fix the problem.

The most obvious error messages to avoid are those that aren't actionable. If users are likely to dismiss the message without doing or changing anything, omit the error message.

Technically, this is an error, but instead of giving an error message, the program could:

• Continue to search for products that most closely match the query.
• If the search has obvious mistakes, automatically recommend a corrected query.
• Automatically handle common problems such as misspellings, alternative spellings, and mismatching pluralization and verb cases.
• Indicate when the product will be in stock.

Another great way to avoid error messages is by preventing problems in the first place. You can prevent errors by:

• Using constrained controls. Use controls that are constrained to valid values. Controls like lists, sliders, check boxes, radio buttons, and date and time pickers are constrained to valid values, whereas text boxes are often not and may require error messages. However, you can constrain text boxes to accept only certain characters and accept a maximum number of characters.
• Using constrained interactions. For drag operations, allow users to drop only on valid targets.
• Using disabled controls and menu items. Disable controls and menu items when users can easily deduce why the control or menu item is disabled.
• Providing good default values. Users are less likely to make input errors if they can accept the default values. Even if users decide to change the value, the default value lets users know the expected input format.
• Making things just work. Users are less likely to make mistakes if the tasks are unnecessary or performed automatically for them. Or if users make small mistakes but their intention is clear, the problem is fixed automatically. For example, you can automatically correct minor formatting problems.

A common belief is that error messages are the worst user experience and should be avoided at all costs, but it is more accurate to say that user confusion is the worst experience and should be avoided at all costs. Sometimes that cost is a helpful error message.

but it is more accurate to say that user confusion is the worst experience and should be avoided at all costs

Error message presentation

Most error messages in Windows programs are presented using modal dialog boxes (as are most examples in this article), but there are other options:

• In-place
• Balloons
• Notifications
• Notification area icons
• Status bars
• Log files (for errors targeted at IT professionals)

By using Help to provide the details, this error message has an inverted pyramid style of presentation.

Use a different error message (typically a different supplemental instruction) for each detectable cause. For example, if a file cannot be opened for several reasons, provide a separate supplemental instruction for each reason.
Use a message with multiple causes only when the specific cause can't be determined. In this case, present the solutions in order of likelihood of fixing the problem. Doing so helps users solve the problem more efficiently.

Use an error icon. Exceptions:

If the error is a user input problem displayed using a modal dialog box or balloon, don't use an icon. Doing so is counter to the encouraging tone of Windows. However, in-place error messages should use a small error icon (16x16 pixel) to clearly identify them as error messages.

If the problem is for a feature that has an icon (and not a user input problem), you can use the feature icon with an error overlay. If you do this, also use the feature name as the error's subject.

Don't use warning icons for errors. This is often done to make the presentation feel less severe. Errors aren't warnings.

Design error messages to avoid the need for Help. Ordinarily users shouldn't have to read external text to understand and solve the problem, unless the solution requires several steps.

Sound

• Don't accompany error messages with a sound effect or beep. Doing so is jarring and unnecessary.
• Exception: Play the Critical Stop sound effect if the problem is critical to the operation of the computer, and the user must take immediate action to prevent serious consequences.

• Don't use the following words:
• Error, failure (use problem instead)
• Failed to (use unable to instead)
• Illegal, invalid, bad (use incorrect instead)
• Abort, kill, terminate (use stop instead)
• Catastrophic, fatal (use serious instead)

Don't use phrasing that blames the user or implies user error. Avoid using you and your in the phrasing. While the active voice is generally preferred, use the passive voice when the user is the subject and might feel blamed for the error if the active voice were used.

Incorrect:

File not found.

Disk is full.

Value out of range.

Character is invalid.

Device not available.

These problems would be much easier to solve with specific names, locations, and values.

Avoid the word "please," except in situations in which the user is asked to do something inconvenient (such as waiting) or the software is to blame for the situation.

• Use the word "sorry" only in error messages that result in serious problems for the user (for example, data loss or inability to use the computer). Don't apologize if the issue occurred during the normal functioning of the program (for example, if the user needs to wait for a network connection to be found).

Use double quotation marks around object names. Doing so makes the text easier to parse and avoids potentially embarrassing statements.

Avoid starting sentences with object names. Doing so is often difficult to parse.

sparingly - экономно
interchangeably - взаимозаменяемо
text is truncated - текст усечён
Don't rely - не полагайтесь
detectable causes - обнаруживаемыми причинами
appropriate - подходящий
Be concise - быть кратким
supplemental - дополнительный
distracting, condescending, or arrogant tone - отвлекающий, снисходительный, высокомерный тон
disengaged - оторванными
Trustworthy - заслуживающий доверия
Feels like being interrogated with a barrage of intrusive questions - Такое ощущение, что тебя допрашивают с градом назойливых вопросов.
drawback - недостаток
rude - грубый
Boastful tone - хвастливый тон
judiciously - рассудительно
interrogative - вопросительный
explanation is utterly baffling - объяснение совершенно сбивает с толку
suitable - подходящий
appropriate - подходящий