Исследователи Markswebb больше 15 лет занимаются поиском, описанием и исправлением UX-проблем в цифровых сервисах. Мы видели тысячи интерфейсов и наконец пришли к тому, чтобы оформить накопленные знания в классификацию и базу знаний для всех, кто занимается созданием и развитием мобильных приложений, веб-версий, сайтов и личных кабинетов.
На этом лендинге мы собрали все артефакты проекта, которые помогут прокачать навык поиска и описания UX-проблем, чтобы полученные в результате исследований инсайты приводили к реальным, полезным для людей и бизнеса изменениям.
Использование классификации Markswebb других документов проекта UX Problems Guide поможет UX-исследователям, дизайнерам, специалистам по клиентскому опыту и продуктовым командам докапываться до сути проблем в интерфейсах и благодаря этому находить их лучшие решения. А также даст источник вдохновения в качестве примеров, которые мы собрали в 80+ цифровых сервисах по сотням пользовательских сценариев. Если объединить визуализации всех найденных проблем и решений, получится видео длиной более 24 часов — такой объем информации мы проанализировали, чтобы выбрать только самое важное и ценное.
Классификация расширяет количество параметров, по которым UX-исследователи или продакт-менеджеры могут оценивать интерфейсное решение. Каждый новый изученный класс проблем дает возможность увидеть то, что раньше осталось бы незамеченным и неисправленным.
В дополнение к классификации мы предлагаем изучить статистический отчет по частотности UX-проблем в цифровых сервисах пяти индустрий и в самостоятельных аудитах руководствоваться чек-листами Markswebb.
Это база знаний, в которой собраны реальные примеры UX-проблем из десятков цифровых сервисов в разных странах. Каждая практика проиллюстрирована визуализацией в виде скриншота или скринкаста, сопровождается текстовым описанием на английском языке и реализацией из другого сервиса, где обозначенная UX-проблема отсутствует.
Перейти в NotionСтатистический анализ 363 UX-проблем из 89 приложений и сайтов показывает отраслевые паттерны и индустриальные особенности. Команды могут сравнивать показатели с конкурентами, находить быстрые улучшения и планировать доработки на основе данных, а не мнений.
Загрузить PDFФинансовые сервисы, тревел, e-commerce, образование, контентные платформы: 5 индустриально-специфичных чек-листов с ключевыми вопросами для оценки цифрового опыта. Простой и практичный инструмент для оценки продукта с учетом особенностей индустрии.
Загрузить PDFКлассификация основана на анализе тысяч интерфейсов за годы работы UX-исследователей Markswebb. В качестве примеров мы выбрали 89 сервисов из 7 индустрий, включая финтех, фудтех, e-commerce, транспорт, образование, аренду и государственные платформы. Мы исключили глобальные бигтехи, небольшие локальные сервисы и индустрию игр. Игры не рассматривались, так как их ключевая цель — длительное вовлечение — принципиально отличается от сервисов, ориентированных на эффективность.
UX-проблема — это любая ситуация, которая вызывает у пользователя затруднения или путаницу и мешает ему уверенно и эффективно выполнять задачи. Дело не только в дефектах дизайна — важно то, как они влияют на пользователя.
Это отличается от маркетинговых проблем — например, нерелевантных предложений, неправильно подобранной аудитории или неясной ценности.
Важно описывать проблему через реальные ощущения и опыт пользователя, а не через поведение интерфейса. Например: «Кнопка слишком маленькая» или «В карточке товара мало фотографий» — это не UX-проблемы, потому что они никак не связаны с задачами и восприятием человека.
Зато формулировка «Пользователь не замечает кнопку подтверждения платежа из-за её маленького размера и слабого визуального выделения, из-за чего тратит больше времени на поиск нужного действия» — это уже UX-проблема.
Не менее важно обосновывать, почему проблема действительно критична. Для этого стоит задать вопросы:
Ответы помогут правильно сформулировать и доказать значимость проблемы.
После того как проблемы определены, их необходимо расставить по степени критичности. Этот параметр отражает степень влияния на пользовательский опыт: чем проблема критичнее, тем выше риск, что пользователи будут испытывать раздражение, не смогут достичь цели и перестанут использовать сервис. Корректная оценка помогает командам сосредоточиться на самом важном.
+ десятки других брендов, которые создают прорывные цифровые сервисы
Мы ответим вам в самое ближайшее время.
Это самый распространенный тип UX-проблем среди изученных нами сервисов — он составляет 18% от всех выявленных проблем. Класс 1 описывает фундаментальное несоответствие между сервисом и задачей пользователя. Важно четко отличать его от классов 2 и 3, которые связаны с навигационными трудностями: цель пользователя достижима, но путь к ней оказывается неочевидным или слишком длинным.
1.1. В сервисе изначально отсутствует необходимая функция или информация.
Пользователь хочет выполнить задачу, но система не предоставляет способа это сделать. Если задача выходит за рамки ожидаемых возможностей сервиса, это не проблема UX, а вопрос продуктовой стратегии или позиционирования. Пример — запрос на совершение криптовалютных сделок в банковском приложении, которое не поддерживает такие функции.
Сервис считается адаптированным под задачи пользователей, когда они могут достичь своих целей от начала до конца, в реальных условиях и ограничениях, без необходимости прибегать к обходным путям или внешним каналам.
Подкласс 1.1. охватывает ситуации, когда пользователь пытается выполнить задачу, явно относящуюся к сфере и типу продукта, но такой возможности не предусмотрено — хотя в цифровых сервисах конкурентов она есть, а также решается офлайн.
Интерфейсы с такой проблемой отражают чрезмерно узкое понимание реальных сценариев использования: они поддерживают только «идеальный путь», но не учитывают полный спектр контекстов, в которых действуют пользователи.
В приложении NJ Transit пользователям также предлагается похожая кнопка «Расписание», но в отличие от Metrolink приложение не перенаправляет их на внешние источники. Пользователи могут легко просматривать расписание поездов прямо в приложении, что обеспечивает целостность цифрового опыта.
1.2. Технические ошибки мешают завершению задачи.
Неработающий элемент или действие приводит к тому же результату для пользователя, что и отсутствующий — задачу невозможно выполнить. Этот подкласс описывает ситуации, когда пользователь совершает корректное и ожидаемое действие — например, нажимает кнопку или отправляет форму, — но ничего не происходит из-за сбоя на стороне бэкенда или функционала.
В отличие от когнитивных проблем, которые возникают из-за восприятия интерфейса пользователем, здесь источник — технические ошибки системы.
Такого рода проблемы чаще всего встречаются в сервисах, основанных на данных и динамическом контенте, где критична работа в реальном времени: образовательные платформы, системы бронирования, каталоги в электронной торговле. В таких сервисах контент постоянно подгружается, и любой технический сбой или задержка ответа сервера приводит к «зависанию» интерфейса.
Пользователи ощущают себя в тупике, особенно если система не показывает сообщение об ошибке.
После добавления блюд в корзину пользователь переходит на страницу оформления заказа, где система предлагает выбрать способ оплаты. Однако кнопка выбора способа оплаты не отвечает на взаимодействие, и пользователь не понимает, как завершить заказ. Отсутствие реакции интерфейса мешает успешно завершить задачу.
Пользователь всё же может выполнить задачу, перейдя в раздел профиля и добавив способ оплаты там, но это требует дополнительных усилий и поиска альтернативного решения.
В приложении Wolt пользователи без препятствий переходят на страницу оформления заказа, где вся необходимая информация для завершения покупки удобно собрана на одном экране. В том числе — выбор предпочтительного способа оплаты. Пользователь может добавить новую карту в рамках единого и цельного пользовательского сценария.
Skillshare (Включить субтитры в полноэкранном режиме)
Domestika (Найти курсы по маркетингу с английскими или испанскими субтитрами)
1.3. Задача не поддерживается, хотя её можно выполнить с помощью неподходящей функции.
Этот подкласс описывает ситуации, когда задача пользователя не решается непосредственно в сервисе, но он предлагает взамен обходные решения. Успеха обычно достигают лишь самые опытные пользователи, прибегая к методу проб и ошибок.
Такой тип UX-проблем не связан с навигационными трудностями, его причина — отсутствие функциональных путей или поддержки задачи пользователя. Подобные ситуации характерны для сервисов, где пользовательские сценарии слишком сильно ориентированы на «идеальные» способы использования.
В банковском приложении отсутствует возможность скачать квитанцию об оплате или поделиться ей. Пользователь может достичь цели только сделав скриншот. В результате пользователи ощущают отсутствие поддержки, когда их потребности хоть немного выходят за рамки заранее заданных сценариев:
— “Я будто разгадывал головоломку, а не пользовался сервисом.”
— “Кажется, что я взламываю систему, лишь бы выполнить самые базовые действия.”

