Home › News

Решение принято, но не реализовано: где ломается процесс между тремя сторонами

05.08.2026

Макет согласован: дизайнер показал решение, заказчик одобрил, разработчик взял его в работу. Через две недели на ревью выясняется, что анимация перехода исчезла, карточки выровнены иначе, а логика фильтрации работает не так, как обсуждали. Никто не саботировал — просто решение растворилось между этапами.

Проблема не в плохой коммуникации как таковой. Проблема в том, что все три стороны по-разному понимают, что значит «решение принято». Дизайнер видит визуальный результат, разработчик — техническую реализацию, заказчик — бизнес-эффект. Если эти интерпретации не сверять, часть смысла легко теряется между этапами.

Три языка, одна комната

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

Первый барьер — отсутствие единого словаря. Когда дизайнер использует термины вроде «воздух», «ритм» или «иерархия», для заказчика это эстетические категории, а для разработчика — нечто, не имеющее технического эквивалента. Решение начинает существовать только тогда, когда оно переведено на язык, понятный всем трем.

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

Когда решение кажется качественным, но таковым не является

Макет может выглядеть безупречно в Figma, но быть нереализуемым в заданных ограничениях. Или реализуемым, но настолько дорогим, что экономика проекта ломается. Качество решения — это не только визуальная или функциональная правильность, но и соответствие контексту.

Чеклист для проверки качества решения перед передачей разработчику:

• Описана ли проблема, которую решение решает? Без формулировки проблемы трудно оценить, насколько решение действительно отвечает задаче.
• Учтены ли технические ограничения платформы? Если целевая платформа не поддерживает нужный тип анимации, решение нужно переформулировать, а не передавать с пометкой «сделайте как-нибудь».
• Является ли решение минимально достаточным? Часто вместо одного точечного изменения предлагают перестроить весь блок, что многократно увеличивает площадь риска.
• Есть ли критерий, по которому можно будет проверить, что решение реализовано верно? Если ответа нет, разработчик будет ориентироваться на собственное понимание.

Уместность: почему хорошее решение может быть неправильным

Не каждое качественное решение уместно в конкретном контексте проекта. Кастомный скроллбар с плавной анимацией — качественное решение для лендинга креативного агентства. То же решение на странице с таблицей из тысячи строк — ошибка, потому что контекст другой.

Ошибочная логика: «Если мы можем это сделать и это выглядит хорошо, значит, нужно делать». Реальная логика: «Это решает проблему пользователя в рамках нашего контекста и не создаёт новых проблем».

Заказчик часто не видит разницы между уместным и неуместным решением, потому что оценивает макет изолированно — на презентации, вне реального использования. Дизайнер должен проговаривать контекстные ограничения вслух: «Это решение подходит для десктопа, но на мобильных мы упростим логику, потому что...» — и получать подтверждение именно на этот компромисс.

Ограничения, которые нужно озвучивать до утверждения

Частая ошибка — скрывать ограничения до этапа разработки. «Да, мы можем сделать такую анимацию» — звучит как согласие, но подразумевает «мы можем, но это займёт втрое больше времени и потребует дополнительной библиотеки». К моменту, когда эта информация всплывает, решение уже утверждено, и откат выглядит как саботаж.

Формат, который работает: к каждому предложенному решению прикладывать краткую карточку ограничений. Не техническую спецификацию — три-четыре строки о том, что именно придётся пожертвовать. Это позволяет заказчику принимать решения осознанно, а разработчику — понимать реальную площадь задачи.

Механика передачи: как решения физически не теряются

Хорошее решение, описанное в комментариях к макету, всё равно может потеряться. Комментарии — это хранилище мнений, а не решений. Решение лучше фиксировать в формате, к которому команда действительно обращается во время разработки и приёмки.

Что практически работает:

1. Единый источник правды — не рассинхронизированные комментарии в Figma, переписка в мессенджере и протокол встречи, а один документ, где зафиксированы все принятые решения с привязкой к конкретным экранам и элементам.
2. Формулировка «что делаем, а не чего избегаем» — вместо «не делайте ло раньше» пишут «делайте так:...». Отрицательные формулировки оставляют слишком много пространства для интерпретации.
3. Привязка к критериям приёмки — каждое решение превращается в проверяемый пункт. Не «кнопка должна быть заметной», а, например, «текст на кнопке соответствует требованию WCAG AA по контрастности для обычного текста, а размеры и расстояния между интерактивными элементами проверяются по принятому в проекте критерию доступности».
4. Промежуточные точки согласования — не ждать финальной реализации, чтобы обнаружить отклонение. Договориться о том, на каком этапе разработчик покажет черновой результат для проверки направления.

Что делать, когда решение нужно изменить в процессе

Идеальный процесс предполагает, что все решения приняты до разработки. Реальный процесс — это постоянные корректировки. И вот здесь кроется основная ловушка: изменение решения без обновления контекста.

Пример: в процессе разработки заказчик решает заменить текстовые фильтры на чипсы. Дизайнер обновляет макет. Но разработчик не знает, что изменилась не только визуальная форма — изменилась логика: теперь пользователь может выбрать несколько значений одновременно, а раньше — только одно. Если это не проговорено, разработчик реализует чипсы с логикой одиночного выбора, потому что старая логика никуда не исчезла из его головы.

Правило: любое изменение решения должно сопровождаться кратким описанием того, что именно меняется в поведении, а не только во внешнем виде. Без этого разработчик будет дорабатывать старую логику под новый дизайн.

Критерии здорового процесса

Понять, что процесс выстроен правильно, можно по нескольким индикаторам. Если на ревью разработчик показывает результат, который визуально и функционально совпадает с ожиданиями дизайнера и заказчика — это не заслуга отдельного исполнителя, это показатель процесса. Если такие совпадения случайны — процесс сломан.

Дополнительные маркеры:

• Уточняющие вопросы появляются до реализации, а не только после неё. Это хороший признак: разработчик вовлечён в контекст и может заранее подсветить неоднозначные места.
• Заказчик реже просит «сделать ло на презентации», потому что понимает, что презентация и реализация — разные контексты.
• Дизайнер перестаёт быть единственным защитником пользовательского опыта — разработчик тоже начинает задавать вопросы о поведении, а не только о пикселях.

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