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

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

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

• Насколько далеко можно продвинуться, пользуясь только клавиатурой
• Рассчитано ли приложение на мышь или на тач
• Используется ли оно часами напролёт или лишь изредка по несколько минут
• Это мониторинг, ввод данных или терминал на месте
• Что ломается при ошибке пользователя
• Выдерживает ли приложение увеличение шрифта, контрастные темы и вспомогательные технологии

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

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

Например, даже в рамках B2B:

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

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

И наоборот, даже в рамках B2C:

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

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

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

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

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

Если сформулировать грубо, но заранее, получится так.

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

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

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

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

2. B2C / B2B - это точка входа, но не сам ответ

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

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

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

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

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

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

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

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

Сначала приведём таблицу, наиболее удобную для практики.

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

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

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

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

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

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

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

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

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

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

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

4.2 Офисный ввод / бэк-офис B2B

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• чётко описать происходящее в первой же строке;
• сделать текст кнопок конкретным - «Удалить» / «Остановить» / «Отключить» вместо «OK» / «Да»;
• обязательно предусмотреть безопасный вариант.

¹⁰

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

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

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

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

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

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

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

⁴

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Таблица решений по устройствам ввода и проектированию команд

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

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

В удобном для практики виде это выглядит так.

Особенно важны такие моменты, связанные с клавиатурой. ³⁹

• Доступ ко всей функциональности только с клавиатуры
• Порядок Tab заметно не расходится с визуальным порядком
• Элементы, которые должны реагировать на Enter / Space, реагируют
• Есть горячие клавиши для важных функций
• Для часто используемых действий предусмотрены клавиши доступа и акселераторы

У тач-ввода есть такие особенности. ⁴

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

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

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

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

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, который долго не ломается.

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;
• прохождение основных сценариев только клавиатурой;
• проверку увеличения текста и контрастных тем.

Это заметно сокращает переделки.

7.6 Заложить восстанавливаемость

Это меньше похоже на однострочный пункт чек-листа Microsoft и больше на то, что реально сильно окупается в практике настольной Windows.

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

Например:

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

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

Особенно в B2B и в инструментах для профессионалов стресс от повторного выполнения работы напрямую превращается в плохой UX.

8. Частые ошибки проектирования

8.1 Убеждённость, что «раз B2B, значит нужно сделать плотнее»

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

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

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

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

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

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

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

тихий ад.

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

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

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

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

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

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

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

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

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

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

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

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

⁶⁷

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

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

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

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

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

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

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

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

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

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

10. Итог

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

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

• 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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.