UX Windows-приложений: приоритеты по среде использования

Когда думаете об UX Windows-приложения, легко сбиться с порядка, если начинать с «выглядит ли это современно» или «аккуратны ли отступы».

На настольной Windows UX не определяется одним внешним видом.

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

Всё это вместе и есть UX.

flowchart TB
    accTitle: UX не сводится к внешнему виду
    accDescr: Рисунок показывает, что UX складывается из способа ввода и того, насколько работу можно завершить, из времени использования и назначения, из цены ошибки и того, можно ли работать со вспомогательными технологиями вроде программы экранного доступа.
    a1["Способ ввода и полнота операций"] --> a4["Всё это вместе и есть UX"]
    a2["Время использования и назначение"] --> a4
    a3["Цена ошибки и вспомогательные технологии"] --> a4
    a4 -.-> a5["Старт с «выглядит современно» сбивает порядок"]

Рис. 1: UX настольной Windows определяется связкой контекста использования, а не внешним видом.

Ещё сложнее то, что у B2C и B2B разный центр тяжести. Но если из этого сделать «раз B2B, значит набить экран информацией» или «раз B2C, значит сделать всё лёгким и воздушным», почти наверняка где-то произойдёт сбой.

Например, даже внутри B2B

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

условия хорошего UX сильно различаются.

И наоборот, даже внутри B2C

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

сильно различаются и по плотности UI, и по требованиям к горячим клавишам.

flowchart TB
    accTitle: Один ярлык — разные условия
    accDescr: Рисунок показывает, что внутри одного ярлыка B2B офисное приложение, цеховой терминал и экран эксплуатации требуют разного UX, а внутри B2C небольшая утилита и инструмент для опытных пользователей различаются и по плотности, и по требованиям к горячим клавишам.
    b0["Один ярлык B2B"] --> b1["Офис, цеховой терминал, эксплуатация"]
    b1 --> b2["Условия хорошего UX сильно различаются"]
    c0["Один ярлык B2C"] --> c1["Утилита и инструмент для опытных"]
    c1 --> c2["Различаются плотность и горячие клавиши"]

Рис. 2: Даже внутри одного ярлыка B2C / B2B условия хорошего UX расходятся.

Руководство Microsoft по проектированию для Windows тоже подчёркивает: проектирование Windows-приложения должно быть интуитивным, доступным и работать согласованно вне зависимости от способа ввода и форм-фактора.¹²

В этой статье UX Windows-приложений сведён в таблицу решений по сценариям использования. Цель — на ревью проектирования или на ранней стадии проектирования экранов легче ответить, что именно у этого приложения должно стоять выше.

Для кого эта статья и какие предпосылки

Термины, которые используются в статье

1. Сначала вывод

Если сказать грубо и сразу, получится так.

• Для B2C сначала важны понятность при первом знакомстве, чувство спокойствия, мало настроек и прямые сценарии
• Для B2B сначала важны устойчивая эффективность, предотвращение ошибочных действий, поддержка клавиатуры и стабильное расположение
• Но для цехового терминала в B2B выше плотности стоят ясность, крупные объекты управления и короткие сценарии
• А для инструмента продвинутого уровня в B2C выше простоты стоят плотность информации, горячие клавиши и настраиваемость
• В Windows-приложении UX ломается реже, если думать его вплоть до клавиатуры / мыши / сенсора / увеличения текста / контрастных тем / вспомогательных технологий¹³⁴⁵⁶⁷

То, что действительно нужно решить в первую очередь, — не только выбор между B2C и B2B. Сначала стоит сформулировать эти пять пунктов.

1. Кто пользуется (новичок, опытный пользователь, смешанная аудитория)
2. Где используется (за столом, в переговорной, на площадке, на заводе, на ресепшене, на улице)
3. Чем управляют (клавиатура, мышь, сенсор, перо, штрихкод, вспомогательные технологии)
4. Насколько часто используется (в основном при первом знакомстве, изредка, каждый день, весь день)
5. Какова цена ошибки (незначительная, серьёзная, опасная, подлежащая аудиту)

Когда эти пять пунктов ясны, приоритеты по плотности UI, навигации, горячим клавишам, диалогам подтверждения и настраиваемости расставлять гораздо проще.

flowchart TB
    accTitle: Пять вопросов, которые формулируют раньше
    accDescr: Рисунок показывает, что когда ясны кто пользуется, где, чем управляют, насколько часто и какова цена ошибки, легче расставить приоритеты по плотности, навигации и диалогам.
    q1["1. Кто пользуется"] --> q2["2. Где используется"]
    q2 --> q3["3. Чем управляют"]
    q3 --> q4["4. Насколько часто"]
    q4 --> q5["5. Какова цена ошибки"]
    q5 --> q6["Складываются приоритеты плотности, навигации, диалогов"]

Рис. 3: Приоритеты складываются, если пять вопросов сформулировать раньше, чем делить на B2C и B2B.

Карта знаний этой статьи

Статья предлагает проектировать UX Windows-приложения не только по классификации B2C/B2B, а по контексту использования: кто управляет, где, чем, насколько часто и какова цена ошибки. Для B2C-утилиты подходят верхняя навигация и лёгкость понимания с первого раза; для офисного B2B — список/детали и удобство клавиатуры; для мониторинга и эксплуатации — боковая навигация, отображение состояния не только цветом, команды по нескольким путям и диалог подтверждения необратимой операции; для полевого терминала — достаточно крупный touch target и дизайн, не зависящий от hover; для инструмента специалиста — вкладки и плотная поддержка клавиатуры. Также разбираются числовые критерии вроде touch target 7,5 мм в квадрате и коэффициента контраста 4.5:1 и важность макета, который следует за увеличением текста и темами контраста.

