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