На сайте Uber Eats пользователи могут применять разные виды сортировки каталога, включая сортировку по времени доставки. Такое UX-решение позволяет легко находить самый быстрый вариант и выбирать ресторан, который соответствует временным ограничениям.

Glovo (Изменить данные адреса доставки).
1.4. Сервис требует от пользователя данные или условия, которые он не может предоставить или выполнить в данный момент.
Этот подкласс охватывает ситуации, когда сервис блокирует выполнение задачи, требуя от пользователя данные или условия, которыми он в данный момент не располагает или не может их выполнить. Подобные требования могут быть технически или процедурными (например, ради безопасности) — но с точки зрения UX они становятся проблемой, когда превращаются в блок без возможности альтернативного пути.
Здесь мы рассматриваем только требования, которых можно было бы избежать или реализовать иначе, особенно если они не обязательны для всех пользователей, но сервис всё равно их навязывает. Этот подкласс встречается редко и характерен в основном для регулируемых отраслей — таких как банковские услуги, государственные сервисы или системы идентификации. Чаще всего он отражает избыточно «перестраховочный» дизайн, когда система ставит во главу угла соответствие нормам и минимизацию рисков, а не доступность для человека.
Такой дизайн создаёт конфликт между безопасностью и доступностью: желание защитить сервис и его пользователей на практике блокирует действия пользователей в критические моменты.



При входе с использованием Apple ID и пароля на новом устройстве система также запрашивает ввод кода подтверждения, отправленного на другое устройство, где пользователь уже авторизован. Однако Apple также предлагает альтернативный вариант — «Не получили код?». С его помощью пользователь может запросить SMS для подтверждения. Это гарантирует, что даже если у человека нет доступа к другому устройству, но SIM-карта установлена в новом телефоне, он сможет без проблем завершить процесс входа.






2.1. Сервис не предлагает очевидного пути к нужной функции или информации
Этот подкласс описывает ситуации, когда пользователи не могут найти функцию или информацию, потому что нет очевидного или интуитивно понятного пути к ней. Чаще всего это происходит в случаях, когда для задачи не существует устоявшегося отраслевого UI-паттерна.
Проблема не в том, что функция расположена «не там», а в том, что пользователи не знают, с чего начать поиск: сервис не выводит нужную опцию на видное место с помощью корректных подписей, иерархии навигации или контекстных подсказок.
Такая проблема особенно часто встречается в финансовых сервисах, приложениях для путешествий и транспорта, в онлайн-магазинах и в сервисах объявлений.
Приложение Omio обеспечивает интуитивно понятную и удобную навигацию через нижнюю панель меню. Чётко различимый значок с изображением человека обозначает раздел «Профиль», что позволяет пользователям легко находить аккаунт и входить в него.
Меню организовано логично, функции разделены на три понятные зоны:
Такая структура сводит путаницу к минимуму и обеспечивает бесшовный пользовательский опыт, поскольку каждый раздел понятно называется и легко доступен. Продуманная навигация повышает удовлетворённость пользователей, позволяя быстро и удобно получать доступ к ключевым функциям.



2.2. Необходимая функция или информация отсутствует в ожидаемом месте
В отличие от класса 2.1, этот подкласс описывает ситуации, когда пользователь знает, где ожидает найти функцию или информацию, но интерфейс нарушает привычную логику или отраслевые стандарты, и нужный элемент отсутствует в том месте, где его естественно искать. Эти ожидания формируются на основе распространённых UI-паттернов, опыта работы с аналогичными сервисами или устоявшихся норм внутри домена (например, кнопка выхода в настройках профиля, фильтры над результатами поиска).
Такая проблема вызывает у пользователя чувство дезориентации: он уверенно ищет в привычном месте, но не находит нужного. В результате часть пользователей может отказаться от выполнения задачи, предположить, что функция вообще отсутствует, или предпринять неверные действия.
Источник проблемы — отклонение от общепринятых UI-паттернов. Чаще всего она встречается в финансовых приложениях, e-commerce, сервисах для оплаты услуг и образовательных платформах, особенно при работе с профилем, управлением аккаунтом или транзакциями.
В приложении DoorDash пользователи могут без усилий получить доступ к корзине в любой момент. Когда блюдо добавлено и пользователь покидает страницу ресторана, корзина заметно отображается внизу главного экрана. Кроме того, в правом верхнем углу всегда есть фиксированная точка доступа к корзине. Такое UX-решение обеспечивает лёгкий доступ к корзине и позволяет без лишних шагов перейти к оформлению заказа.
Zoom (Изменить язык в десктопном приложении Zoom для macOS).
Telegram (Выйти из аккаунта в Telegram).
2.3. Приоритеты в интерфейсе расставлены неверно: второстепенные элементы выделены, а основные остаются незаметными.
Этот подкласс охватывает ситуации, когда визуальная иерархия интерфейса не отражает реальные приоритеты пользователя. Он заходит в сервис с чёткой целью — например, выбрать подходящий курс, проверить детали рейса или подтвердить содержимое корзины, — но интерфейс перенаправляет внимание на второстепенные элементы, в то время как основной контент выделен недостаточно и может быть не заметен.
Такие несоответствия обычно возникают из-за неудачных решений в верстке, чрезмерного продвижения функций, не относящихся к основной задаче, или отсутствия визуальных подсказок, которые должны направлять пользователя к главному действию или информации. В результате пользователю приходится тратить дополнительное время на поиск и интерпретацию интерфейса.
Эта проблема часто встречается в сервисах, связанных с выбором, подтверждением форм или действий, в цифровых сервисах на рынке образования, путешествий, e-commerce, финансов и коммуникаций.
Воздействие особенно раздражает, когда пользователь выполняет критически важные действия — бронирование, покупку или подтверждение данных, — именно в эти моменты особенно ожидаются ясность и скорость.
В приложении Uber Eats пользователю наглядно показывается содержимое корзины перед переходом к оформлению заказа. Пользователь может удобно сделать ревью и внести необходимые изменения перед подтверждением. Это снижает риск ошибок, даёт пользователю уверенность в покупке и повышает общий уровень цифрового опыта.
2.4. Названия разделов меню или ссылок на функции не отражают их назначение достаточно ясно.
Этот подкласс описывает ситуации, когда подписи или заголовки, используемые в меню и навигационных ссылках, не дают понять, к какой функции или какому контенту они ведут, из-за чего пользователям сложнее найти то, что им нужно. В отличие от проблем, связанных с неясными инструкциями или терминологией в процессе выполнения задачи (подклассы 11.1–11.3), здесь речь идёт о навигационном понимании — способности находить функции или информацию.
Проблема возникает, когда:
Такое затруднение часто встречается в e-commerce, тревел- и медиа-платформах, где переход к ключевым разделам (избранное, поддержка, личные настройки) усложняется из-за неясных или нестандартных названий.
В приложении Spotify есть единый раздел «Аккаунт», где собрана вся информация, связанная с аккаунтом. Нажав на этот раздел, пользователь может легко получить доступ к данным и управлять ими, включая привязанные адреса электронной почты. Такой централизованный подход упрощает навигацию, позволяет быстро находить и обновлять настройки и повышает общее удобство использования платформы.
3.1. Сервис запрашивает у пользователя лишнюю информацию в процессе выполнения операций.
Эта проблема возникает, когда сервис просит пользователя снова вводить информацию, которую он уже указывал или которую система могла бы определить автоматически. В такие моменты у человека возникает ощущение, что интерфейс «забывает» и перекладывает лишнюю работу на него:
–«Разве я это уже не указывал?»Обычно такие ситуации встречаются при регистрации, онбординге или повторных сценариях использования, когда собранные ранее данные не применяются на следующих этапах. Например, пользователь указывает адрес доставки при регистрации, а затем снова вводит его при оформлении заказа. В основе проблемы — неспособность системы эффективно использовать собственную память и персонализацию.
К этому же типу относятся случаи, когда сервис требует информацию, которую можно извлечь из метаданных. Например, выбор типа карты (Visa или MasterCard) при вводе номера избыточен: система способна определить его автоматически.
Даже если задача завершается, у пользователя остаётся чувство нерациональности: интерфейс не помогает, а мешает, игнорируя уже имеющиеся данные и усилия.
В приложении Octopus пользователи могут получить доступ к разделу счетов без повторного ввода учётных данных. Сервис не требует дополнительных логинов для входа в этот раздел. Такой удобный дизайн позволяет мгновенно просматривать и оплачивать счета, делая процесс простым и комфортным.
3.2. Для доступа к нужной функции или информации требуется слишком много навигационных действий (кликов, прокруток).
Проблема возникает в длинных сценариях с множеством шагов или на перегруженных экранах с большим количеством функций и информации. Она охватывает как внутриэкранную навигацию (например, кнопку «Далее» нужно искать в самом низу), так и межэкранные переходы, когда для доступа к нужной функции требуется слишком много кликов.
Как отличить лишние действия от необходимых?
Они считаются избыточными, если носят чисто навигационный характер, могли бы быть сокращены или убраны и при этом нарушают ментальную модель пользователя о том, как «должно работать» приложение.
Важно: этот подкласс не описывает ситуации, когда пользователь не знает, где находится функция (как в классе 2); здесь проблема именно в навигации, а не в поиске.
Чаще всего такие ошибки встречаются в e-commerce и тревел-сервисах, где пользователям приходится проходить много шагов — выбирать рейсы, сравнивать товары, оформлять заказ. Они также характерны для разделов входа и поддержки, где возврат на главный экран требует чрезмерного количества шагов назад.
Типичные причины:
Такие паттерны замедляют сценарий и повышают усилия, необходимые для выполнения задачи.
В приложении WizzAir процесс бронирования билета организован максимально удобно благодаря оптимизированной навигации. Как только пользователь выбирает тариф, внизу экрана появляется кнопка «Далее», которая остаётся видимой при прокрутке. Это позволяет продолжить бронирование без необходимости переходить в самый низ формы. Такой продуманный дизайн повышает эффективность и обеспечивает более плавный пользовательский опыт.
Uber — пользователь хочет изучить политику сервиса по валюте, но нужный раздел доступен только через слишком длинный путь навигации.
3.3. Поля ввода данных и способы ввода не обеспечивают наиболее удобный и быстрый способ ввода информации.
Этот подкласс чаще всего относится к формам с полями ввода. Он встречается в сценариях входа, регистрации, бронирования и оплаты. Проблема возникает, когда интерфейс нарушает принцип минимальных усилий — система не предлагает удобные, привычные и контекстно подходящие способы ввода информации.
Типичные проявления:
Этот тип проблем особенно часто встречается в тревел-сервисах, e-commerce, финансовых и сервисах доставки, где нужно вводить много персональных и логистических данных: имя, адрес, платёжную информацию.
Неудобный ввод увеличивает время и когнитивную нагрузку, ведёт к ошибкам и вызывает усталость пользователей.
Instagram задаёт отраслевой стандарт для загрузки фотографий, предлагая удобный и эффективный процесс. Пользователи могут загрузить до 10 фото за один раз, при этом появляется всплывающее уведомление с информацией об этом лимите, что обеспечивает прозрачность. В приложении есть встроенные инструменты редактирования, позволяющие вносить изменения без выхода из платформы. Кроме того, возможность выбрать конкретный альбом для загрузки упрощает навигацию и устраняет необходимость прокручивать всю галерею. Такое сочетание функций не только повышает удобство, но и экономит время, создавая для пользователя цельный и эффективный опыт.
Shopee. Пользователь хочет привязать новую карту к аккаунту.
Capital One. Пользователь накопил кэшбэк в своём аккаунте Capital One и хочет вывести его наличными с помощью формы для вывода.
3.4. Для получения результата или обратной связи от сервиса требуются лишние действия.
Этот подкласс описывает ситуации, когда пользователь совершает действие в сервисе и ожидает реакции или подтверждения, но система не предоставляет их автоматически. Самый очевидный пример — экраны успеха и подтверждения: после транзакции пользователь должен увидеть обновлённый баланс, а не вручную обновлять страницу.
Такие проблемы могут проявляться в любой части интерфейса, где человек ожидает автоматической реакции. Автоматизация здесь должна завершать действие логично и предсказуемо, не нарушая чувства контроля.
Простой пример: каталог, где фильтры обновляются только после нажатия кнопки «Применить», вместо того чтобы работать в реальном времени.
Если подкласс 3.2 связан с отсутствием шорткатов и избыточной навигацией, то 3.4 описывает именно проблемы с результатом: пользователь вынужден выполнять лишние действия, чтобы подтвердить завершение или понять статус своих действий.
Когда обратная связь отсутствует или приходит с задержкой, возникает неопределённость и недоверие. Пользователь не понимает, выполнено ли действие, стоит ли его повторить, и часто испытывает раздражение.
Пользователь начинает регистрацию в приложении, но у него под рукой нет номера социального страхования (SSN).
Когда пользователь возвращается через пару минут, система заставляет его заново вводить все данные. Приложение не сохраняет прогресс даже временно. Это вызывает раздражение, трату времени и повышает риск того, что пользователь вовсе откажется от завершения регистрации.
Такая ситуация демонстрирует неспособность системы хранить данные хотя бы в течение короткого времени (5–10 минут). В реальной жизни пользователи часто вынуждены отвлекаться, и повторный ввод одних и тех же данных воспринимается как серьёзное препятствие.
Скриншот