flowchart LR
    accTitle: Карта знаний осей решений UX Windows-приложений
    accDescr: Схема показывает, что контекст использования — кто управляет, где и чем — задаёт приоритеты UX: шаблон навигации, размер touch target, удобство клавиатуры и то, как применяют диалоги
    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["отображение ошибки validation в поле"]
    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["чрезмерное создание custom control"]
    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. B2C / B2B — точка входа, но не сам ответ

Деление на B2C / B2B удобно как первая точка входа. Однако правильный UX сильнее определяет не тип покупателя, а тип использования.

Например, грубо по двум осям это выглядит так.

То есть неверно, что

• B2C = всегда лёгкий UI
• B2B = всегда плотный UI

В руководстве по проектированию Windows-приложений тоже подчёркивается согласованное удобство независимо от устройств, типов ввода и форм-факторов, а с точки зрения доступности важно учитывать не только ограничения по здоровью, но и такие условия среды, как яркий свет на улице, общие пространства, тихие или шумные места.¹²

flowchart TB
    accTitle: Тип использования сильнее типа покупателя
    accDescr: Рисунок показывает, что равенства «B2C всегда лёгкий UI» и «B2B всегда плотный UI» не существует, и правильный UX определяет тип использования, включая ограничения среды.
    e1["B2C = всегда лёгкий UI"] --> e3["Эти равенства не работают"]
    e2["B2B = всегда плотный UI"] --> e3
    e3 --> e4["Ответ даёт тип использования"]
    e4 -.-> e5["Учитывают и ограничения среды"]

Рис. 4: Правильный UX определяет тип использования, а не тип покупателя.

Поэтому после взгляда на B2C / B2B полезно дополнительно разрезать по следующим осям.

Если разрезать это заранее, разговоры на встречах вроде «выглядит как-то по-модному» или «выглядит как-то по-корпоративному» заметно сокращаются.

3. Таблица решений по сценариям на одну страницу

Сначала — таблица, которой удобнее всего пользоваться на практике.

Уже одной этой таблицы достаточно, чтобы увидеть общее направление. Особенно важно, что даже в B2B цеховые терминалы не следует делать плотным UI, а даже в B2C для продвинутых инструментов эффективность важнее лёгкости.

flowchart TB
    accTitle: Два случая, где ярлык и ответ меняются местами
    accDescr: Рисунок показывает два примера, где ответ, который ждут от ярлыка, меняется на противоположный: цеховой терминал B2B не должен быть плотным UI, а продвинутый инструмент B2C ставит эффективность выше лёгкости.
    f1["Цеховой терминал B2B"] --> f2["Плотный UI здесь не ответ"]
    f3["Продвинутый инструмент B2C"] --> f4["Эффективность важнее лёгкости"]
    f2 --> f5["Решают не по ярлыку, а по сценарию"]
    f4 --> f5

Рис. 5: Две строки таблицы, где ответ, ожидаемый от ярлыка, меняется на противоположный.

Если спешите, на этой главе можно остановиться. Глава 4 разворачивает каждую строку таблицы до «почему так» и «что именно ставить на экран». Те же выводы таблица уже дала, поэтому главу можно читать как материал, который в таблицу не поместился.

4. Направления проектирования по сценариям

4.1 Утилита / персональное приложение B2C

Для небольшого B2C-приложения на Windows сильнее всего работает «можно пользоваться сразу после запуска».

Особенно стоит подчеркнуть следующее.

• Уже на первом экране понятно, для чего это приложение
• Основные действия сведены к одному-двум
• Пустое состояние не выглядит неприветливо
• Опасные действия можно отменить
• Не показывать все пункты настроек сразу

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

Руководство по проектированию навигации в Windows тоже говорит, что единого правильного решения для всех приложений нет, и в первую очередь подчёркивает согласованность, простоту и ясность. Стандартные элементы и стандартные места делают UI предсказуемым.⁸

Поэтому для B2C зачастую достаточно такой организации:

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

flowchart TB
    accTitle: Как упорядочить B2C
    accDescr: Рисунок показывает, что для B2C ось — «можно пользоваться сразу после запуска»: небольшой размер ведёт к одному экрану, равноправные разделы — к верхней навигации, настройки показывают постепенно, основное действие делают ярким.
    g1["Можно пользоваться сразу после запуска"] --> g2["Небольшое — один экран"]
    g1 --> g3["Равноправные разделы — верхняя навигация"]
    g1 --> g4["Настройки показывают постепенно"]
    g4 -.-> g5["Основное действие яркое, остальное тише"]

Рис. 6: Лёгкий инструмент B2C упорядочивают ближе к «сразу можно пользоваться», а не к «много функций».

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

4.2 Офисный ввод / back-office B2B

В офисных B2B-приложениях важна не лёгкость внешнего вида, а то, что работа не останавливается.

Ежедневные пользователи привыкают к UI за несколько дней. После этого начинает иметь значение вот что:

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

