Когда прототип уже выглядит как настоящий сайт, возникает очень опасное ощущение: кажется, что большая часть фронтенда уже сделана. Кнопки нажимаются, блоки двигаются, адаптив работает, анимации живут. Значит, осталось только подключить данные и выложить проект. На практике именно в этот момент начинается самая неприятная часть работы - выясняется, что визуально убедительный прототип и система, которую можно спокойно развивать, это разные вещи.
Прототип отвечает на другой вопрос
Главная задача хорошего прототипа - доказать идею. Он показывает композицию, поведение интерфейса, настроение, основные сценарии и то, как пользователь воспринимает продукт. Ради скорости в нем совершенно нормально принимать локальные решения: быстро собрать блок, жестко задать размеры, временно повторить стили, написать простой обработчик прямо рядом с элементом. Пока мы ищем форму продукта, это не недостаток, а нормальная цена эксперимента.
Проблема начинается, когда экспериментальный код без переходного этапа становится основой рабочего продукта. То, что помогало быстро менять концепцию, начинает мешать поддержке. Один и тот же цвет оказывается записан в десятке мест, похожие карточки ведут себя немного по-разному, состояние элемента определяется случайной связкой классов, а изменение одной страницы неожиданно ломает другую.
Разработчику недостаточно увидеть результат
Когда другой человек открывает готовый прототип, он видит итог, но не видит систему решений, которая к нему привела. Почему у двух кнопок одинаковый радиус? Это правило или совпадение? Почему один отступ 24 пикселя, а соседний 22? Так задумано или просто осталось после нескольких правок? Какие элементы должны стать общими компонентами, а какие действительно уникальны?
Если на эти вопросы не ответить заранее, разработчик вынужден заниматься археологией. Он восстанавливает правила по внешнему виду. Два разных разработчика могут восстановить их по-разному - и оба будут логичны. В результате визуально единый прототип превращается в несколько несовместимых трактовок.
Нужен промежуточный слой
В TRUE VISUAL мы пришли к тому, что между прототипом и полноценной разработкой должен существовать отдельный пакет передачи. В него входят компоненты, состояния, дизайн-токены, правила тем, адаптивное поведение, описание интерактивных элементов и границы допустимых изменений. Цель не в том, чтобы заранее написать разработчикам их код. Наоборот, стек может быть любым. Нужно передать не реализацию, а логику продукта.
Поэтому хороший пакет не говорит: "используйте такую-то библиотеку и такую-то архитектуру". Он говорит: "вот сущности интерфейса, вот их состояния, вот общие правила, вот исключения, вот ожидаемое поведение". Техническая команда уже выбирает способ реализации.
Когда прототип действительно можно считать основой фронтенда
Сам по себе HTML не делает прототип фронтендом. Гораздо важнее другое: можно ли изменить системное правило в одном месте и получить предсказуемый результат по всему продукту; понятно ли, где заканчивается компонент и начинается конкретная страница; отделены ли данные и состояния от декоративной разметки; описаны ли адаптивные сценарии; можно ли передать проект другой команде без устного экскурсовода.
Если ответы положительные, прототип становится хорошим технологическим фундаментом. Если нет, он все равно остается ценным - просто его ценность находится в другом месте. Он является точной моделью продукта, по которой еще предстоит построить производственную систему.
Мы перестали воспринимать прототип как недоделанный сайт. Это самостоятельный этап проектирования. Чем честнее проведена граница между экспериментом и производственным решением, тем меньше приходится переписывать потом.