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