В приложении DKB процесс регистрации построен так, что данные сохраняются поэтапно. После ввода персональной информации на первом шаге пользователь создаёт логин — и может вернуться к заявке позже. Система прямо сообщает: «Вы можете прервать процесс в любой момент, введённые данные будут храниться шесть месяцев».
Это особенно важно, так как регистрация включает видео-идентификацию, требующую стабильной связи и документов под рукой. Пользователь может продолжить, когда будет готов, не начиная всё заново. Такой подход снижает раздражение и значительно повышает вероятность успешного завершения регистрации.



Just Eat. Пользователь хочет купить конкретный товар, например круассан, и быстро добавить его в корзину.
Craigslist. Пользователь хочет найти квартиру стоимостью до $2000, где разрешено проживание с кошками. В идеале — в Манхэттене, но также подойдут районы вроде Бруклина. Он хочет просмотреть все варианты до $2000 сразу по нескольким районам.
Этот класс встречается реже всего — всего 2% от всех выявленных проблем. Такая низкая частотность говорит о том, что большинство сервисов уже воспринимают производительность как приоритет. Но это также повышает ожидания: поскольку цифровые продукты в целом работают быстро, пользователи начинают воспринимать мгновенную реакцию и быструю загрузку как норму. Поэтому даже небольшие задержки бросаются в глаза и вызывают раздражение.
4.1. Сервис (или его отдельные части) работает медленно или слишком долго загружается.
Этот подкласс описывает ситуации, когда система или отдельные элементы интерфейса отвечают дольше, чем ожидает пользователь. Ожидания формируются на основе опыта в других сервисах: если повсюду экраны загружаются мгновенно, пользователи ждут того же и от вас.
Типичные проявления:
Любая из этих ситуаций ломает поток действий, заставляет ждать без объяснений и вызывает раздражение.
Где это чаще встречается
В приложении Venmo, когда пользователь получает запрос на перевод, он отображается в виде баннера, который можно легко принять одним действием. Подтверждение транзакции происходит мгновенно, без задержек и зависаний. Venmo также показывает надёжное сообщение о подтверждении, которое информирует о том, что перевод успешно принят.
Robinhood — пользователь заполняет регистрационную форму. На этом шаге он выбирает отрасль занятости из выпадающего списка.
4.2. Пользователям приходится слишком долго ждать после выполнения действия, чтобы увидеть его результат или получить подтверждение об успешном завершении.
Этот подкласс описывает ситуации, когда система принимает ввод или запрос пользователя, но результат отображается с задержкой, превышающей разумные ожидания. Пользователь остаётся ждать подтверждения или изменения состояния и часто не понимает, зафиксировано ли его действие вообще.
Технически операция может быть выполнена успешно, но из-за отсутствия немедленной обратной связи возникает ощущение неопределённости и недоверия.
Такие задержки особенно часто встречаются в транзакционных сценариях: при оплате, подтверждении бронирований, обновлении данных аккаунта.
Wise демонстрирует отличный подход к повышению уверенности пользователей, мгновенно обновляя баланс счёта сразу после завершения перевода. Такой моментальный апдейт подтверждает успешность операции и устраняет любую неопределённость, создавая для пользователя прозрачный и бесшовный опыт.
5.1. Сервис показывает уведомление, из которого непонятно, что произошло и нужно ли выполнять какие-то действия.
Системные уведомления — это ключевой канал связи между сервисом и пользователем. Их задача — вовремя и понятно информировать о состоянии системы: будь то результат действия, системное событие или фоновый процесс. Важно также ясно указывать, нужны ли дополнительные шаги со стороны пользователя.
Проблема возникает, когда уведомление появляется, но человек не понимает, что оно значит, что его вызвало и нужно ли ему что-то делать. В таком случае цикл обратной связи между пользователем и системой нарушается.
Подобные сообщения чаще всего встречаются в сценариях с аккаунтом: вход, регистрация, смена тарифа.
Признаки проблемы: если хотя бы на один из вопросов ответ «нет», это указывает на подкласс 5.1.

Приложение Open Talk демонстрирует качественный подход к созданию понятных и дружелюбных сообщений об ошибках. Когда платёж не проходит, приложение показывает яркий красный крест — простой и универсально узнаваемый символ, мгновенно указывающий на проблему. Сопровождающий текст успокаивает пользователя, объясняя, что произойдёт, если деньги были ошибочно списаны: они будут автоматически возвращены в течение 3–4 рабочих дней. Дополнительно сообщение об ошибке содержит контакты службы поддержки, чтобы пользователь понимал, как эффективно решить проблему. Такой подход снижает тревожность и повышает доверие к сервису.

