10 UX-ошибок, которые совершают даже опытные дизайнеры
Когда опыт становится слепой зоной
В дизайнерских кругах есть уютный миф о том, что ошибки — проблема джунов, из которой перерастаешь, выпустив достаточно продуктов и высидев достаточно клиентских звонков. На практике происходит обратное. Опыт даёт вам шорткаты, а шорткаты — это именно то место, где прячутся плохие привычки. Дизайнер с десятью годами за плечами не перестаёт ошибаться — он просто делает более уверенные ошибки, быстрее, и с лучшими готовыми оправданиями, если кто-то начнёт возражать.
Я совершил каждую ошибку из этого списка, обычно не по одному разу, и видел, как множество талантливых людей — в агентствах, в инхаус-командах, в соло-практике — повторяют их тоже. Дальше — не чек-лист для новичков. Это то, что переживает джуниорские годы, потому что маскируется под компетентность: сопоставление с паттернами, которое на самом деле лень, уверенность, которая на самом деле избегание, и процессные шорткаты, которые работают нормально — до того одного проекта, где не сработают.
Дизайн для себя, а не для пользователя
Чем больше дизайн-систем вы построили, тем больше мнений накопилось о том, как выглядит «хорошо». Это полезно, пока незаметно не подменяет реальный контекст пользователя. Я сидел на ревью, где старший дизайнер отклонил раскладку, потому что она казалась «захламлённой» — совершенно валидное эстетическое суждение — для дашборда, которым пользуется складской персонал, которому нужно видеть все цифры сразу, не переключаясь между тремя вкладками. Дизайн был объективно хуже для аудитории и объективно приятнее выглядел на скриншоте в портфолио. Это напряжение никогда полностью не исчезает, и опытные дизайнеры чаще проигрывают эту схватку молча, потому что их вкус подтверждали столько раз, что он начинает ощущаться как данные.
Решение не в том, чтобы не доверять своему вкусу — а в том, чтобы держать его в своих рамках. Вкус выбирает между двумя вариантами, которые уже удовлетворяют реальную задачу пользователя. Он никогда не должен быть решающим фактором в том, обнаруживаема ли функция, читается ли текст на расстоянии вытянутой руки, или имеет ли смысл форма для человека, заполняющего её в 14:00 на складе, а не на MacBook в хорошо освещённой студии.
Пропуск исследований, потому что «я и так знаю ответ»
Это версия старшего дизайнера полного пропуска пользовательских исследований — не признание, что вы это пропускаете, а переформулирование этого как эффективности. «Мы уже строили пять таких, я знаю, что нужно пользователям» иногда правда, а иногда очень дорогое допущение. У каждой вертикали свои особенности: то, что сработало для B2C подписочного приложения, не переносится чисто на B2B инструмент закупок, которым пользуются люди, не выбиравшие этот софт и обижающиеся, что приходится его изучать.
Паттерн, который я чаще всего вижу в агентской работе — исследования вырезают не потому что кто-то решил, что они не ценны, а потому что никто их не запланировал, и таймлайн сомкнулся вокруг их отсутствия. Пять быстрых интервью с пользователями — даже неструктурированных, по звонку — регулярно вскрывают то, что коллективный опыт команды упустил. Ошибка не в незнании — а в подмене памяти о паттернах проверкой, что работает ровно до тех пор, пока паттерн применим.
Процессные ошибки, тихо убивающие проекты
Отдельные экраны редко топят продукт. Провалы процесса — да, потому что они молча накапливаются неделями, прежде чем кто-то замечает, что направление было неверным. Следующие две ошибки меньше про мастерство и больше про то, как опытные дизайнеры структурируют собственную работу — часто пропуская шаги именно потому, что уверены, что могут удержать всю проблему в голове.
Слишком быстрый переход к высокой детализации
Каждый дизайнер знает в теории, что исследование в низкой детализации должно предшествовать отполированным макетам. На практике опытные дизайнеры часто это пропускают, потому что могут выдать правдоподобно выглядящий детализированный экран почти так же быстро, как скетч, а клиенты лучше реагируют на то, что выглядит готовым. Проблема в том, что глянец читается как определённость. Как только клиент или стейкхолдер видит чистый, брендированный макет, он перестаёт оценивать лежащую в основе структуру и начинает комментировать цвета и текст — потому что визуально это уже выглядит одобренным.
Я видел, как это пускало под откос целые сценарии: процесс оформления заказа с фундаментально неудобным порядком шагов утвердили на первом же ревью, потому что он выглядел профессионально, и к тому моменту, когда кто-то заметил структурную проблему, поверх было построено ещё три экрана. Вайрфреймы низкой детализации — не костыль для новичков; это намеренный способ удержать разговор на структуре до того, как чьё-то мнение зафиксируется на визуальных деталях. Пропуск этого этапа ради экономии дня работы регулярно стоит недели позже.
Отсутствие метрик успеха, определённых до начала дизайна
Это ошибку сложнее всего заметить, потому что в моменте ничего не выглядит сломанным. Редизайн выходит, все довольны тем, как он выглядит, а через три месяца кто-то спрашивает «это вообще помогло?», и сравнивать не с чем. Опытные дизайнеры подвержены этому не меньше остальных, потому что уверенность в мастерстве подменяет ответственность за результат — если работа выглядит и ощущается правильной, легко предположить, что она и есть правильная.
Практическое решение скучное, но эффективное: перед началом любой серьёзной работы над редизайном запишите, что конкретно должно измениться и как вы об этом узнаете. Конверсия на конкретном шаге, тикеты в поддержку с конкретным тегом, среднее время завершения, отток на конкретном экране. Не нужен формальный дашборд аналитики — даже одна фраза, согласованная с клиентом до кикоффа («мы будем считать это успехом, если отказ от оформления заказа упадёт ниже X%»), меняет то, как принимается каждое последующее решение, потому что теперь есть к чему проектировать, помимо «выглядит лучше».
Провалы в коммуникации и совместной работе
Дизайн не проваливается в изоляции — он проваливается в точках передачи, в разрывах между тем, что имел в виду дизайнер, и тем, что реально понял разработчик, продакт-менеджер или клиент. Эти ошибки меньше про саму работу и больше про то, как она путешествует, покинув ваш файл.
Представление решений без обоснования
У старших дизайнеров обычно сильная интуиция, а сильная интуиция создаёт соблазн пропустить «почему» и просто представить «что». Это быстрее, и когда вы уверены в направлении, объяснение каждого решения может ощущаться как ненужная опека. Но дизайн, представленный без обоснования, приглашает обратную связь не на том уровне — клиенты и стейкхолдеры начинают реагировать на поверхностные детали, потому что это всё, на что у них есть материал для реакции.
Я видел, как это идёт не так в обе стороны. Иногда клиент возражает против того, что на самом деле было хорошо продуманным компромиссом, и дизайнеру приходится в спешке задним числом обосновывать решение, принятое обдуманно неделями ранее — что читается как оборонительная позиция, а не уверенность. В других случаях клиент быстро одобряет что-то, потому что это было недостаточно понятно, чтобы с этим спорить, и реальный риск в дизайне остаётся неисследованным до запуска. Пройтись по обоснованию — даже кратко, даже для опытных клиентов — это не накладные расходы. Это то, что превращает ревью дизайна в разговор о правильных вещах, а не в референдум по выбору шрифта.
Игнорирование инженерных ограничений до последнего
Эта ошибка усугубляется с опытом, а не уменьшается, потому что опытные дизайнеры обычно работали с достаточным числом способных разработчиков, чтобы начать предполагать реализуемость, а не проверять её. Дизайнер, проведший годы в агентствах с сильными инженерными партнёрами, может прийти в новую команду — может, в стартап с тонким стеком, может, к клиенту с легаси-инфраструктурой — и проектировать так, будто действует тот же технический потолок. Обычно это не так.
Результат — прекрасный сценарий, требующий перестройки модели данных для поддержки, обнаруженной за два дня до дедлайна спринта, и тогда выбор стоит между тем, чтобы выпустить что-то хуже задуманного, или сорвать сроки. Реальное решение здесь — не расплывчатое «вовлекайте разработку раньше», а конкретное: получите техническую оценку любого паттерна взаимодействия, зависящего от данных в реальном времени, сложного состояния или нестандартных компонентов, прежде чем это представят клиенту, а не после того, как это уже одобрено. У одобренных дизайнов есть инерция. Как только клиент сказал «да», откат назад по техническим причинам стоит доверия, даже если ничьей вины в этом нет.
Ловушки визуального и интерактивного дизайна
Ошибки мастерства — это то, что люди ожидают увидеть в подобном списке, но версии, доживающие до старшей работы, тоньше, чем «плохая типографика». Это ошибки, происходящие от сильной визуальной интуиции, применяемой без достаточной сдержанности, или от работы над достаточным числом проектов, чтобы согласованность начала между ними ускользать.
Пере-дизайн: декорация вместо ясности
Чем искуснее вы становитесь с инструментом, тем больше соблазн использовать всё, на что он способен. Тонкие градиенты, слоистые тени, движение на каждом изменении состояния, кастомная иконография для вещей, которым не нужны были кастомные иконки. Ничто из этого не плохо само по себе — ошибка в применении мастерства к вещам, которым оно не нужно, за счёт вещей, которым нужно. Красиво анимированный сценарий онбординга, добавляющий четыре лишние секунды, прежде чем вернувшийся пользователь доберётся до реальной задачи — это не триумф мастерства; это трение в красивом костюме.
Я думаю об этом как о разнице между декорацией и коммуникацией. Декорация делает интерфейс продуманным на вид. Коммуникация делает его пригодным к использованию. Опытные дизайнеры чаще перевкладываются в декорацию именно потому, что хороши в ней, и она красиво фотографируется для портфолио или скриншота на Dribbble — но аудитория кейс-стади и аудитория реального продукта — это разные люди с разными потребностями. Тест, который я использую: если полностью убрать этот визуальный штрих, интерфейс станет менее понятным или просто более простым на вид? Если второе — это, вероятно, декорация, и декорация никогда не должна идти ценой более быстрого, ясного выполнения задачи.
Непоследовательное применение дизайн-системы
Это почти парадоксально: дизайнеры, наиболее склонные нарушать правила дизайн-системы — те, кто её построил, потому что понимают её достаточно хорошо, чтобы точно знать, какие углы «безопасно» срезать. Токен отступа переопределяется для одного экрана, потому что здесь он «просто выглядит лучше». Новый компонент вводится под один частный случай вместо расширения существующего паттерна, потому что построить кастомное быстрее, чем в моменте договариваться с ограничениями существующей системы.
Каждое отдельное исключение защитимо. Накопление — нет. Через полгода в продукте четыре разных стиля карточек, три варианта оформления кнопки, все означающие «основное действие», и документ дизайн-системы, больше не отражающий реальность. Это не проблема документации — это проблема дисциплины, и стоит относиться к каждому исключению «только в этот раз» как к решению, требующему той же строгости, что и постоянное добавление чего-то в систему, потому что на практике именно этим оно обычно и становится.
Бизнес-слепые зоны в работе с клиентами
Последняя категория вообще не про мастерство дизайна — она про суждения, происходящие вокруг работы, где у опытных дизайнеров теоретически больше всего рычагов поступить правильно, а иногда они ими не пользуются.
Неспособность сказать нет плохим запросам
Младшие дизайнеры часто не возражают, потому что ещё недостаточно доверяют собственному суждению, чтобы не согласиться с клиентом. У опытных дизайнеров другая, более дорогая версия того же провала: они знают, что запрос плохой, формулируют почему про себя, а затем всё равно его реализуют, потому что возражение ощущается как риск для отношений, или потому что дедлайн не оставляет места для разговора. Я так делал — строил сценарий, который, как я знал, добавлял ненужный шаг, потому что клиент настоял, наблюдал, как метрики подтвердили мои опасения три месяца спустя, а затем неловко предлагал отменить то, против чего сам советовал, но всё же построил.
Реальный навык здесь — не отказ от запросов, а разделение «я эстетически не согласен» и «это измеримо навредит результату, за улучшение которого мне платят», и приберегание возражений для второй категории, доставленных с прикреплённым обоснованием, в идеале с уже набросанной альтернативой. Клиенты редко напрочь отвергают хорошо обоснованную альтернативу. Они отвергают расплывчатое сопротивление. Сказать «я это сделаю, но хочу зафиксировать, что, по-моему, это добавляет трение на третьем шаге» — более слабая версия того же самого, и её стоит использовать, когда более сильная позиция невозможна — как минимум это защищает доверие к отношениям для следующего разногласия.
Недооценка онбординга, граничных случаев и негламурных 20%
Основной сценарий большинства продуктов получает больше всего дизайнерского внимания, потому что это самая интересная проблема и часть, которая попадает в кейс-стади. Пустые состояния, сообщения об ошибках, экраны отказа в доступе, что происходит, когда у пользователя ноль позиций вместо дюжины из счастливого пути — этому уделяют вечер в конце проекта, если вообще уделяют выделенное внимание. Опытные дизайнеры подвержены этому именно потому, что усвоили, как выглядит «готово» с точки зрения портфолио, а ничего из этих негламурных 20% там не появляется.
Но именно в этих 20% пользователи непропорционально часто и сталкиваются с трением, потому что это места, где у них уже что-то пошло чуть не так — ошибка, растерянность в первый раз, аккаунт, в котором пока ничего нет. Великолепный основной сценарий в паре с общим сообщением об ошибке «Что-то пошло не так» и пустым состоянием без единой подсказки — в целом худший продуктовый опыт, чем более простой основной сценарий с продуманной обработкой граничных случаев повсюду. Аудит того, какие состояния реально спроектированы — не только те, что в основном прототипе — одна из самых результативных проверок, которую лид дизайна может провести перед выпуском проекта, именно потому что это то, что с наибольшей вероятностью было тихо пропущено.
Как поймать эти ошибки до релиза
Ни одна из этих десяти ошибок не экзотична. Опасными их делает то, что каждая в моменте звучит как разумный шорткат — экономия времени, решение из уверенности, «починим потом» — который раскрывается как ошибка только тогда, когда его уже дорого отменять. Паттерн, связывающий их все — опыт заставляет шорткаты казаться безопаснее, чем они есть, потому что вы уже брали похожие шорткаты раньше и вам это сходило с рук.
Несколько привычек ловят большую часть этого до того, как это станет проблемой недели запуска:
- Запишите метрику успеха до начала визуальной работы, а не после — даже одна фраза, согласованная с тем, кто платит за проект.
- Держите хотя бы один проход в низкой детализации перед тем, как что-либо клиентское уйдёт в высокую детализацию, специально чтобы отделить структурные разговоры от визуальных.
- Прикрепляйте абзац с «почему» к каждому крупному дизайн-решению, представляемому клиенту или команде, даже когда уверены, что никто не спросит.
- Получайте техническую проверку на здравый смысл для любого нового паттерна взаимодействия до того, как его представят как одобренный, а не после.
- Проверяйте граничные случаи, пустые состояния и сценарии ошибок как отдельный пункт чек-листа — а не как запасной вариант, если в конце проекта останется время, потому что обычно не остаётся.
- Относитесь к каждому исключению из дизайн-системы как к постоянному добавлению, пока не доказано обратное, и пересматривайте систему ежеквартально против того, что реально выпущено.
Ничего из этого не про то, чтобы стать более осторожным дизайнером — цель не в том, чтобы подвергать сомнению каждый инстинкт, наработанный годами практики. Это про распознавание, какие решения ваш опыт реально заслужил право сокращать, а какие просто так ощущаются, потому что вам стало комфортно. Старшие дизайнеры, чья работа выдерживает проверку временем — не те, кто полностью перестал совершать эти ошибки — а те, кто выстроил вокруг себя достаточно процесса, чтобы поймать их раньше, чем это сделает клиент, пользователь или релиз.
Самые дорогие ошибки в дизайне редко выглядят как ошибки в моменте. Они выглядят как уверенность.
Если вы узнали две-три из этих ошибок в своей недавней работе — это не тревожный знак, а нормальная цена за то, что сделали достаточно проектов, чтобы обзавестись реальными инстинктами. Разница между хорошим старшим дизайнером и великим обычно не в отсутствии этих привычек. Она в наличии процесса, достаточно строгого, чтобы поймать их раньше клиента.
