Правки появляются не из-за того, что все ленивые
Опубликовано: 06.08.2026
Макет утверждён, дизайнер выдохнул, проект ушёл в разработку. Через три недели выясняется, что кнопка не помещается на мобильном, условия лицензии шрифта не подходят для выбранного способа использования, а анимация, которая выглядела изящно в Figma, на реальном устройстве тормозит. И начинаются переделки — дорогие, нервные, растягивающие сроки.
Обычно в таких ситуациях винят дизайнера. Реже — разработчика. На самом деле проблема не в людях, а в том, когда именно проверяются решения. Если критичные вопросы всплывают после старта вёрстки, это не ошибка исполнителя. Это системный сбой процесса.
Иллюзия завершённости
Пиктограммы в Figma лежат ровно. Текст обтекает картинки. Всё выглядит собранным и логичным. Но макет — это декорация, а не здание. Декорация не должна выдерживать ветер, а интерфейс — реальные данные, реальные устройства, реальные пальцы на стекле. Чем раньше команда проверяет решения на реальных ограничениях, тем дешевле исправить ошибку. С этим подходом стоит сверять и остальные этапы процесса, прежде чем разработка станет слишком дорогой для экспериментов.
Проблема усугубляется тем, что утверждение макета воспринимается как финал дизайнерской стадии. Закрыли задачу — пошли дальше. Но макет утверждён визуально, а большинство критичных проблем — структурные, технические, логические. Их не видно глазом.
Что именно обычно всплывает поздно
Если разобрать типичные постфактум-правки, они группируются в несколько категорий:
- Масштабирование контента. В макете стоит «Заголовок» из двух слов. В реальности заголовок — три строки. Блок разваливается, верстальщик импровизирует, результат отличается от замысла.
- Состояния, которых нет. Есть обычная кнопка. Нет состояния наведения, нажатия, отключённой кнопки, загрузки. Разработчик делает это на свой вкус.
- Адаптив, нарисованный задним числом. Десктоп продуман детально, а мобильный — сжатая копия с обрезанными блоками. На маленьком экране пользователь не может выполнить ключевое действие.
- Несовместимость с технологиями. Сложная тень, многослойный градиент, нестандартный шрифт — всё это выглядит прекрасно, но рендерится секунду на бюджетном смартфоне.
- Отсутствие логики переходов. Понятно, как выглядит экран, но непонятно, куда ведёт кнопка, что происходит после отправки формы, как выглядит ошибка валидации.
Как проверять до разработки
Нужно не больше времени, а другой тип внимания. Вот несколько рабочих подходов, которые не требуют отдельной стадии и сложных инструментов.
Реальные данные вместо заглушек
Хотя бы для ключевых экранов — заполнить формы настоящими фамилиями, вставить реальные заголовки из контент-плана, положить настоящие картинки, а не серые прямоугольники. Это моментально обнажает проблемы масштабирования и позволяет увидеть, где тексту тесно.
Проверка крайних состояний
Простая привычка: для каждого интерактивного элемента проговорить или набросать, как он выглядит в каждом состоянии. Кнопка в обычном виде, при наведении, при нажатии, когда отключена, когда внутри идёт спиннер загрузки. Поле ввода — пустое, с фокусом, с ошибкой, с подсказкой, с длинным текстом. Это занимает пятнадцать минут, но экономит часы переписки в чате с разработчиком.
Тестирование на реальном устройстве
Не на мониторе 27 дюймов, не в режиме предпросмотра Figma, а именно на телефоне. Открыть макет, отмасштабировать до реального размера, попробовать тапать пальцем. Мелкие ссылки, тесно расположенные элементы, нечитабельный текст — всё это становится очевидным за минуту.
Внутренний ревью с вопросом «а что если»
Перед передачей макета показать его коллеге — не для красоты, а для стресс-теста. Коллега должен задавать деструктивные вопросы. Что если имя пользователя состоит из сорока символов? Что если нет интернета? Что если список пуст? Что если пользователь нажмёт «назад» на этом шаге? Ответы на эти вопросы либо уже лежат в макете, либо становятся задачами.
Синхронизация с разработчиком до старта
Не формальная передача макета по почте, а живой разбор. Разработчик смотрит и сразу говорит: «Эта анимация будет тормозить», «Этот компонент не существует в нашей библиотеке», «Здесь нужен бэкенд, которого ещё нет». Десять минут разговора предотвращают недели правок.
Хороший дизайн-процесс — это не когда макет красивый, а когда от макета до работающего продукта путь прямой и предсказуемый.
Почему этим часто пренебрегают
Причины бытовые. Дедлайны давят, заказчик торопит, «давайте уже запускать». Проверка состояний кажется рутиной. Разговор с разработчиком — лишняя координация. И в результате экономия на ранней проверке может обернуться значительно более дорогими переделками после начала разработки, когда изменение уже затрагивает код, тестирование и несколько участников команды.
Ещё один скрытый фактор — психологический. Когда макет готов, он выглядит законченным. Автору хочется закрыть задачу и перейти к следующей. Возвращаться к нему и искать слабые места — значит признать, что он не идеален. Это неприятно, и мозг сопротивляется.
Норма, а не перестраховка
Проверка дизайн-решений до разработки — нормальная часть профессионального процесса. Чем раньше команда проверяет состояния, реальные данные, ограничения платформы и спорные сценарии, тем дешевле обычно обходится корректировка решения.
Переделки не исчезнут совсем. В любом нетривиальном проекте что-то поменяется по ходу. Но есть большая разница между небольшой правкой и перестройкой структуры экрана уже после начала разработки. Ранние проверки нужны прежде всего для того, чтобы чаще оставаться в первой категории.
