Вы отправляете ссылку на Figma с чувством выполненного долга, закрываете ноутбук и идете пить заслуженный матча-латте. Но через 10 минут разработчик заходит в ваш чат с лицом человека, который только что увидел привидение или, что хуже, ваш макет.
Спойлер: ваше «авторское видение» просто невозможно реализовать на текущем стеке без литра крови и ведра костылей. В 2026 году интерфейсы стали сложнее, а разрыв между «нарисовано» и «закожено» только увеличился. На dizko.ru мы считаем: дизайн — это не картинка, это инструкция по сборке. И если ваша инструкция заставляет инженера страдать, значит, вы — плохой инструктор.
Разберем 5 грехов дизайнера, которые превращают разработку в ад и плодят технический долг.
1. Хаотичные отступы и «магические числа»
Беда: В одном месте у вас отступ 16px, в другом 17px, а в третьем — внезапно 21.43px, потому что вы тянули фрейм мышкой и «глаз так подсказал».
Почему это плохо: Для разработчика это не «творческий поиск», а системная ошибка. В коде никто не пишет индивидуальный margin для каждой кнопки. Там есть переменные и шаги сетки. Если фронтенд видит margin: 17px, он либо делает костыль, либо (если он молодец) тратит время, чтобы прийти к вам и спросить: «Это баг или фича?».
Как надо: Забудьте про нечетные числа. Ваша библия — 8pt grid system (или 4pt для мелких деталей). Все отступы должны быть кратны 4 или 8. В Figma используйте переменные (Variables) для отступов. Когда разработчик видит в инспекте spacing-m вместо 24px, он понимает, что вы работаете в системе, а не в хаосе.
2. Анимации, игнорирующие законы физики
Беда: Вы собрали в Prototyping сложнейшую анимацию, где пять элементов вылетают из разных углов, меняют прозрачность и схлопываются в один. Выглядит эффектно, но логика движения не описана.
Почему это плохо: В Figma анимация — это часто «магия» перехода между двумя кадрами (Smart Animate). В коде — это математика, кривые Безье и расчет нагрузки на процессор. Если ваш переход требует переписывания всей логики стандартной библиотеки или создания кастомного canvas-решения ради одной иконки — это плохой дизайн. Вы создаете legacy, который будет тормозить приложение на слабых девайсах.
Как надо: Перед тем как рисовать «летающие пиксели», разберитесь, на каком стеке пишется проект. Если это стандартный React Native или Flutter, узнайте возможности их анимационных движков. Описывайте анимацию параметрами: duration, easing, delay. Если можете — дайте ссылку на JSON из Lottie. Будьте инженером, а не мультипликатором.
3. Игнорирование динамического контента
Беда: Вы рисуете карточку товара с идеальным названием «Apple Watch» и коротким описанием. Все выглядит чисто и минималистично.
Почему это плохо: Добро пожаловать в реальный мир. Здесь пользователя зовут Абдурахмангаджи Ибн-Хаттаб, а название товара может быть «Промышленный перфоратор с двойным ударом и набором сверл (модель 2026 года, синий)». Ваша верстка «поплывет», кнопки вылезут за bounding boxes, а текст наложится друг на друга. Это классический провал в работе с dynamic content.
Как надо: Всегда тестируйте макеты на «неудобных» данных.
- Что будет, если заголовок в три строки?
- Что, если цена содержит 10 знаков?
- Как поведет себя блок, если картинка не загрузилась? Используйте Auto Layout 5.0 на максимум: задавайте правила растяжения (Fill, Hug) и минимальные/максимальные ширины. Дизайн должен быть резиновым, а не хрупким.
4. Отсутствие состояний (Empty/Error/Loading)
Беда: Дизайнер рисует «Happy Path» — идеальный сценарий, где интернет летает, сервер отдает данные за 10мс, а в корзине всегда есть товары.
Почему это плохо: Разработчик живет в мире боли. У него есть edge cases: сервер упал, пользователь зашел из подвала с 2G, данных нет вовсе. Если в макетах нет состояния загрузки (Skeleton Screens) или экрана «Ничего не найдено», программист либо придумает их сам (и вам не понравится результат), либо оставит белый экран. Это убивает UX и заставляет допиливать макеты на лету, когда спринт уже горит.
Как надо: Матрица состояний — ваш лучший друг. Для каждого функционального блока должны быть отрисованы:
- Default (обычное состояние).
- Loading (как мы ждем данные).
- Empty (когда данных нет).
- Error (если всё сломалось).
- Hover/Active/Disabled (для интерактивных элементов).
5. Нелогичные сетки и слои (Привет из Windows Forms)
Беда: Макет — это свалка из групп, масок и слоев с названиями Group 534 и Vector 12. Объекты внутри фрейма не привязаны к сетке и ведут себя непредсказуемо при ресайзе.
Почему это плохо: Те, кто помнит Windows Forms, знают: если вы не задали правильные «анкоры» (Anchors) и «докинг» (Docking), ваше окно превратится в кашу при первом же изменении размера. Современная верстка работает так же. Если разработчик видит в Figma мешанину, он не понимает иерархию компонентов. Ему приходится вручную высчитывать, как элементы должны перестраиваться на планшете или десктопе.
Как надо: Группируйте слои по смыслу, а не «чтобы удобнее было двигать». Используйте компоненты и декомпозируйте их. Называйте слои понятно: header, button-primary, input-field. Ваша структура слоев должна практически повторять структуру DOM в HTML. Дизайн — это не куча слоев, это вложенная логика.
Кейс из жизни: Падшие ангелы параллакса
Однажды мой коллега нарисовал «гениальную» идею: при скролле страницы элементы должны были вращаться по оси Z, меняя масштаб в зависимости от положения курсора. Выглядело на видео в After Effects божественно.
На встрече с лидом разработки воцарилась тишина. Оказалось, что проект пишется на старой десктопной библиотеке, где z-index и 3D-трансформации конфликтуют с текущим рендером таблиц. Итог: неделю дизайнер «полировал» идею, которую выбросили в корзину за две минуты обсуждения технического стека. Мораль:Сначала спроси «А мы так можем?», а потом раскрашивай.
Резкий финал
Дизайнер, который не знает, как работает код — это просто визуализатор фантазий. Ваши картинки не имеют ценности, если их нельзя собрать в работающий продукт. Хотите перестать быть «рисовальщиком» и стать проектировщиком?
Откройте хотя бы раз документацию к библиотеке компонентов, на которой пишут ваши коллеги. Посмотрите, как устроены Flexbox и Grid. Поймите, что пиксель — это не точка на экране, а результат выполнения кода.
Хотите, чтобы ваши макеты оживали без боли и криков из соседнего отдела? Подписывайтесь на dizko.ru. Мы учим делать «умный» дизайн, который можно собрать.