Руководство Microsoft по доступности с клавиатуры тоже говорит, что приложение должно давать доступ ко всей функциональности с клавиатуры, рекомендуя порядок Tab, фокус, активацию через Enter / Space и реализацию горячих клавиш.³

Access key полезны не только для доступности, но и для эффективности опытных пользователей, предпочитающих клавиатуру. Там, где это уместно, рекомендуется поддерживать их, включая собственные элементы.⁹

Для систем ввода данных надёжный выбор навигации — список/детали. В руководстве по навигации Windows тоже отмечается, что список/детали подходит, когда часто переключаются между элементами, просматривая или обновляя детали, что соответствует таким сценариям, как почтовый ящик, список контактов, ввод данных.⁸

Иными словами, естественна такая компоновка:

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

flowchart TB
    accTitle: Прямая компоновка офисного ввода
    accDescr: Рисунок показывает прямую компоновку офисного ввода: сверху поиск, фильтры и основные команды, слева категории функций, в центре список, справа или снизу детали и правка, часто используемые действия — с горячими клавишами.
    h1["Сверху: поиск, фильтры, основные команды"] --> h2["Слева: категории функций"]
    h2 --> h3["Центр: список"]
    h3 --> h4["Справа или снизу: детали и правка"]
    h4 -.-> h5["Частые действия — с горячими клавишами"]

Рис. 7: Прямая компоновка офисного ввода вокруг списка/деталей.

И наоборот, стоит перечислить паттерны, которых лучше избегать.

• Диалог на каждое действие
• Слишком мало столбцов, из-за чего обзор списка низкий
• Основные действия доступны только глубоко в контекстном меню
• Попытка передать смысл одними значками
• Хаотичный порядок Tab, где не работают ни Enter, ни Space

По ошибкам ввода тоже: ошибки проверки, привязанные к полю, естественнее показывать не в диалоге, а прямо на экране. Руководство Windows по диалогам тоже рекомендует для контекстно привязанных ошибок проверки, например для полей пароля, не использовать диалог, а показывать сообщение на месте.¹⁰

4.3 Мониторинг и эксплуатация B2B

Для экранов мониторинга и эксплуатации важнее «удобства» — не пропустить, не ошибиться, не остановиться.

Приоритеты здесь примерно такие.

• Наличие аномалии видно с первого взгляда
• Понятна серьёзность аномалии
• Можно проследить не только текущее значение, но и изменения и временной ряд
• Путь к опасным операциям не слишком лёгкий
• Журналы, история, разбор причин доступны в один переход

В экранах такого рода представление состояния — сердце UX. Состояние безопаснее выражать несколькими элементами сразу — цветом + текстом + значком + временем. Передача состояния одним цветом провоцирует пропуски и ошибки распознавания и слаба с точки зрения доступности.¹¹

flowchart TB
    accTitle: Состояние показывают несколькими элементами
    accDescr: Рисунок показывает, что на экранах мониторинга и эксплуатации представление состояния — центр UX, и один цвет легко даёт пропуски и ошибки распознавания, поэтому безопаснее сочетать цвет, текст, значок и время.
    i1["Состояние только цветом"] --> i2["Легко пропустить или перепутать"]
    i2 -.->|"вместо этого"| i3["Цвет + текст + значок + время"]
    i3 --> i4["И пропусков, и ошибок распознавания меньше"]

Рис. 8: Состояние на экране мониторинга показывают не одним цветом, а набором элементов.

Для навигации, если объектов мониторинга много, хорошо работает левая навигация, углубление в конкретный объект — через drill-down, а детали — через журналы или временной ряд. В руководстве по навигации Windows тоже отмечается, что левая навигация подходит для множества пунктов верхнего уровня и структур, где переключение страниц не происходит непрерывно.⁸

С точки зрения взаимодействия размещать команду только в одном месте тоже рискованно. Руководство Windows по проектированию команд рекомендует, чтобы команды были доступны через несколько поверхностей — кнопки, контекстные меню, горячие клавиши, жесты, и чтобы все связанные команды входили в контекстное меню или CommandBarFlyout. Опора только на операции, доступные при наведении, делает их недоступными на сенсорных устройствах и со вспомогательными технологиями.¹²¹³

Диалоги подтверждения для опасных операций тоже важны здесь. Но подход «на всякий случай подтверждать всё» контрпродуктивен. По-настоящему подтверждения требуют операции, близкие к необратимым: остановить, удалить, переключить, отключить, перезаписать. Если диалог всё же показывают, минимум стоит соблюсти следующее:

• в первой строке ясно сказать, что произойдёт
• текст кнопок сделать конкретным — «Удалить» / «Остановить» / «Отключить», а не «OK» / «Да»
• обязательно дать безопасный вариант

¹⁰

flowchart TB
    accTitle: Три правила диалога подтверждения
    accDescr: Рисунок показывает, что подтверждать нужно операции, близкие к необратимым — остановить, удалить, отключить, — и если диалог показывают, в первой строке пишут, что произойдёт, текст кнопок делают конкретным и обязательно ставят безопасный вариант.
    j1["Подтверждают только близкие к необратимым операции"] --> j2["В первой строке — что произойдёт"]
    j1 --> j3["Текст кнопок конкретный"]
    j1 --> j4["Обязательно безопасный вариант"]
    j2 -.-> j5["«На всякий случай всё» даёт обратный эффект"]

Рис. 9: Диалог подтверждения оставляют необратимым операциям и держат три минимума.

