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