Shopee — пользователь совершает покупки в приложении Shopee.
Metrolink — пользователь установил приложение Metrolink на новое устройство и хочет войти в свой аккаунт.
5.2. Сервис запрашивает данные, которые непонятны или трудно доступны пользователю.
Этот подкласс описывает ситуации, когда интерфейс просит пользователя ввести данные, смысл которых неочевиден или которые сложно получить в данный момент в контексте выполняемой задачи.
Данные считаются «непонятными» не только тогда, когда их значение двусмысленно, но и когда они кажутся лишними для текущего шага или пользователь не понимает, как они повлияют на результат.
Такие ситуации возникают в процессе выполнения задачи — при бронировании, оформлении заказа или заполнении формы, когда пользователь уже вовлечён в поток. Это отличает подкласс 5.2 от класса 1.4, где отсутствие доступных или корректных данных мешает начать выполнение задачи вообще.
Подобные требования нарушают пользовательский поток и вызывают особое раздражение.
На экране входа есть кнопка «Log in/Register» и поле «User name». Это вызывает путаницу: регистрация ещё не пройдена, и непонятно, что именно нужно ввести. Подпись «User name» двусмысленна — не ясно, речь идёт об email или другом идентификаторе. Дополнительное замешательство вносит надпись под полем «Forgot login details?», которая использует термин «login», ещё больше запутывая назначение поля.
Ситуация усугубляется на этапе регистрации. Пользователь думает, что может придумать имя сам, но после ввода система сообщает, что в качестве имени нужно использовать email. Непоследовательность сбивает с толку и прерывает выполнение задачи.
Проблему усиливает и историческая несогласованность: до октября 2021 года можно было создавать логины, не привязанные к email. Теперь старые пользователи используют «традиционные» логины, а новые обязаны указывать email. Одно и то же поле обслуживает два разных формата без пояснений — это дезориентирует и усложняет процесс.
Такой неясный и непоследовательный дизайн подрывает пользовательский опыт, усложняя жизнь как новым, так и существующим пользователям. В итоге возникает раздражение и желание отказаться от регистрации или использования сервиса.
Bershka предлагает удобное решение для объединения процессов входа и регистрации в одном поле. На экране регистрации поле ввода чётко обозначено плейсхолдером «Email address», который подсказывает пользователю, что именно нужно ввести. Кнопка отправки называется «Continue» — универсальный вариант, подходящий как для входа, так и для регистрации. Такой подход помогает пользователям интуитивно понять, что сначала нужно ввести email и продолжить, будь то вход или создание нового аккаунта. Единая и понятная логика делает процесс простым и удобным как для новых, так и для постоянных пользователей.

5.3. Ошибки отображаются без чётких указаний, как их исправить.
Этот подкласс описывает ситуации, когда система сообщает пользователю об ошибке, но не объясняет, что её вызвало и как её исправить. Сообщение не содержит полезных и применимых деталей.
Как правило, оно не сообщает:
Такие проблемы особенно часто встречаются при входе, регистрации, оплате и оформлении заказа, а также на тревел- и образовательных платформах. В этих случаях пользователи чувствуют себя беспомощными и застревают в процессе:
— «Я всё время получаю ошибку, но нигде не написано, как её исправить».
Чаще всего такие сбои связаны с недостаточным вниманием к UX-райтингу. Исправление формулировок сообщений об ошибках требует небольших усилий, но помогает пользователю понять, что пошло не так и как действовать дальше, что напрямую повышает вероятность успешного завершения задачи.

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

5.4. Сервис не предлагает понятных следующих шагов для завершения задачи пользователя.
Этот подкласс описывает ситуации, когда во время выполнения задачи интерфейс не предлагает очевидного пути вперёд или назад. Задача сама по себе выполнима (в отличие от класса 1.1), но пользователь не видит, как продолжить или откатиться назад, либо нужные функции недоступны в текущем канале.
Часто такие ситуации связаны с ограничением доступа. Например, функция доступна только премиум-пользователям, но отображается как активная для всех — и при попытке использовать её ничего не происходит.
Другая типичная ситуация — невозможность завершить задачу в текущем канале. Например, в мобильном приложении есть раздел «Управление подпиской», но кнопки неактивны, потому что управлять подпиской можно только с десктопа.
Пользователи в таких случаях чувствуют себя в безвыходной ситуации или введёнными в заблуждение. У них возникают вопросы: «Что мне делать дальше?» или «Почему ничего не происходит?»
Где это встречается чаще всего
В Deezer пользователи видят вкладку Premium, похожую на ту, что есть у Spotify, где представлены различные варианты подписки. Однако, в отличие от Spotify, Deezer использует кликабельные баннеры для продвижения своих премиум-предложений, позволяя сразу перейти к покупке внутри приложения. Делая элементы интерфейса интерактивными, Deezer обеспечивает простой и удобный доступ к премиум-функциям.
SoundCloud — пользователь хочет скачать треки, но не получает подсказки, что это доступно только премиум-аккаунтам
BlaBlaCar — при регистрации пользователь доходит до шага создания пароля, но не получает очевидного способа продолжить.
6.1. Сервис делит задачи на этапы, но не показывает текущий шаг и количество оставшихся шагов.
Пользователь начинает выполнять задачу, состоящую из нескольких шагов — например, подтверждение личности, загрузка документов или заполнение формы. Он вводит данные и выполняет подзадачи, ожидая, что система будет сопровождать его в процессе. Однако интерфейс никак не показывает, на каком этапе находится пользователь и сколько шагов осталось.
Когда пользователи не знают, сколько ещё предстоит пройти или где именно они находятся, они часто прерывают задачу. Это подрывает чувство контроля и предсказуемости — ключевые принципы UX.
Типичные интерфейсные паттерны, провоцирующие такую проблему, — отсутствие индикатора прогресса или пошагового маркера.
Эта проблема особенно распространена в сервисах со сложными многоэтапными процессами, например:
На экране профиля пользователь видит кнопку «Опубликовать профиль» и нажимает её. После этого сайт предлагает ответить на несколько вопросов для завершения профиля. Однако в форме отсутствует индикатор прогресса, поэтому пользователь не понимает, насколько длинная форма и сколько вопросов предстоит пройти до конца. Это не позволяет спланировать время и делает процесс запутанным.
DKB (Deutsche Kreditbank) демонстрирует грамотный подход к онбордингу, предлагая видимый индикатор прогресса на протяжении всего процесса регистрации. Эта функция помогает пользователю легко отслеживать свой прогресс, чётко понимая, сколько шагов осталось и сколько времени потребуется для завершения. Такая прозрачность позволяет лучше планировать время, снижает неопределённость и улучшает общий пользовательский опыт.

6.2. Сервис не даёт понятной обратной связи после выполнения действия.
Этот подкласс описывает ситуации, когда система не сообщает пользователю, было ли действие успешно выполнено (в тех случаях, когда обратная связь ожидается и необходима для понимания статуса) или каков результат этого действия. После выполнения задачи — отправки формы, оплаты, загрузки файла или сохранения изменений — пользователь остаётся в сомнениях:
— «Всё прошло успешно или что-то пошло не так?»
— «Нужно ли ещё что-то сделать?»
Отсутствие подтверждения или обратной связи подрывает чувство контроля и вносит ненужные сомнения. Пользователь может повторно выполнить действие, бросить процесс или потратить время на обращение в поддержку.
Типичные признаки этой проблемы:
Эта проблема особенно распространена в формах, финансовых операциях и процессах регистрации, где пользователи особенно ожидают чёткой обратной связи.
Omio обеспечивает отличный пользовательский опыт при редактировании персональных данных. После сохранения изменений пользователь остаётся на той же странице и получает уведомление в верхней части экрана о том, что все данные успешно обновлены. Такой бесшовный процесс обеспечивает ясность и снижает вероятность путаницы.
MEGA — пользователь хочет загрузить видео со своего телефона в облачное хранилище.
6.3. Неясно, как вернуться на предыдущий шаг или возможно ли выйти из процесса, не потеряв прогресс.
Этот подкласс описывает ситуации, когда интерфейс не дает понять, можно ли безопасно вернуться назад, поставить процесс на паузу или выйти из него, не потеряв введённые данные или прогресс.
Такая проблема часто возникает в многошаговых задачах, например, при настройке аккаунта, заполнении формы, оформлении заказа или бронировании, особенно в сервисах, где пользователям важно иметь возможность пересмотреть или отредактировать ранее введённую информацию. Интерфейс не отвечает на ключевые вопросы:
— «Могу ли я вернуться на предыдущий шаг?»
— «Потеряю ли я всё, если закрою приложение или страницу?»
— «Сохранятся ли мои данные, если я выйду и вернусь позже?»
Когда такие возможности не обозначены явно, пользователи могут чувствовать себя в ловушке, опасаться ошибок или вовсе отказаться от продолжения процесса.
Причинами часто становятся отсутствие кнопки «Назад», отсутствующие опции «Сохранить», отсутствие подтверждающих диалогов или неочевидная навигация в полноэкранных модальных окнах.
На сайте Kyte пользователи могут без проблем редактировать детали поездки прямо на этапе оформления заказа, не теряя введённые данные, включая информацию о водителе. Хотя на сайте также нет кнопки «Назад», в ней нет необходимости — все выборы, сделанные на предыдущих шагах, можно изменить непосредственно на текущем экране. Такая гибкость обеспечивает бесшовный и эффективный опыт аренды автомобиля.
7.1. Сервис требует запоминать или вводить длинные/сложные значения.
Этот подкласс описывает ситуации, когда пользователь вынужден запоминать и вручную вводить длинные, или сложные данные, в которых легко ошибиться — например, идентификационные номера, коды или названия товаров.
Проблема может возникать как внутри самого сервиса (например, при заполнении формы регистрации), так и когда пользователю нужно перенести информацию из сервиса во внешний контекст (например, передать данные в поддержку через другой канал).
Распространённые паттерны этого подкласса:
Такие проблемы часто встречаются в финансовых сервисах и e-commerce.
Процесс входа должен быть простым и быстрым. Наилучший вариант — когда приложение предлагает несколько способов входа, так как некоторые из них могут быть недоступны в данный момент. Отличный пример показывает Uber, где пользователь может войти через email, Google или Apple Account, номер телефона и ранее созданные passkeys. Эти способы знакомы большинству пользователей, и сервис не требует непонятных данных, что делает такое решение оптимальной практикой.