4.4 Цеховой терминал / UI оборудования / киоск B2B

Цеховые терминалы внутри UX Windows-приложений — совсем другой вид.

• пользователь не сидит
• возможно, в перчатках
• свободна только одна рука
• экран не рассматривают внимательно
• есть нехватка времени
• используется в ярком или шумном окружении

Эти условия вполне обычны.

Руководство Microsoft по доступности тоже говорит, что хорошее Windows-приложение должно учитывать не только ограничения по здоровью, но и условия среды — яркий солнечный свет, общие пространства, шум, тишину или готовку.²

А в проектировании сенсорного ввода есть такие различия:

• у сенсорного ввода нет hover
• пальцы и рука перекрывают (occlusion) UI
• часть экрана неудобно нажимать с учётом положения руки
• важна визуальная обратная связь

⁴

flowchart TB
    accTitle: Четыре отличия сенсорного проектирования
    accDescr: Рисунок показывает отличия проектирования: у сенсорного ввода нет hover, палец или рука перекрывают UI, часть экрана неудобно нажимать из-за позы, и важна визуальная обратная связь.
    k1["Сенсорный ввод"] --> k2["Нет hover"]
    k1 --> k3["Палец или рука перекрывают UI"]
    k1 --> k4["Есть места, неудобные из-за позы"]
    k4 -.-> k5["Важна визуальная обратная связь"]

Рис. 10: У сенсора другие предпосылки по hover и перекрытию, поэтому способ показать обратную связь становится ключевым.

Поэтому для цеховых терминалов обычно ориентируются так:

• кнопки и элементы списка достаточно крупные
• приближение к принципу «один экран — одна цель»
• чёткая реакция после каждого действия
• поэтапное разбиение потока
• ввод по возможности ближе к выбору, сканированию и шаблонам, а не к свободному вводу
• состояние ясно показывают сверху или в центре экрана

Чего стоит избегать:

• мелкого текста
• маленьких областей нажатия
• зависимости от всплывающих подсказок на hover
• глубоких иерархий
• массы информации на одном экране
• длинного свободного ввода

Именно здесь легковесная идея «раз B2B, значит плотность лучше» промахивается сильнее всего. Скорее это мир, где ясность в приоритете сильнее, чем где-либо ещё среди бизнес-приложений.

flowchart TB
    accTitle: Цеховой терминал ставит ясность выше
    accDescr: Рисунок показывает направление цехового терминала: ближе к одному экрану на одну цель, ввод ближе к выбору, сканированию и шаблонам, реакция после действия явная — среди бизнес-приложений ясность здесь особенно важна.
    l1["Цеховой терминал / UI оборудования"] --> l2["Ближе к одному экрану на одну цель"]
    l1 --> l3["Ввод ближе к выбору, сканированию, шаблонам"]
    l1 --> l4["Реакцию после действия показывают явно"]
    l2 --> l5["Среди бизнес-приложений ясность особенно важна"]
    l3 --> l5
    l4 --> l5

Рис. 11: Цеховой терминал сдвигают не к плотности, а к ясности, крупным объектам управления и коротким сценариям.

4.5 Инструменты правки и анализа для специалистов

В инструментах для специалистов «сделайте понятнее» иногда проигрывает «не заставляйте меня останавливаться».

Например:

• CAD
• анализ сигналов
• видеомонтаж
• обработка изображений
• создание музыки
• инструменты для разработчиков
• анализ данных
• инструменты аудита / диагностики

Для приложений такого рода хорошо работают следующие элементы.

• Плотность информации
• Несколько панелей
• Вкладки
• Контекстные меню
• Горячие клавиши
• Сохранение компоновки
• Настраиваемые столбцы и отображаемые поля
• Undo / Redo
• Восстановление состояния работы

В руководстве по навигации Windows тоже отмечается, что вкладки подходят, когда одновременно открывают, закрывают и переупорядочивают несколько страниц или документов.⁸ А в проектировании команд Windows рекомендуется делить команды между несколькими поверхностями UI, чтобы одно и то же действие было доступно независимо от способа ввода.¹²

Частая ошибка с инструментами такого рода — попытка проявить заботу о новичках, пряча всё в глубокие меню. Но опытные пользователи выполняют одно и то же действие сотни раз в день. Для них важна не мягкость первых пяти минут, а отсутствие усталости после 100 часов использования.

Поэтому для продвинутых пользователей хорошо работает такое проектирование:

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

flowchart TB
    accTitle: Как раскладывать функции для опытных пользователей
    accDescr: Рисунок показывает, что опытные пользователи делают одно и то же сотни раз в день, поэтому важнее не мягкость первых пяти минут, а отсутствие усталости после 100 часов: частые действия рядом, вспомогательные чуть дальше, продвинутые не удаляют, а упорядочивают.
    n1["Опытные пользователи делают одно и то же сотни раз в день"] --> n2["Частые действия кладут рядом"]
    n1 --> n3["Вспомогательные — чуть дальше"]
    n1 --> n4["Продвинутые не удаляют, а упорядочивают"]
    n2 -.-> n5["Важнее усталость после 100 часов, чем первые 5 минут"]

Рис. 12: В инструменте для специалистов функции раскладывают по расстоянию в зависимости от частоты.

4.6 Резидентные утилиты и приложения в трее

Для резидентных приложений сама UX-задача — не проявлять присутствие приложения чрезмерно.

Например, для таких приложений, как

