Ошибки начинающих дизайнеров и базовые UX/UI-практики
До этого мы учились понимать задачу пользователя, разбирать взаимодействие и замечать паттерны. Теперь сменим роль: вы уже нарисовали небольшой интерфейс и собираетесь показать его команде. Как проверить работу самому — не по принципу «мне нравится», а по понятным профессиональным критериям?
Хороший экран не равен хорошему решению
Начинающему дизайнеру легко начать самопроверку с того, что бросается в глаза: ровные ли отступы, совпадают ли радиусы, приятна ли композиция. Всё это важно, но профессиональная ошибка часто живёт уровнем выше. Экран может выглядеть проще, привычнее и аккуратнее — и при этом хуже помогать человеку получить правильный результат.
Хороший пример дала команда британского Department for Education — Министерства образования Великобритании. Она проектировала сервис для проверки профессиональной квалификации работников дошкольного образования. Первый вариант выглядел почти образцово просто: одно поле поиска и кнопка. [1]
Сначала поставьте диагноз сами
Представьте альтернативу: вместо свободного поиска сервис задаёт четыре конкретных вопроса и только после этого показывает подходящие варианты. Какой путь кажется проще на первый взгляд? Какой критерий нужен, чтобы выбрать между ними профессионально, а не на вкус?
В исследованиях знакомый поиск часто приводил к неудаче: названия квалификаций были похожи, а люди вводили сведения, по которым база не была организована. Альтернативный путь задавал четыре вопроса: где получена квалификация, когда начато обучение, какой у неё уровень и какая организация её выдала. Эти ответы постепенно сужали набор вариантов. [1]
На Figma-доске команда сопоставляла семь шагов всего guided-сценария с четырьмя шагами поискового пути. Это не семь вопросов: собственно вопросов было четыре. Общая доска полезна команде для обзора сценария, но её миниатюры слишком мелкие для учебного чтения, поэтому здесь мы смотрим на читаемый экран результата.
Пользовательское исследование показало, что почти все участники заметно надёжнее приходили к правильному результату через путь с вопросами, хотя часть людей субъективно предпочитала поиск. Поэтому важный вывод для самопроверки такой: простота интерфейса — не количество элементов и не минимальное число экранов. Сначала нужно определить результат задачи, затем спросить, насколько надёжно решение к нему приводит. [1]
Знать английский для разбора не требуется. В подписи к каждому экрану указано, на что именно смотреть и какой вывод сделала команда. Не пытайтесь переводить весь интерфейс — тренируйте дизайнерское наблюдение.
Ошибка 1–2. Красота и оригинальность становятся отдельной задачей
В первом блоке мы подробно разбирали композицию, цвет и визуальную иерархию. Здесь не повторяем эти темы. Новый вопрос звучит жёстче: что именно вы усиливаете визуальными средствами и зачем это нужно пользователю? Красивый экран полезен только тогда, когда красота поддерживает содержание и действие, а не заставляет человека обслуживать дизайнерскую идею.
То же относится к оригинальности. В прошлом уроке мы уже увидели, почему люди приходят в продукт с опытом других интерфейсов. Nielsen Norman Group приводит старый, но показательный пример магазина зимних товаров: привычную корзину назвали авторским термином Shopping Sled — «санки для покупок». Часть участников тестирования не понимала название; другим помогало лишь привычное расположение элемента. [2]
«Так выглядит интереснее. Обычная корзина слишком скучная».
«Что получает пользователь от необычного решения и компенсирует ли эта польза необходимость его расшифровать?»
Поэтому на самопроверке не нужно запрещать себе выразительный визуальный стиль или новые решения. Нужно требовать от них причины. Если элемент стал необычным только потому, что дизайнеру хотелось «сделать не как у всех», пользователь оплачивает эту оригинальность своим вниманием.
Ошибка 3. Приоритет начинается с пользовательского результата
Визуальная иерархия отвечает на вопрос «что человек заметит раньше». UX-проверка начинается на шаг раньше: что он вообще должен заметить раньше, чтобы решить текущую задачу? Это различие хорошо видно на реальном redesign страницы британского сервиса Explore education statistics — платформы официальной образовательной статистики.
Со временем страницы статистических выпусков обросли настоящим редакционным контентом. Вводные тексты могли вытеснять главные цифры вниз, а часть полезного материала пряталась в раскрывающихся секциях. Исследования показывали, что пользователи хотели быстрее видеть ключевые показатели и данные. [3]
Что здесь является UX-проблемой?
Не «слишком много текста» само по себе. Проблема возникает потому, что реальный контент перестал отражать приоритет задачи: люди приходили за ключевыми данными, а шаблон позволял второстепенной вводной информации отодвигать их ниже.
После нескольких итераций команда сократила верхнюю часть страницы, разделила крупные направления работы и подняла headline facts and figures ближе к началу. Это не урок «всегда ставьте цифры сверху»: другая задача потребовала бы другой иерархии. Важно, что порядок теперь аргументирован пользовательским приоритетом. [3]
На собственном макете задайте три вопроса: что человек делает сейчас? Что он должен понять перед действием? Что можно увидеть позже без риска для решения? Только после этого имеет смысл возвращаться к уже знакомым инструментам композиции и проверять, действительно ли они выражают этот порядок.
Ошибка 4. Макет без настоящего контента проверяет пустой контейнер
Предыдущий кейс показывает ещё одну проблему: интерфейс живёт не с тем текстом, который удобно поместился в макет, а с тем, который приходит из продукта. Nielsen Norman Group рекомендует подстраивать гибкие шаблоны под содержимое и проверять масштабирование заранее: container-first подход легко создаёт искусственные ограничения, когда реальный текст, данные или их количество перестают помещаться в заранее придуманные рамки. [4]
Для новичка достаточно простого стресс-теста. Возьмите один компонент и попробуйте не один «красивый» пример, а несколько допустимых вариантов данных.
| Проверка | Что она ловит |
|---|---|
| Очень короткое значение | Не держится ли вся композиция на искусственной длине текста. |
| Очень длинное, но допустимое значение | Переносы, переполнение, рост карточки и конфликт с соседними элементами. |
| Значение отсутствует | Понятно ли отсутствие данных и не выглядит ли интерфейс сломанным. |
| Неожиданное, но валидное значение | Не строится ли решение на слишком узком предположении о реальных данных. |
Например, карточка сотрудника с именем «Анна Иванова» ничего не доказывает. Попробуйте длинное название организации, отсутствующее отчество, длинный статус, цену с дополнительными разрядами. Вы не «ломаете дизайн» — вы проверяете, способен ли он обслуживать продукт.
Не нужно придумывать строку из 500 символов, если продукт такую строку никогда не допустит. Проверяйте реальные границы данных или честно помечайте предположение, если правила пока неизвестны.
Ошибка 5. Happy path — только одна ветка
Даже макет с настоящими данными может показывать только момент, когда всё идеально. Такой путь часто называют happy path — идеальным сценарием: пользователь вводит корректные данные, сеть отвечает, операция завершается успешно.
Здесь важно сохранить границу курса. Мы не изучаем сейчас отдельную систему Loading, Error, Empty, Partial, Disabled и других состояний — для этого впереди есть специальный урок. Пока задайте четыре вопроса: что видно до действия, что происходит во время обработки, что подтверждает успех и что получает человек, если сценарий пошёл неидеально.
Internal consistency: продукт должен помнить собственные правила
В предыдущем уроке конвенции описывали внешние ожидания: человек приходит из других продуктов и уже знает некоторые способы взаимодействия. Здесь consistency получает другой ракурс — внутреннюю последовательность одного продукта.
В 2025 году команда Teaching Record System Console — внутреннего сервиса управления данными об учителях — выложила на доску скриншоты всех основных сценариев. Так стали видны расхождения, которые трудно заметить по одному экрану: notification banners отличались структурой текста, теги одинаковых типов использовали разный регистр и цвета, одинаковые страницы проверки назывались по-разному. [5]
Что искать на таком ревью?
Сначала не «сделать всё одинаковым», а найти повторяющийся смысл. Если два статуса означают разное, им может требоваться разное оформление. Но если одинаковое действие в одном месте называется «Confirm», а в другом «Save» без смысловой причины, пользователь вынужден каждый раз заново интерпретировать продукт.
Nielsen Norman Group различает internal и external consistency именно так: внутреннее правило действует внутри продукта, внешнее — следует отраслевым и платформенным ожиданиям. [6] В этом уроке нас интересует первое.
Feedback: наличие сообщения ещё не означает, что ответ понятен
Во втором UX-уроке мы уже определили feedback как ответ системы на действие. Здесь термин не переучиваем. Проверяем качество: достаточно ли ответ своевременный, заметный и связанный с действием, чтобы человек понял состояние системы и следующий шаг? Nielsen Norman Group связывает видимость состояния именно с этой возможностью оценить результат предыдущего действия. [8]
Реальный кейс снова показывает, почему нельзя проверять принцип галочкой «сообщение есть». В сервисе Plan technology for your school после завершения части самооценки показывался зелёный Success banner. Исследования показали, что пользователи часто не замечали его, а заметив — не связывали сообщение с тем, что делать дальше. [7]
Почему «зелёный banner есть» — слабая проверка?
Потому что feedback должен помогать оценить состояние системы. Если человек не замечает сообщение или не понимает, с каким объектом оно связано, формально существующий баннер не выполняет задачу.
В следующей итерации команда убрала отдельный баннер, перенесла информацию о состоянии к самим темам и добавила явные действия для просмотра рекомендаций. Это не означает «баннеры плохие». Это означает, что feedback нужно оценивать через поведение пользователя, а не через наличие конкретного компонента. [7]
Error prevention и recovery: не путайте предотвращение с восстановлением
Хорошее сообщение об ошибке полезно, но error prevention — предотвращение ошибок — идёт раньше: дизайн старается убрать предсказуемую ловушку или проверить опасное условие до действия с последствиями. Nielsen Norman Group формулирует этот принцип именно как устранение ошибкоопасных условий либо проверку перед подтверждением действия. [10]
Отдельно полезно знать слово recovery — восстановление после ошибки. Это не новая большая тема урока, а граница, которая не даст смешать два действия дизайнера: prevention старается не допустить проблему, recovery помогает человеку продолжить, когда проблема уже обнаружена.
В Register of training providers адрес из внешнего справочника мог выглядеть полным, хотя в данных отсутствовало обязательное поле. Раньше пользователь попадал дальше и не имел возможности дополнить адрес. Команда изменила сценарий: теперь система проверяет обязательные поля до следующего шага; если чего-то не хватает, открывает ручную форму и подставляет уже известные данные. [9]
Разделите prevention и recovery
Prevention: система проверяет, что обязательные части адреса существуют до перехода дальше. Recovery: после обнаружения проблемы сохраняет уже известные город, индекс и другие поля, показывает конкретную причину и просит дополнить только недостающее.
Это важная привычка самопроверки: сначала спросить «можно ли убрать предсказуемую ошибку до её возникновения?», а уже потом «если она всё же случилась, сможет ли человек понять причину и продолжить?».
Progressive disclosure: скрывайте сложность, а не смысл
Когда возможностей много, возникает соблазн сделать экран «чище», спрятав часть содержания. Именно здесь нужен принцип progressive disclosure — постепенного раскрытия. Он переносит вторичные или редко нужные возможности на следующий уровень, чтобы не заставлять всех пользователей разбираться со всей сложностью сразу. [13]
Ключевое слово — вторичную. В сервисе проверки квалификации команда первоначально спрятала дополнительные требования по уровням в раскрывающиеся details-блоки, чтобы страница выглядела компактнее. В исследованиях участники редко раскрывали их без подсказки, пропускали важные требования и путали, к какому уровню относится раскрытый текст. [11]
Почему это неудачное progressive disclosure?
Потому что скрытая информация была нужна для самого решения. Пользователь не мог уверенно оценить квалификацию, не увидев требования. Progressive disclosure не должно превращать существенное условие в необязательное «почитать подробнее».
Команда заменила скрытые блоки на summary cards: уровень, статус и применимые требования стали видны вместе. Страница осталась структурированной, но человеку больше не нужно угадывать, какой блок раскрыть. [11]
А вот другой экран того же семейства сервисов показывает более подходящий случай постепенного раскрытия. Поле даты окончания нужно только тогда, когда пользователь выбирает статус Passed — «пройдено». До этого оно не относится к текущему выбору. [12]
Sensible defaults: иногда лучший default — никакого выбора
Ещё один способ уменьшить лишнюю работу — заранее поставить разумное начальное значение. Хороший default даёт вероятную или безопасную отправную точку и остаётся заметным и легко изменяемым. Но плохо выбранное значение может незаметно вести человека к ошибке: пользователи часто не меняют то, что уже выбрано системой. [14]
| Ситуация | Что проверить |
|---|---|
| Российский сервис доставки начинает со страны «Россия» | Соответствует ли это основному контексту и можно ли легко изменить. |
| Список открывается в наиболее часто полезной сортировке | Помогает ли отправная точка большинству задач, не скрывая другие варианты. |
| Платная дополнительная услуга уже согласована за пользователя | Не превращает ли default невнимательность в финансово значимое решение. |
Поэтому «у каждого элемента должен быть default» — плохое правило. Для субъективного, рискованного или финансово значимого выбора отсутствие предвыбранного ответа может быть разумнее. NN/g отдельно отмечает, что в опасных подтверждениях иногда лучше вообще не давать ответа по умолчанию. [15]
Здесь пригодится прошлый урок о deceptive patterns: sensible default помогает человеку начать, а не использует его невнимательность в интересах продукта.
Что исправлять первым: серьёзность важнее количества замечаний
После такого прохода вы почти наверняка найдёте больше трёх проблем. Новая ошибка новичка — считать их равнозначными. Два пикселя лишнего отступа и неясный результат после оплаты не должны занимать одинаковое место в ревью.
Для базовой самопроверки не нужна формальная шкала severity из исследовательской практики. Достаточно простого порядка, который заставляет связать замечание с пользовательской задачей и последствиями.
| Уровень | Проверочный вопрос | Пример |
|---|---|---|
| 1. Блокирует | Может ли человек вообще завершить задачу? | Обязательное поле нельзя заполнить допустимым значением. |
| 2. Риск существенной ошибки | Может ли интерфейс привести к неверному или дорогому результату? | После оплаты непонятно, прошла ли операция, и пользователь повторяет её. |
| 3. Лишняя работа или неопределённость | Задача выполнима, но приходится угадывать или делать лишние шаги? | Одинаковое действие в разных местах называется по-разному. |
| 4. Косметика | Изменится ли выполнение задачи, если это оставить? | Незначительное расхождение отступов без влияния на смысл и действие. |
Позже вы научитесь опираться на исследования, частоту проблемы и данные продукта. Сейчас цель проще: перестать сортировать замечания по тому, насколько они раздражают дизайнера визуально.
Self-review: от наблюдения к аргументированному решению
Финальный навык урока — не просто заметить слабое место, а сформулировать его так, чтобы другой человек мог проверить вашу логику. Слово «плохо» ничего не объясняет. Хорошее замечание отделяет факт от интерпретации и связывает изменение с пользовательской задачей.
«После расчёта интерфейс какой-то непонятный. Я бы переделал кнопку».
«После изменения веса результат визуально не меняется и нет сигнала, применились ли новые параметры. Пользователь не может понять, соответствует ли показанная стоимость последнему вводу. Нужно сделать новое состояние расчёта наблюдаемым».
Удобная последовательность для собственного ревью:
- Факт: что именно вы наблюдаете на экране или после действия.
- Влияние: что из-за этого становится труднее, рискованнее или непонятнее в задаче.
- Принцип: какой уже изученный критерий помогает объяснить проблему.
- Изменение: что должно измениться в поведении или информации, а не просто «стать красивее».
- Приоритет: насколько серьёзны последствия по сравнению с другими найденными проблемами.
Это и есть базовая профессиональная самопроверка. Она не заменяет исследования с реальными пользователями и не доказывает, что ваша гипотеза верна. Зато позволяет убрать очевидные ошибки до того, как команда потратит время на их обсуждение.
- Проверяйте интерфейс через пользовательский результат, а не через красоту или количество экранов.
- Визуальная иерархия должна отражать приоритет задачи, а макет — выдерживать настоящий контент и неидеальные ветки.
- Internal consistency и feedback оцениваются через предсказуемость поведения, а не наличие конкретных компонентов.
- Error prevention старается убрать ловушку до ошибки; recovery помогает продолжить, если проблема уже возникла.
- Progressive disclosure скрывает вторичную сложность, а sensible defaults уменьшают усилие, не решая за человека.
- Хорошее self-review замечание связывает факт, влияние на задачу, принцип, изменение и приоритет.
Откройте публичный калькулятор доставки Почты России для бизнеса. На момент подготовки урока в нём доступны страна и города, тип отправления, тип партии, объявленная ценность, вес, габариты и способы отправки и доставки. [16] Если интерфейс изменился, не пытайтесь воспроизвести старую версию: работайте с тем, что реально видите, и фиксируйте отличие.
Нужно оценить стоимость отправки товара из Москвы в Казань: одно отправление, вес 1200 г, размеры 25 × 18 × 8 см. Не оформляйте отправление и не вводите персональные данные.
- Задача и приоритет. Одним предложением сформулируйте результат пользователя. Затем укажите, какой блок или действие должно быть главным на текущем шаге и почему.
- Начальное состояние и defaults. Запишите, что уже выбрано до вашего действия. Для каждого значения решите: оно помогает, нейтрально или может незаметно изменить результат. Если важный выбор не сделан заранее — тоже зафиксируйте это как решение.
- Действие и feedback. Заполните маршрут, вес и габариты. Перед расчётом запишите, что ожидаете увидеть. После действия сделайте скриншот и сравните ожидание с фактом. Затем измените один параметр и проверьте, понятно ли, относится ли показанный результат уже к новым данным.
- Неидеальная ветка. Безопасно очистите одно обязательное поле или введите очевидно недопустимое числовое значение, если интерфейс это позволяет. Разделите наблюдение: что система предотвращает до отправки формы и как помогает восстановиться после обнаруженной проблемы.
- Правила продукта. Сравните названия действий, единицы измерения и оформление одинаковых смыслов. Переключите тип партии между единичным и многоместным, если такой выбор доступен, и посмотрите, появляется ли связанная сложность только тогда, когда нужна. Не называйте отсутствие progressive disclosure ошибкой автоматически — сначала докажите, что скрывать здесь вообще есть что.
Сделайте три скриншота: исходное состояние, одно значимое промежуточное или ошибочное состояние и результат. Затем выпишите наблюдения и выберите ровно три самых существенных. У каждого используйте форму: «факт → влияние на задачу → принцип → изменение → уровень серьёзности».
Добавьте ещё один пункт: одно решение, которое вы бы сохранили без изменений, и объясните, почему оно помогает пользователю. UX-review — не соревнование по количеству критики.
- Пользовательская задача сформулирована как результат, а не как последовательность кликов.
- Есть три собственных скриншота разных состояний текущего интерфейса.
- Defaults оценены через контекст; отсутствие предвыбранного ответа тоже допускается как разумное решение.
- Хотя бы один случай feedback сравнивает ожидаемое состояние с фактическим.
- Prevention и recovery не смешаны в одно понятие.
- Найденные inconsistencies сначала проверены на различие смысла, а не названы ошибками по внешнему виду.
- Выбрано ровно три главных замечания, и их приоритет объяснён последствиями для задачи.
- Есть одно аргументированное решение «оставить как есть».
Подсказка, если замечаний получилось слишком много
Сначала уберите косметику. Затем спросите: что блокирует расчёт, что способно привести к неверному результату, а что только добавляет лишнюю работу или неопределённость. Если вы не можете описать влияние на пользовательскую задачу, замечание пока недостаточно аргументировано.
Показать ответ
C. Количество шагов — характеристика решения, а не самостоятельный критерий качества. Если задача требует точного результата, надёжность сценария важнее формальной краткости.
Показать ответ
B. Длина сама по себе не является ошибкой. Проблема в том, что структура после появления реального контента перестала выводить на первый план то, за чем человек пришёл.
Показать ответ
A. Consistency не означает механическое одинаковое оформление. Если смысл или последствия действительно различаются, различие может быть полезным; случайная вариативность — нет.
Показать ответ
B. Критерий — не наличие баннера, а понимание результата действия. Если человек не связывает сообщение с новым состоянием и дальнейшим действием, ответ системы не выполняет задачу.
Показать ответ
C. Ограничение не даёт создать предсказуемо невозможное состояние, а сохранённые данные уменьшают цену уже случившейся проблемы и помогают продолжить.
Показать ответ
A. Progressive disclosure подходит вторичной сложности. Если информация нужна почти каждому для решения основной задачи, её сокрытие разрушает сам принцип.
Показать ответ
C. Финансово значимый выбор не должен зависеть от того, заметит ли человек предустановку. В такой ситуации отсутствие выбора по умолчанию часто безопаснее.
Показать ответ
C. Самопроверка приоритизирует влияние на задачу и цену ошибки. Косметические расхождения можно исправить позже, если они не меняют понимание и действие.