Robinhood — пользователь хочет скопировать тикер или название акции, чтобы не вводить его вручную, задавая вопросы службе поддержки.
7.2. Сервис требует точного взаимодействия с определённой областью экрана, что требует от пользователя дополнительных усилий и повышенного внимания.
Этот подкласс описывает ситуации, когда пользователь вынужден нажимать, кликать, перетаскивать или взаимодействовать с очень маленькой или строго определённой областью экрана, чтобы выполнить действие. Такие проблемы особенно часто встречаются на мобильных устройствах, где точность нажатий ниже, а пользователи нередко действуют на ходу или одной рукой.
Пользователи ожидают, что смогут нажимать на элементы без необходимости тщательно прицеливаться или увеличивать экран. Когда интерфейс нарушает это ожидание, возрастает когнитивная и физическая нагрузка, а выполнение задачи замедляется.
Типичные ошибки дизайна включают:
Подобные проблемы особенно распространены в:
Booking.com delivers an excellent experience in map navigation within its app. The map responds accurately and intuitively to user gestures, allowing for smooth zooming in and out without any interruptions or errors.
This precise and seamless interaction enhances usability, enabling users to explore hotels effortlessly. Whether searching for accommodations or exploring specific areas, the smooth map functionality ensures users can focus on their tasks without frustration, making Booking.com a benchmark for effective map integration in mobile apps.
Trenitalia — пользователь создаёт аккаунт в приложении Trenitalia, итальянском сервисе для покупки билетов на национальные и региональные поезда и местные автобусы.
Binance — пользователь хочет открыть историю ордеров в своём аккаунте Binance.
7.3. Сервис не защищает от ошибок ввода.
Пользователи обычно ожидают, что цифровые сервисы будут улавливать опечатки и помогать при вводе данных. Они рассчитывают на мгновенную и понятную обратную связь во время ввода, а не после отправки формы. Поэтому данный подкласс описывает ситуации, когда интерфейс не помогает пользователям избегать или обнаруживать ошибки ввода.
Ошибки возможны в любой системе, но эффективные интерфейсы спроектированы так, чтобы минимизировать их вероятность и поддерживать пользователя в их исправлении на ранних этапах.
Проблемы часто возникают из-за:
Подобные проблемы особенно распространены в сервисах, связанных с формами, авторизацией или поиском, особенно в:
Amazon демонстрирует отличный пример ориентированного на пользователя процесса ввода данных, используя «прощающее» форматирование, которое терпимо к ошибкам и опечаткам. Сервис помогает пользователю беспрепятственно завершать задачи, даже если при вводе данных допущены ошибки. Дополнительно приложение улучшает процесс поиска, предлагая быстрые подсказки прямо в поле ввода. Эти подсказки помогают уточнить запрос и быстрее найти нужный товар, даже если пользователь не уверен в деталях.


Libby — Найти конкретную книгу, будучи неуверенным в правильности написания имени автора.
Glovo — Ввести адрес доставки при оформлении заказа.
8.1. Сервис создаёт впечатление, что операция бесплатна или стоит дешевле, чем на самом деле.
Пользователи ожидают прозрачности в вопросах ценообразования и предполагают, что отображаемая цена отражает полную стоимость услуги или продукта. Когда скрытые комиссии раскрываются слишком поздно или информация подаётся двусмысленно, это нарушает ожидание честности и снижает доверие.
Этот подкласс описывает ситуации, когда интерфейс формирует ложное или неполное представление о стоимости. Пользователю может казаться, что операция бесплатна, уже включена в тариф или стоит дешевле, чем на самом деле. Причиной этого становятся: отсутствие информации о цене, неудачное размещение деталей или намеренное использование «тёмных паттернов», которые занижают реальную стоимость.
Как это проявляется
Типичные UI-триггеры
Даже если стоимость формально указана, общее впечатление от интерфейса оставляет у пользователя чувство обмана. Подобные проблемы особенно распространены в сервисах для путешествий, e-commerce и подписочных платформах.
В приложении Tomplay есть отдельный раздел с бесплатными нотами. При переходе туда и нажатии на кнопку загрузки партитура скачивается сразу — без подписки или дополнительных условий. Такой прозрачный подход делает процесс получения бесплатного контента простым, честным и удобным.
Avis — аренда автомобиля при ограниченном бюджете: скрытые комиссии или непрозрачные условия повышают фактическую стоимость, подрывая доверие пользователя.
8.2. Элементы интерфейса воспринимаются пользователем как решение его задачи, но на самом деле предназначены для других целей.
Этот подкласс описывает ситуации, когда дизайн, подписи или расположение элементов интерфейса вводят пользователя в заблуждение, создавая впечатление, что элемент поможет выполнить его задачу, хотя на самом деле это не так.
Основная проблема — несоответствие между тем, что интерфейс обещает на первый взгляд, и тем, что он реально делает. Это может происходить из-за:
Такие ситуации нарушают UX-принцип «распознавание важнее запоминания», так как пользователь ориентируется на подсказки интерфейса, а не на фактический результат.
Проблемы этого типа могут встречаться в любых цифровых сервисах, в самых разных сценариях — от поиска настроек аккаунта до совершения платежей. Особенно часто они проявляются в мобильных приложениях, где пространство экрана ограничено, а визуальные подсказки (иконки, ярлыки) играют ключевую роль в поведении пользователей.
В мобильном приложении YouTube поисковая строка для раздела «История» расположена непосредственно над списком просмотренных видео. Такое размещение обеспечивает чёткую визуальную иерархию, так как поле поиска визуально и контекстно связано с заголовком «История просмотров». Дизайн естественным образом направляет внимание пользователя на правильную функцию поиска для нахождения ранее просмотренного контента. При этом глобальный поиск остаётся доступным через отдельную иконку в правом верхнем углу, что сохраняет ясность и предотвращает путаницу между локальным и глобальным поиском.

8.3. Сервис не отображает уточняющую информацию или элементы интерфейса, что приводит к ошибкам пользователей и неправильной интерпретации данных в сервисе.
Такие проблемы возникают в ситуациях, когда интерфейс содержит элементы или термины, смысл которых непонятен без дополнительного контекста, и пользователь ожидает, что система предоставит пояснения. Данный подкласс охватывает случаи, когда отсутствие уточняющего контента, визуальных подсказок или контекстных объяснений приводит к тому, что пользователь неправильно понимает происходящее или свои действия. В результате формируются ошибочные предположения, совершаются ошибки или принимаются решения на неверной основе.
Эта проблема встречается во многих типах цифровых сервисов:
В одних случаях такие упущения являются непреднамеренными и отражают слабый приоритет в дизайне или контенте. В других — могут рассматриваться как «тёмные паттерны», когда ясность намеренно скрывается, чтобы подтолкнуть пользователя к менее осознанному решению.
Пользователь видит нужный бекон в каталоге Food4Less. Цена со скидкой вписывается в его бюджет, поэтому он решает оформить заказ именно в этом магазине. Однако при добавлении товара в корзину цена меняется на $8.99. В корзине нет никакого индикатора того, что скидка не применена, и что для её активации нужно выполнить дополнительные действия. Позже, посетив страницу товара, пользователь узнаёт, что скидка доступна только при наличии карты лояльности магазина, которой у него нет.
Кроме того, сервис намеренно отображает цену и поясняющий текст «With loyalty card» в разных стилях. В результате пользователь не связывает этот текст с ценой.
Приложение некорректно информировало пользователя об ограничениях, связанных с применением скидки.
В приложении Ocado товары со скидками явно помечены в каталоге поясняющими бейджами с условиями получения скидки. Пользователь заранее понимает, какие действия необходимо выполнить, чтобы получить выгодную цену. Такая прозрачная и своевременная коммуникация предотвращает несоответствие ожиданий и делает процесс покупок более понятным и предсказуемым.