• статус синхронизации
• статус подключения
• резервное копирование
• переключение звука / камеры / устройств
• VPN / агенты / лаунчеры
• центр уведомлений

главное окно нередко не главный герой.

Приоритетно:

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

Чего стоит избегать:

• диалогов по мелочам
• открытия главного окна при каждом запуске
• невидимости фоновой активности
• избытка уведомлений, из-за которого их все игнорируют

Для приложений такого рода ненавязчивость влияет на UX сильнее, чем обилие функций.

flowchart TB
    accTitle: Для резидентной утилиты UX — не мешать
    accDescr: Рисунок показывает, что резидентные утилиты ставят выше доступ из трея или небольшого меню, понятность текущего состояния и уведомления только когда нужно, а избыток уведомлений приводит к тому, что их все игнорируют.
    r1["Достать из трея сразу"] --> r4["UX в том, чтобы не мешать"]
    r2["Текущее состояние понятно"] --> r4
    r3["Уведомления только когда нужно"] --> r4
    r4 -.-> r5["Слишком много уведомлений — их все игнорируют"]

Рис. 13: У резидентной утилиты UX как раз в том, чтобы не выпячивать присутствие.

5. Таблица решений по навигации

В руководстве по навигации Windows утверждается, что единого навигационного решения, подходящего всем приложениям, нет, а базовыми принципами служат согласованность, простота и ясность. Кроме того, размещение стандартных элементов там, где их ожидает пользователь, делает UI предсказуемым.⁸

flowchart TB
    accTitle: Принципы проектирования навигации
    accDescr: Рисунок показывает, что единого правильного паттерна навигации нет, принципы — согласованность, простота и ясность, а стандартные элементы ставят туда, где их ждут, чтобы UI был предсказуемым.
    s0["Единого правильного паттерна нет"] --> s1["Согласованность"]
    s0 --> s2["Простота"]
    s0 --> s3["Ясность"]
    s3 -.-> s4["Стандартные элементы — туда, где их ждут"]

Рис. 14: У навигации нет единственного правильного ответа; предсказуемость дают три принципа и стандартные места.

На практике удобно разрезать по такой таблице.

В руководстве по навигации Windows особо приводится следующее разграничение.⁸

• Верхняя навигация: когда нужно показать на экране все пункты навигации
• Левая навигация: когда пунктов верхнего уровня много и частое переключение страниц не требуется
• Список/детали: когда переключение элементов частое и нужен просмотр или обновление деталей
• Вкладки: когда несколько документов или страниц нужно динамически открывать и закрывать
• «Хлебные крошки»: когда иерархия глубока и путь назад должен быть понятен

5.1 Каркасные схемы только скелетом

Словами картинка плохо складывается, поэтому ниже четыре типичных скелета. Детали можно игнорировать — смотрите только, что где лежит.

[ Верхняя навигация ]  когда все страницы одного уровня нужно показать
+-------------------------------------------------------------
| AppName        Главная | Преобразование | История | Параметры
+-------------------------------------------------------------
|
|    Основное содержимое
|    Ближе к одному экрану на одну цель
|
+-------------------------------------------------------------


[ Левая навигация ]  когда пунктов верхнего уровня много
+-------------------------------------------------------------
| AppName                                 Поиск [           ]
+-------------------------------------------------------------
| Дашборд         |
| Список устройств |    Основное содержимое
| Оповещения      |
| Задания         |
| Отчёты          |
| Параметры       |
+-------------------------------------------------------------


[ Список/детали ]  переключать элементы, смотреть и обновлять детали
+-------------------------------------------------------------
| Поиск [          ]  Фильтр: необработанные / все      [Создать] [Удалить]
+-------------------------------------------------------------
| Список           |  Детали / правка
|  > Документ 1001 |    Номер        1001
|    Документ 1002 |    Контрагент   ...
|    Документ 1003 |    Строки       ...
|    Документ 1004 |
|                  |    [ Сохранить ]   [ Отмена ]
+-------------------------------------------------------------


[ Дашборд + drill-down ]  найти аномалию и копнуть
+-------------------------------------------------------------
| Итого   норма 22    внимание 3    аномалия 1        обновлено 0.5 с назад
+-------------------------------------------------------------
| Аномалия 1
|   ! Линия B, инспекционное устройство    нет ответа    48 с назад    [ Подробнее ]
| Внимание 3
|   - Линия A, камера                      значение устарело    12 с назад    [ Подробнее ]
|   ...
+-------------------------------------------------------------
              |
              |  нажать [ Подробнее ]
              v
+-------------------------------------------------------------
| < К списку       Линия B, инспекционное устройство / нет ответа
+-------------------------------------------------------------
| Текущее значение | График ряда | Журнал событий | Операции
+-------------------------------------------------------------

Если поставить четыре скелета рядом, ось выбора становится ясной.

• Верхняя и левая навигация расходятся по числу пунктов верхнего уровня. Если все умещаются в ряд — верхняя, если нет — левая
• Главный герой списка/деталей — не правая панель, а список слева. Если информации в списке мало, детали приходится открывать снова и снова
• Суть дашборда — в первой строке показать, сколько аномалий. Если пользователь ушёл «копать», путь назад обязателен

Иными словами, навигация — не «вопрос визуальных предпочтений», а отражение структуры информации и структуры работы.

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, реагируют
• Есть горячие клавиши для важных функций
• Для часто используемых действий предусмотрены access key и акселераторы

У сенсорного ввода есть такие особенности.⁴

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

6.1 Решать не «достаточно крупно», а числом

На ревью проектирования чаще всего спорят там, где останавливаются на «достаточно крупно» и «явно». Там, где руководство Microsoft уже даёт число, это число лучше сразу сделать критерием «проходит / не проходит» — тогда разговор короче.

Когда число зафиксировано, меняется и формулировка на ревью. Вместо «эта кнопка не мелковата?» можно сказать «эта кнопка 32 px, до ориентира 7.5 mm не дотягивает» — и решение, править или нет, заканчивается на месте.

flowchart TB
    accTitle: С числом ревью идёт быстрее
    accDescr: Рисунок показывает, что остановка на «достаточно крупно» и «явно» плодит споры на ревью, а число из руководства как критерий «проходит / не проходит» сразу даёт ответ, править или нет.
    v1["Остановка на «достаточно крупно»"] --> v2["На ревью начинается спор"]
    v2 -.->|"вместо этого"| v3["Число сразу как критерий проходит / не проходит"]
    v3 --> v4["Можно сказать, дотягивает или нет"]
    v4 --> v5["Решение заканчивается на месте"]

Рис. 17: Если число стало критерием, спор о размере заканчивается на месте.

Заметьте: стандартные элементы WinUI по умолчанию уже держат этот размер цели.¹⁵ Обратная сторона: опасно как раз в собственных элементах и в собственной отрисовке.

В проектировании команд хороший ориентир — руководство Windows по командам. Особенно важно делать команды доступными с нескольких поверхностей UI.¹²

• нажимается кнопкой
• также есть в контекстном меню
• также вызывается горячей клавишей
• при необходимости — свайпом или жестом

Рекомендуется также, чтобы все связанные команды входили в контекстные меню или CommandBarFlyout. Зависимость от операций, видимых только при наведении, создаёт затруднения на устройствах только с сенсорным вводом.¹²

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. Минимум пунктов UX, которые не стоит упускать в Windows-приложении

Далее собраны минимальные пункты, важные вне зависимости от сценария использования.

7.1 Можно ли завершить работу только с клавиатуры

На настольной Windows клавиатура — это не «приятное дополнение», а полноценный способ ввода.

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

Минимум стоит проверить эти пять пунктов.

• Естественен ли порядок Tab
• Есть ли визуализация фокуса
• Можно ли нажать через Enter / Space
• Есть ли горячие клавиши
• Можно ли вызвать эквивалент правого щелчка с клавиатуры

Неброско, но если это ломается, UX B2B-приложения сильно страдает.

7.2 Увеличение шрифта, контрастные темы, доступность

В Windows-приложениях простое следование системным размеру шрифта и контрасту заметно стабилизирует UX.

Руководство Microsoft рекомендует коэффициент контраста видимого текста не менее 4.5:1 и требует, чтобы при увеличении текста элементы и контейнеры тоже меняли размер и перестраивались.⁵⁶

Для контрастных тем дополнительно рекомендуется:

• не жёстко прописывать цвета в коде
• использовать ресурсы SystemColor / Brush
• проверять на четырёх контрастных темах

⁷

Часто ломается вот что:

• подписи, рассчитанные на фиксированную ширину
• высота кнопок, зафиксированная в пикселях
• проектирование, передающее смысл только цветом
• UI с собственной отрисовкой, не следующий теме

Это стоит рассматривать не столько как «соответствие доступности», сколько как основу для Windows UI, который долго не ломается.

flowchart TB
    accTitle: Основа, которая выдерживает увеличение и темы
    accDescr: Рисунок показывает, что фиксированная ширина подписи, фиксированная высота в пикселях, смысл только цветом и собственная отрисовка без следования теме легко ломаются; цвета не прописывают жёстко, используют ресурсы и проверяют на четырёх контрастных темах — это основа долговечного Windows UI.
    y1["Фиксированная ширина подписи, высота в пикселях"] --> y3["Ломается при увеличении и смене темы"]
    y2["Смысл только цветом, собственная отрисовка"] --> y3
    y3 --> y4["Цвета не прописывать жёстко, использовать ресурсы"]
    y4 --> y5["Проверить на четырёх контрастных темах"]
    y5 -.-> y6["Основа UI, который долго не ломается"]

Рис. 19: Следование увеличению текста и контрастным темам — это основа UI.

7.3 Не злоупотреблять диалогами

Диалоги удобны, но при чрезмерном использовании становятся врагом работы.

В руководстве Windows по диалогам они определяются как модальный UI для случаев, требующих уведомления, подтверждения или дополнительного ввода, и рекомендуется включать хотя бы одну безопасную, неразрушающую операцию (Close, Cancel и т. п.). Кроме того, текст кнопок лучше делать конкретным ответом.¹⁰

Важно не превращать в диалог всё подряд.

В частности:

• ошибки ввода на уровне поля
• форматные ошибки, исправимые на месте
• временные уведомления

лучше по возможности выносить во встроенное отображение.¹⁰

7.4 У важных команд — несколько путей

В проектировании команд Windows подчёркивается, что важные команды должны быть доступны через разные способы ввода и разные поверхности UI.¹²¹³

На практике это работает очень хорошо.

Например, для «Удалить» несколько путей вроде:

• панель инструментов
• контекстное меню
• клавиша Delete
• при необходимости свайп