8.4. Интерфейс не даёт никаких визуальных или текстовых подсказок о скрытых функциях или информации.
Этот подкласс описывает ситуации, когда важные функции или информация скрыты за интерактивными элементами, но интерфейс никак не подсказывает пользователю, что с ними можно или нужно взаимодействовать. Пользователь ожидает, что сервис будет направлять его, раскрывать свои возможности. Когда это ожидание нарушается, пользователи упускают функции только потому, что в UI нет никаких сигналов об их существовании.
Здесь речь идёт об отсутствии аффордансов — визуальных или текстовых подсказок, которые помогают пользователю распознать, где возможно взаимодействие. Например, в каруселях или горизонтальных меню частично обрезанные элементы или лёгкие тени дают понять, что контента есть больше. Подобные проблемы могут встречаться в сервисах любого типа и в самых разных сценариях.
После нажатия на одну из иконок на карте открывается карточка объекта, но видна только одна фотография. Пользователь проводит свайп, ожидая увидеть другие фото этой же квартиры, но вместо этого открывается карточка другого объекта.
Неясно, что именно произойдёт после свайпа: в одних сервисах (AirBnB, Trip.com) это означает просмотр фотографий того же объекта, а в других (Booking, Agoda) — переход к следующему объекту. Таким образом, существует более одного сценария, и пользователю приходится уделять больше внимания интерфейсу, чтобы не потеряться. Отсутствие предсказуемости и подсказок о возможных действиях может вызвать ощущение дезориентации.
Многие приложения сталкиваются с проблемой в режиме карты, когда непонятно, что произойдёт при свайпе изображения отеля. Agoda решает эту задачу эффективно: сервис явно указывает, что свайп приведёт к показу следующего объекта. Такой подход снижает путаницу и делает пользовательский опыт более интуитивным.
В приложениях, где свайп используется для просмотра нескольких фотографий одного и того же объекта, Airbnb демонстрирует лучшую практику — использование пагинационных точек. Эти индикаторы показывают количество доступных изображений и помогают понять, что произойдёт после свайпа. Такой приём делает пользовательский путь более предсказуемым и бесшовным.
Condor (Choose the connecting flight with the suitable layover)
Проблемы этого класса чаще всего возникают на странице продукта.
9.1. Важная информация труднонаходима или недостаточно заметна.
Что в данном контексте считается «важной» информацией?
Важная информация r — это любые данные, которые являются ключевыми для выполнения задачи или принятия решения: например, детали цены, правила провоза багажа или статусы транзакций.
Есть две основные причины, из-за которых такая информация становится труднодоступной: её расположение и её визуальная заметность.
С точки зрения расположения, это не навигационная проблема (как в Классе 3), так как пользователь уже находится на правильном экране или странице; он достиг нужного контекста, но критически важная информация внутри этого контекста не представлена достаточно явно.
Плохое расположение означает, что важная информация помещена в такие зоны интерфейса, куда пользователи не смотрят в естественном ходе выполнения задачи. Это может проявляться в следующем:
С точки зрения видимости проблема возникает, когда информация находится на нужном экране, но визуально не выделена. В отличие от класса 12.4, где вся система дизайна выстроена так, что замедляет поиск информации, проблемы в 9.1 могут встречаться даже в интерфейсах, которые в целом хорошо сделаны — но на конкретном экране важной информации уделено недостаточно визуального веса.
Это может происходить, например, когда информация:
Часто встречаются комбинации указанных UX-недочётов: информация остаётся незамеченной одновременно из-за неудачного расположения и слабого визуального акцента, либо из-за нескольких факторов.
В истории транзакций Evoca Bank отсутствует ключевой контекст — не указано, входящая или исходящая это операция. Узнать это можно только при открытии детальной информации по каждой транзакции, что требует лишних действий и времени.
Без чётких индикаторов направления транзакций пользователи не могут быстро и точно отследить свои доходы и расходы, что снижает удобство и эффективность приложения как инструмента финансового управления.

Wise демонстрирует отличный стандарт оформления истории транзакций в банковских приложениях. Каждая запись чётко показывает ключевые детали: сумму, тип транзакции и её статус, сопровождаемые понятными иконками. Входящие и исходящие суммы визуально различаются с помощью цветового кодирования (например, зелёный для поступлений), что позволяет легко отличать доходы и расходы с первого взгляда.

Binance — перевод USDT между двумя кошельками внутри приложения.
9.2. Критическая информация недоступна в нужный момент.
Этот подкласс описывает ситуации, когда пользователь уже находится в процессе выполнения задачи, но какой-то важнейшей информации не хватает именно в тот момент, когда она нужна больше всего. В отличие от 9.1, где информация присутствует, но плохо размещена или оформлена, в 9.2 проблема в том, что система не предоставляет критические данные в точке принятия решения. Пользователю приходится гадать, возвращаться назад или вовсе прерывать задачу.
Что делает информацию «критической»?
Она считается критической, если без неё пользователь не может уверенно или успешно завершить текущую задачу. Сюда относятся данные о цене, ограничениях, доступности или любых требованиях, напрямую связанных с выбором.
Такая проблема часто встречается в:
Wise демонстрирует образцовый подход к предоставлению пользователям полной информации о транзакциях. Для переводов P2P пользователи могут зайти в историю и получить все необходимые данные. Приложение позволяет быстро сформировать документ с деталями операции и скачать его в формате PDF. Кроме того, доступна опция отправки документа по email, в мессенджеры или любым другим удобным способом, что обеспечивает гибкость и удобство для хранения и передачи данных.
GG Taxi — заказ такси пользователем, который хочет сэеономить.
9.3. Отсутствует необходимая информация для завершения задачи.
Этот подкласс описывает ситуации, когда пользователь не может завершить задачу, потому что ключевая информация полностью отсутствует в интерфейсе. Она не представлена в контексте, не доступна в разделах помощи и вообще нигде не отображается в приложении. В отличие от класса 1.1, где получение информации является основной целью пользователя, в 9.3 информация является вторичной, но необходимой — её отсутствие мешает успешно завершить задачу.
Пользователь часто оказывается в тупике: он может отказаться от выполнения задачи, обратиться к сторонним источникам или в службу поддержки. Это вызывает разочарование, недоверие и ощущение, что система ненадёжна или не учитывает реальные потребности.
Подобные проблемы часто встречаются в:
Trip.com демонстрирует отличный подход, предлагая единый процесс бронирования как для прямых, так и для стыковочных рейсов. В том числе выбор багажа встроен в единый поток для всех типов перелётов. Такая стандартизация повышает предсказуемость интерфейса, снижает риск ошибок и упрощает для пользователей процесс принятия решений.
9.4. Сервис не сообщает ожидаемое время выполнения операций.
Если операция не является мгновенной и занимает время, пользователь должен быть проинформирован о предполагаемой длительности ожидания — принципы контроля и предсказуемости в UX нарушать нельзя. Задача системы — заранее сообщить ожидаемое время ожидания как до действия (например, в форме оплаты перед транзакцией), так и после (на экране подтверждения).
Если обратная связь отсутствует, у пользователей возникает чувство неопределённости:
— «И что теперь? Когда это завершится?»
— «Уже обработано? Ждать дальше или обращаться в поддержку?»
Такая проблема обычно встречается в финансовых сервисах, государственных и коммунальных приложениях, а также в онбординге или процессах верификации, где операции вроде платежей, загрузки документов, обращений в поддержку или рассмотрения заявок могут занимать минуты, часы или даже дни — но система никак не сообщает об этом.
Пример: После отправки заявки на кредит пользователь видит сообщение об успешной отправке, но не получает информации о том, сколько времени займёт рассмотрение и когда он будет уведомлён.
Airbnb демонстрирует оптимальное решение, предоставляя пользователям чёткие ожидания при контакте с хозяином. Приложение показывает, что ответ поступит в течение 24 часов, и указывает локальное время в регионе хозяина, помогая пользователям предугадать момент получения ответа. Кроме того, в каждой карточке объекта указано, как быстро хозяин обычно отвечает, что позволяет планировать действия. Общение арендаторов с хозяевами ведётся прямо в приложении, что делает канал связи очевидным и удобным. В нижнем меню приложения размещён отдельный раздел Messages, где пользователь может легко найти все свои диалоги в любое время. Это снижает тревожность и делает процесс более прозрачным и предсказуемым.