делают работу стабильно удобной.

И наоборот, проектирование вида:

• появляется у правого края только при наведении
• доступно только по правому щелчку
• никогда не достижимо с клавиатуры

резко слабеет при смене способа ввода.

7.5 Проверять инструментами

Доступность быстрее проверить инструментами, чем полагаться на мысль «наверное, всё в порядке».

Руководство Microsoft по тестированию доступности рассказывает о Live Inspect, FastPass и Troubleshooting с помощью Accessibility Insights for Windows, а также о том, что с помощью Inspect из SDK можно проверить атрибуты 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 и больше на то, что реально сильно окупается в практике настольной Windows.

UX определяется не только «приятной кнопкой, которую хочется нажать», но и возможностью вернуться после сбоя.

Например:

• Undo / Redo
• автосохранение
• сохранение состояния незавершённой правки
• восстановление фильтров / сортировки / ширины столбцов
• пауза и возобновление
• прогресс и отмена для длительных операций

влияют на UX гораздо сильнее, чем внешний вид.

Особенно в B2B и в инструментах для специалистов стресс от повторного выполнения работы напрямую превращается в плохой 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 Убеждённость, что «раз B2B, значит нужно сделать плотнее»

Это верно лишь наполовину.

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

Ориентация не на ярлык B2B, а на уровень подготовки, способ ввода и среду использования реже приводит к промаху.

8.2 Чрезмерное скрытие функций из-за того, что «это B2C»

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

Если склонить всё в сторону «показать проще», начинается:

• часто используемые действия становятся далёкими
• приходится каждый раз рыться в меню
• бесконечное переключение экранов

тихий ад.

flowchart TB
    accTitle: Две ловушки веры в ярлык
    accDescr: Рисунок показывает две ловушки: «раз B2B, значит плотнее» промахивается на цеховом терминале, а «раз B2C, значит прятать» отдаляет частые действия опытных пользователей.
    ca1["Раз B2B — значит плотнее"] --> ca2["На цеховом терминале плотность — враг"]
    ca3["Раз B2C — значит прятать"] --> ca4["У опытных частые действия оказываются далеко"]
    ca2 --> ca5["Смотрят подготовку, способ ввода, среду"]
    ca4 --> ca5

Рис. 22: Убеждения «B2B — плотность» и «B2C — простота» промахиваются в противоположную сторону.

8.3 Создание взаимодействий, зависящих от hover

У сенсорного ввода нет hover. Более того, UI, появляющийся только для указателя, обычно плохо сочетается со вспомогательными технологиями.⁴¹²

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

До: действия появляются у правого края только на строке под hover
  Документ 1001   2026-03-18   необработан                        <- ничего не видно
  Документ 1002   2026-03-18   необработан        [ Правка ][ Удалить ] <- только строка под мышью

После: всегда видно + путей больше
  Документ 1001   2026-03-18   необработан        [ Правка ][ Удалить ]
  Документ 1002   2026-03-18   необработан        [ Правка ][ Удалить ]
     правый щелчок  -> Правка / Удалить
     клавиатура     -> Enter открывает правку, Delete удаляет

8.4 Передача состояния только цветом

Особенно часто встречается на экранах мониторинга: передавать смысл только красным / жёлтым / зелёным опасно.

Сочетание текста, значков, времени, количества и описания снижает и пропуски, и ошибки распознавания.¹¹

8.5 Превращение всех ошибок проверки в диалоги

Часто встречается в системах офисного ввода. Если диалог появляется при каждом вводе, рабочий ритм полностью ломается.

Ошибки, замкнутые в контексте, естественнее показывать прямо на экране, на месте.¹⁰

До: модальное окно на каждое поле
  Индекс    [ 1234        ]        +------------------------------+
  Адрес     [             ]        | Формат индекса неверный
                                   |                       [ OK ]
                                   +------------------------------

После: сообщение на месте
  Индекс    [ 1234        ]
            ! Введите 7 цифр. Пример: 1234567
  Адрес     [             ]

8.6 Компоновка с фиксированным размером

В среде разработки при отображении 100% всё может выглядеть аккуратно, но легко ломается при:

• увеличении текста
• высоком DPI
• контрастных темах
• локализации

⁶⁷

До: подпись фиксированной ширины + кнопка фиксированной высоты. При увеличении текста
  [ Отгрузка... ][ 2026-03-1  ]      <- подпись обрезана, значение вылезает
  [ Ре ][ От ]                        <- текст кнопки обрезан сверху и снизу

После: макет растёт вместе с содержимым
  Плановая дата отгрузки
  [ 2026-03-18              ]
  [ Зарегистрировать ]   [ Отмена ]   <- высоту задают содержимое + поле

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

8.7 Создание слишком большого числа собственных элементов

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

Они берут на себя заботу о:

• фокусе
• клавиатуре
• следовании теме
• UI Automation
• связи со вспомогательными технологиями

Поэтому создание всего самостоятельно без веской причины накапливает долг по UX и доступности.⁸³

9. Восемь вопросов, которые стоит решить перед началом работы

Напоследок — восемь вопросов, удобных для начала ревью проектирования.

Если заранее ответить на эти восемь вопросов, дальше естественным образом определяется:

• нужна ли более неглубокая навигация
• подходит ли список + детали
• стоит ли активно использовать горячие клавиши
• где применять диалоги
• насколько допускать настраиваемость

flowchart TB
    accTitle: Что складывается из восьми вопросов
    accDescr: Рисунок показывает, что если восемь вопросов задать до начала работы, естественным образом складываются глубина навигации, устройство списка и деталей, насыщенность горячими клавишами, место диалогов и границы настраиваемости.
    da1["Ответить на восемь вопросов до начала"] --> da2["Глубина навигации и устройство списка с деталями"]
    da1 --> da3["Насыщенность горячими клавишами"]
    da1 --> da4["Границы диалогов и настраиваемости"]
    da2 --> da5["Складывается естественным образом"]
    da3 --> da5
    da4 --> da5

Рис. 23: Если восемь вопросов задать раньше, основные проектные выборы складываются сами.

10. Итог

В UX-проектировании Windows-приложения важно решить не «красиво ли это», а прежде всего то, сможет ли конкретный человек, в конкретном месте, конкретным способом ввода пользоваться приложением без остановок.

flowchart TB
    accTitle: Что решить раньше, чем «красиво ли»
    accDescr: Рисунок показывает, что в UX важнее не «красиво ли», а сможет ли этот человек в этом месте этим способом ввода пользоваться без остановок, и что UX — не украшение, а договор об управлении.
    ea1["Этот человек"] --> ea2["в этом месте"]
    ea2 --> ea3["этим способом ввода"]
    ea3 --> ea4["сможет пользоваться без остановок?"]
    ea4 -.-> ea5["UX — не украшение, а договор об управлении"]

Рис. 24: Раньше «красиво ли» решают, сможет ли человек в этом месте этим вводом работать без остановок.

Если подытожить грубо, получается так.

• B2C ставит выше понимание при первом знакомстве и чувство спокойствия
• Офисный B2B ставит выше устойчивую эффективность и поддержку клавиатуры
• Мониторинг B2B ставит выше предотвращение пропусков и безопасность операций
• Цеховые терминалы B2B ставят выше крупные объекты управления и короткие сценарии
• Инструменты для специалистов ставят выше плотность, горячие клавиши и настраиваемость
• Резидентные утилиты ставят выше ненавязчивость

А вне зависимости от сценария использования общими остаются следующие шесть пунктов.

1. Прямолинейное использование стандартных элементов
2. Возможность завершить основные операции с клавиатуры
3. Отсутствие тупиков при работе с сенсором и вспомогательными технологиями
4. Отсутствие поломок при увеличении текста и контрастных темах
5. Несколько путей к важным командам
6. Возможность вернуться после сбоя

UX — это не украшение, а договор об управлении приложением. Чем лучше этот договор согласован с пользователем, средой и способом ввода, тем незаметнее, но тем сильнее становится удобство использования Windows-приложения.

11. Справочные материалы

Похожие статьи

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

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Должен ли B2B-бизнес-приложение быть плотным UI, набитым информацией?

Это верно лишь наполовину. В офисном вводе, которым каждый день пользуются опытные сотрудники, высокая плотность, обзор списков и возможность сделать всё с клавиатуры действительно держат устойчивую эффективность. Но на цеховых терминалах — завод, склад, ресепшен — и в UI оборудования плотность, наоборот, враг: выше должны стоять крупные объекты управления, короткие сценарии и ясность. Смотреть лучше не на ярлык «B2B», а на подготовку пользователя, способ ввода и среду использования. И наоборот, даже в B2C для инструментов продвинутого уровня — правка изображений, инвестиционный анализ — выше простоты оказываются плотность информации, горячие клавиши и настраиваемость.

Что нужно решить в первую очередь при UX-проектировании Windows-приложения?

Одного деления на B2C и B2B недостаточно — сначала стоит сформулировать пять вопросов. Кто пользуется (новичок, опытный пользователь, смешанная аудитория), где используется (за столом, на площадке, на улице, на ресепшене), чем управляют (клавиатура, мышь, сенсор, сканер, вспомогательные технологии), насколько часто используют (в основном при первом знакомстве, каждый день, весь день) и какова цена ошибки (незначительная, серьёзная, опасная, подлежащая аудиту). Когда эти пять пунктов ясны, легче расставить приоритеты по плотности UI, навигации, горячим клавишам, диалогам подтверждения и настраиваемости.

Как выбирать паттерн навигации?

Единого навигационного решения, которое подходило бы всем приложениям, нет — принципы это согласованность, простота и ясность. Ориентир такой: верхняя навигация — когда все пункты нужно показать на экране сразу; левая — когда пунктов верхнего уровня много; список/детали — для ввода данных, где часто переключаются между элементами, просматривая или обновляя детали; вкладки — когда несколько документов нужно динамически открывать и закрывать; «хлебные крошки» — когда при глубокой иерархии легко потерять текущее место. Навигация — не вопрос визуальных предпочтений, а отражение структуры информации и структуры работы.

До какой степени показывать диалоги подтверждения?

Важно не превращать в диалог вообще всё. Ошибки ввода на уровне поля и форматные ошибки, которые можно исправить на месте, естественнее выносить не в диалог, а прямо на экран. По-настоящему подтверждения требуют скорее необратимые операции: остановить, удалить, отключить, перезаписать. Если диалог всё же показывают, минимум три правила: в первой строке ясно сказать, что произойдёт; текст кнопок сделать конкретным («Удалить», «Остановить»), а не «OK» / «Да»; обязательно дать безопасную неразрушающую кнопку.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.