10.1. Похожие действия выполняются по-разному в разных частях сервиса.
Этот подкласс описывает ситуации, когда пользователи сталкиваются с несогласованностью в том, как одни и те же или схожие действия выполняются в разных разделах сервиса. Это может проявляться в различиях в расположении элементов, паттернах взаимодействия, доступных опциях, терминологии или размещении элементов управления.
Такая несогласованность нарушает принцип внутренней консистентности, который позволяет пользователям переносить знания, полученные в одном разделе интерфейса, в другой. При его нарушении пользователям приходится заново учиться взаимодействию, что увеличивает когнитивную нагрузку.
Чаще всего проблема возникает из-за дизайнерских решений, принятых изолированно, когда разные разделы разрабатываются без общих гайдлайнов или повторного использования компонентов. Особенно сильно это проявляется в сервисах со сложными сценариями и множеством точек входа, где одно и то же действие (например, сортировка, редактирование, подтверждение) доступно из разных частей приложения или сайта.
Эта проблема часто встречается в:
Система фильтров на сайте Skillshare непоследовательна и сложна для освоения. Структура фильтров меняется в зависимости от зоны навигации, что создаёт фрагментированный опыт:
В итоге пользователю приходится выполнять слишком много навигационных действий, чтобы добраться до базовых фильтров. Такая несогласованность заставляет подстраиваться под разные логики фильтрации в зависимости от зоны навигации, делает процесс поиска длиннее и менее интуитивным. Отсутствие единого подхода нарушает пользовательский путь и снижает общую удобство использования.
На образовательных сайтах быстрый доступ к фильтрам критически важен, чтобы пользователи могли быстро находить подходящие курсы. Udemy демонстрирует лучший пример: фильтры по уровню, языку и рейтингу доступны как в каталоге, так и в поиске, независимо от точки входа. Они расположены на видном месте и сразу доступны, без дополнительных шагов. Такой единый и ориентированный на пользователя дизайн обеспечивает плавный и предсказуемый опыт поиска, позволяя быстро и интуитивно находить нужный курс.
Skillshare — Регулировка скорости воспроизведения видео.
10.2. Для выполнения действий требуются необычные элементы интерфейса или нестандартные действия.
Этот подкласс описывает ситуации, когда сервис заставляет пользователя взаимодействовать с нестандартными элементами интерфейса или выполнять непривычные действия, хотя для этой же задачи существует устоявшийся и более эффективный паттерн.
Пользователи естественным образом ожидают, что стандартные действия (например, выбор количества, удаление элемента, подтверждение шага) будут работать так же, как и в других сервисах. Когда эти ожидания нарушаются без веской причины, возникает путаница. Проблема не в инновациях как таковых — она появляется, когда кастомное взаимодействие заменяет привычное, но работает хуже, усложняя задачу, замедляя её выполнение или увеличивая риск ошибок.
Такие проблемы особенно часто встречаются в:

Realtor, американский сайт недвижимости, предлагает удобный и гибкий фильтр для поиска квартир по количеству спален в формате выпадающего списка. Когда пользователь нажимает на фильтр “Beds”, отображаются все варианты, позволяя задать как минимальное, так и максимальное количество спален — что особенно удобно для тех, у кого есть точные требования. Кроме того, можно указать только минимальное количество или оставить любой вариант, если точное число не принципиально. Когда задано минимальное количество, знак «+» рядом с числом чётко показывает, что в результатах поиска будут квартиры с этим количеством спален или больше.
10.3. Несогласованная обратная связь для похожих действий.
Этот подкласс описывает ситуации, когда система дает разные типы или уровни обратной связи для схожих действий в разных частях интерфейса. Пользователи ожидают, что одинаковые взаимодействия будут приводить к предсказуемым и единообразным реакциям, и нарушение этой логики подрывает понимание того, как работает система.
Примеры несогласованной обратной связи:
Такая непоследовательность часто заставляет пользователей сомневаться в результате своих действий и подозревать, что система работает ненадёжно.
Проблема часто встречается в финансовых сервисах, управлении аккаунтом и при отправке контента, особенно если один и тот же тип действий распределён по нескольким сценариям или экранам.
После ввода запроса «Magnesium B6» в поисковой строке пользователь получает список из 1 775 товаров. Столкнувшись с таким большим выбором, он пытается найти более доступные варианты, используя сортировку. При переключении на сортировку по возрастанию цены список неожиданно сужается до 2 товаров. Это вызывает раздражение, так как изначально система показала широкий выбор, но после сортировки оставила только минимальное количество результатов. Вероятно, проблема связана с тем, что только два товара точно соответствуют запросу пользователя. Однако для пользователя это неочевидно: он ожидает, что даже при отсутствии точных совпадений система позволит сортировать все 1 775 похожих результатов.
В итоге у пользователя нет возможности увидеть все товары, связанные с «Magnesium B6», отсортированные по цене. Чтобы найти самый дешевый вариант, приходится вручную просматривать и анализировать длинный список предложений.
На сайте Fruitful Yield количество результатов поиска остается одинаковым вне зависимости от выбранного варианта сортировки. При сортировке по цене, релевантности или другим критериям система просто перестраивает полный список результатов, не сокращая и не исключая товары. Благодаря этому пользователи легко находят самый дешевый или наиболее подходящий продукт без необходимости вручную просматривать весь каталог.
Omio — Настройка багажа при бронировании авиабилета
10.4. Сервис ведёт себя неожиданно с точки зрения пользователя.
Этот подкласс описывает ситуации, когда поведение системы не соответствует ожиданиям пользователя, даже если интерфейс выглядит корректным или знакомым. Проблема возникает, когда действия пользователя приводят к нелогичным, непоследовательным или несоразмерным результатам по сравнению с его намерениями.
Эти ожидания формируются на основе стандартных паттернов цифровых сервисов — пользователи, например, предполагают, что кнопка «Назад» вернёт их на один шаг назад.
Неожиданное поведение часто связано со следующими случаями:
Такие ситуации подрывают доверие к сервису, так как пользователи начинают сомневаться в предсказуемости интерфейса и вынуждены перепроверять свои действия.
Ошибки, описанные в подклассе 11.1, чаще всего возникают из-за несоответствия между визуальной или текстовой формой элемента и реальной логикой системы. Эта проблема нередко встречается в финансовых приложениях, e-commerce, образовательных и сервисах бронирования.
Trip.com демонстрирует высокий стандарт настройки языка благодаря продуманному и интуитивному дизайну. По умолчанию приложение подстраивается под язык устройства, что обеспечивает лёгкий старт для новых пользователей. Кроме того, в настройках язык можно легко поменять без необходимости перезапуска или повторного входа в приложение, что упрощает процесс.
Особенно полезна независимость настроек языка, валюты и страны. Пользователи могут настраивать каждую опцию отдельно, выбирая наиболее удобную комбинацию. Например, смена языка не влияет на валюту или страну, и наоборот. Эта гибкость учитывает разнообразные предпочтения пользователей и делает Trip.com отличным примером продуманного и адаптивного дизайна.
iHerb — Покупка бюджетного витамина D 5000 МЕ
iHerb — Удаление ненужных товаров из корзины, чтобы оформить заказ только с двумя продуктами
Just Eat — Сравнение общей стоимости, добавляя товары в корзины разных ресторанов
OLIVE YOUNG GLOBAL — Переход к оформлению заказа в гостевом режиме
WizzAir — Бронирование рейса из Белграда в Барселону
11.1. Использование сложных профессиональных или технических терминов.
Этот подкласс описывает ситуации, когда интерфейс опирается на отраслевой или технический язык, который труден для понимания обычного пользователя. Подобная терминология может быть знакома профессионалам, но вызывает затруднения или остаётся совершенно непонятной для широкой аудитории.
Пользователи ожидают, что сервис будет общаться простым, человеческим и доступным языком. Когда ожидание нарушается, это раздражает:
— «Почему они разговаривают со мной так, будто у меня диплом по финансам?»
Эта проблема особенно часто встречается в сервисах, работающих с сложными или регулируемыми областями — такими как финансы, криптовалюты, здравоохранение или государственные платформы.
Типичные проявления проблемы:
Страница содержит сложные объяснения, перегруженные технической и юридической терминологией, что затрудняет понимание правил подачи заявки. Например, раздел «Who Should Use This Form?» включает ссылки на другие формы и упоминания о законе Affordable Care Act, что увеличивает когнитивную нагрузку. Из-за обилия профессиональных терминов снижается удобство использования, и пользователю сложно разобраться, имеет ли он право на рассрочку.
The Internal Revenue Service (IRS) — это налоговая служба США, ответственная за сбор федеральных налогов. Installment Agreement на сайте IRS — это план платежей, который позволяет налогоплательщикам погашать задолженность по налогам небольшими, более удобными суммами в течение времени, вместо единовременной полной оплаты. Эта опция доступна физическим лицам и бизнесу, которые не могут выплатить всю сумму к установленному сроку.


Сайт GOV.UK демонстрирует более ориентированный на пользователя подход. Когда пользователям нужно настроить рассрочку платежа из-за невозможности своевременно оплатить налог, страница предоставляет чёткую и лаконичную информацию. Контент структурирован по разделам с простыми маркированными списками, которые описывают необходимые шаги, используя понятный язык и избегая ссылок на другие формы или сложные юридические термины. Такой прямой и прозрачный подход помогает пользователям легко понять доступные варианты и действия, которые нужно предпринять.



11.2. Длинные и расплывчатые объяснения.
Эта проблема возникает, когда система пытается прояснить процесс или элемент, но объяснение оказывается настолько затянутым и неопределённым, что перестаёт быть полезным.
В отличие от двусмысленных фраз (11.3), которые чаще всего встречаются в основном языке интерфейса, расплывчатые объяснения в 11.2 обычно появляются как дополнительный контент — например, в тултипах, вспомогательных текстах или сносках. Они должны помогать, но на деле не выполняют эту функцию.
Такие объяснения часто:
В результате такие объяснения, наоборот, усиливают путаницу и когнитивную нагрузку:
— «Я всё равно не понимаю, что от меня требуется»
— «Зачем так усложнять? Просто скажите, что делать»


On PayPal's login page, users are clearly informed about the required credentials through well-labeled fields. The input field is accompanied by a label “Password” that explicitly indicates what information is expected. This approach eliminates ambiguity, ensuring users understand exactly what they need to provide.

11.3. Двусмысленные слова или фразы, допускающие несколько трактовок.
Этот подкласс описывает случаи, когда формулировка элементов интерфейса, чаще всего ярлыков или подписей, может быть истолкована по-разному.
В отличие от 11.2, где объяснения слишком длинные и размытые, здесь язык может выглядеть коротким и ясным, но его смысл недостаточно конкретен и может меняться в зависимости от предположений пользователя или контекста.
Такие проблемы часто возникают из-за:
Пользователи ожидают ясного и простого языка, и когда этого нет, могут делать неверные предположения.
Эта проблема особенно распространена в финансовых сервисах, где двусмысленная терминология может приводить к ошибочным решениям или провалам в выполнении задач.

В приложении Wise пользователям отображается единая, чёткая сумма баланса на экране счёта. Этот баланс отражает именно доступные для использования средства, исключая путаницу между такими понятиями, как «current» или «available». Отображая только потраченную сумму, Wise упрощает пользовательский опыт и гарантирует, что пользователи сразу видят доступные деньги без необходимости в дополнительных пояснениях.

11.4. Части интерфейса на иностранном языке.
Этот подкласс описывает ситуации, когда отдельные слова, фразы, кнопки или целые разделы интерфейса отображаются на языке, отличном от выбранного пользователем.
Ключевая причина такой проблемы — недостаточная глобализация или локализация:
Такие проблемы особенно критичны в:
Пользователи ожидают цельного и полностью локализованного опыта после выбора предпочитаемого языка. Даже единичные элементы на другом языке создают впечатление незавершённости, небрежности или недоверия к сервису.
В приложении Sparkasse после установки пользователь сразу может выбрать предпочитаемый язык на первом экране. После настройки приложения он попадает на экран входа, где есть возможность открыть расчётный счёт, если его ещё нет. Процесс открытия счёта полностью доступен на английском языке, что обеспечивает бесшовный опыт для тех, кто не говорит по-немецки. Интерфейс приложения удобен и упрощает настройку аккаунта, повышая доступность для широкой аудитории.
Shopee — Использование приложения на английском
Примечательно, что проблемы этого класса чаще всего встречаются в мобильных версиях сервисов, связанных с путешествиями. Такие интерфейсы нередко стремятся уместить большой объём информации в ограниченном пространстве небольшого экрана. В результате они часто жертвуют визуальной иерархией, отступами и ясностью, что приводит к перегруженным макетам и создаёт чрезмерную нагрузку на восприятие.
12.1. Информация и элементы интерфейса слишком мелкие или имеют низкий контраст.
Этот подкласс описывает ситуации, когда текст, иконки или функциональные элементы слишком малы, чтобы их можно было комфортно прочитать или нажать, либо когда контраст между элементами слишком низкий. Подобные проблемы особенно критичны на мобильных устройствах, где пространство экрана ограничено.
Скриншот


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

12.2. Интерфейс слишком яркий или цветной.
Этот подкласс описывает ситуации, когда чрезмерно насыщенные цвета, яркие фоны или избыточное использование контрастных акцентов создают визуально агрессивный опыт. Слишком яркие или перегруженные цветами интерфейсы вызывают усталость или дискомфорт, особенно при длительном использовании или в условиях низкой освещённости.
Визуально выразительный дизайн сайта соответствует художественной теме, но создаёт серьёзные проблемы с удобством использования:
В результате пользователь испытывает разочарование, так как ему сложно найти нужную информацию и эффективно ориентироваться на сайте.

Веб-сайт Университета Оксфорда демонстрирует образец лучших практик для академических учреждений, удачно сочетая профессиональную эстетику с функциональностью, ориентированной на пользователя. На сайте используется сдержанная и изящная цветовая схема, которая повышает читаемость и удерживает внимание на содержании, не отвлекая избыточными визуальными элементами. Меню продумано и структурировано так, чтобы пользователи могли быстро находить нужную информацию без путаницы. Чёткая категоризация и логичная иерархия обеспечивают лёгкую навигацию. Макет избегает чрезмерного использования пустого, рационально используя экранное пространство, но при этом сохраняя чистый и профессиональный внешний вид. Такой баланс позволяет эффективно представить контент без ощущения перегруженности.

12.3. Интерфейс перегружен слишком большим количеством элементов.
Этот подкласс описывает интерфейсы, которые одновременно перегружают пользователя информацией, элементами управления и визуальными объектами, затрудняя концентрацию или быстрое сканирование экрана.
Распространённые причины:
Скриншот


Форма бронирования авиабилетов в приложении Omio выполнена грамотно: визуальные акценты помогают пользователю ориентироваться и быстро выделять важную информацию. Несмотря на сдержанную цветовую палитру приложения, контраст между синим и белым цветами формирует чёткие границы и повышает читаемость, а удобный для восприятия шрифт снижает нагрузку на глаза. Результаты поиска автоматически сортируются по параметру «Recommended». Цветные логотипы авиакомпаний добавляют визуальный интерес и способствуют узнаваемости бренда, а элементы с повышенным визуальным весом — например, яркие подписи «2nd Cheapest» или «Fastest» — привлекают внимание к наиболее подходящим вариантам, помогая пользователю быстро находить оптимальные билеты.

12.4. В интерфейсе отсутствуют визуальные подсказки и акценты для быстрого поиска информации.
Этот подкласс описывает ситуации, когда пользователи не могут быстро найти ключевые данные или элементы действий, потому что интерфейсу не хватает выразительных визуальных маркеров, группировки или акцентов. Без визуального сопровождения пользователи вынуждены просматривать весь экран, что замедляет их и повышает нагрузку на внимание.
В отличие от 9.1 — где плохо оформлен или размещён один важный элемент, — здесь проблема заключается в отсутствии целостной визуальной иерархии во всём интерфейсе.
Пользователь не ищет конкретный объект, а пытается осмыслить экран целиком, и отсутствие визуальных подсказок вынуждает его «прочёсывать» всё подряд с дополнительным усилием:
— «Я не понимаю, что здесь главное — всё выглядит одинаково»
Типичные проблемы включают:
Чаще всего корень проблемы кроется в слабых основах дизайн-системы: либо визуальная иерархия не была определена, либо сервис использует общий шаблон интерфейса, не адаптированный к содержанию.

Форма бронирования автобусных билетов в приложении Omio выполнена грамотно: визуальные акценты помогают пользователю ориентироваться и быстро выделять ключевую информацию. Несмотря на сдержанную цветовую палитру, контраст между синим и белым цветами формирует чёткие границы и повышает читаемость. Цветные логотипы автобусных компаний добавляют визуальный интерес и способствуют узнаваемости бренда, а элементы с повышенным визуальным весом — например, яркие подписи «2nd Cheapest» или «Fastest» — привлекают внимание к наиболее подходящим вариантам, помогая пользователю быстрее находить оптимальные билеты. Результаты поиска также можно отсортировать по параметру «Fastest», что ещё больше упрощает процесс выбора наиболее удобного билета.

iHerb — Открыть каталог
Condor — Найти самый дешёвый билет