Прототип сайта на Тильде нельзя рассматривать только как черновик будущего дизайна. На связи Марков Вадим из команды marmelad.digital, и в этой статье я разберу, какие ограничения платформы стоит учитывать до визуального макета и сборки.
Тильду часто воспринимают как инструмент, где можно быстро собрать сайт из готовых блоков. Это правда, когда структура заранее ложится на логику платформы. Но если сначала нарисовать свободный макет, а потом пытаться перенести его в конструктор без учета стандартных блоков, Зеро-блока, адаптива, форм, SEO-структуры и будущего редактирования, скорость быстро исчезает.
На прототипе почти все выглядит нормально. Шапка ровная, первый экран понятный, карточки одинаковые, форма короткая, блок вопросов аккуратный. Потом появляется реальный контент, мобильная версия, длинные заголовки, несколько типов услуг, заявки, интеграции, SEO-страницы - и часть решений приходится пересобирать.
Это не особенность только Тильды. Любая платформа задает свои рамки. Просто в конструкторе эти рамки лучше учитывать раньше: не на сборке, не после дизайна, а в момент прототипирования.
Что меняется, когда сайт собирается на Тильде
В абстрактном прототипе достаточно показать структуру страницы, основные блоки и пользовательский сценарий. Для сайта на Тильде этого мало. Нужно понимать, из чего конкретно будет собрана страница.
Условно есть несколько типов решений: стандартные блоки, Зеро-блок, формы, каталог, HTML-вставки, внешние сервисы и настройки самой страницы. У каждого способа своя цена. Стандартный блок быстрее собрать и проще поддерживать. Зеро-блок дает больше свободы, но требует внимательнее работать с адаптивом. HTML-вставка позволяет добавить собственный код через блок T123 , но это уже отдельная зона ответственности.
Поэтому нормальный прототип для Тильды должен отвечать не только на вопрос «что будет на странице». Он должен показывать, каким способом это будет собрано, где будут ограничения, кто будет редактировать контент после запуска и какие места нельзя оставлять на усмотрение верстальщика.
Стандартные блоки и Зеро-блок нужно разделять еще в прототипе
На раннем этапе легко нарисовать страницу как свободную композицию: здесь карточки, там текст, поверх фотография, рядом кнопка, ниже нестандартная сетка. В статичном прототипе это выглядит безобидно. Но в Тильде любое решение рано или поздно превращается в выбор способа сборки.
Стандартные блоки подходят для типовых секций: обложка, карточки, преимущества, этапы, форма, вопросы и ответы, контакты, таблица, меню, подвал. Их проще обновлять, особенно если после запуска сайтом занимается клиент или контент-менеджер без опыта работы с дизайном.
Зеро-блок нужен там, где стандартной структуры недостаточно: сложная композиция, нестандартная типографика, своя сетка, наложения, индивидуальные карточки, анимации.
В прототипе стоит сразу помечать тип секции:
Секция | Предполагаемый способ сборки | Почему так |
|---|---|---|
Первый экран | Зеро-блок | нужна нестандартная композиция |
Список услуг | стандартный блок | карточки будут часто редактироваться |
Форма заявки | стандартная форма | важны интеграции и стабильность |
Сложная схема процесса | Зеро-блок | нужна ручная композиция |
Встроенная карта или виджет | HTML-вставка | используется внешний код |
Вопросы и ответы | стандартный блок | секцию удобно поддерживать |
Эта таблица полезна команде, чтобы не спорить об очевидном уже на сборке.
Мобильную версию нельзя откладывать до сборки
Одна из частых ошибок — согласовать прототип и дизайн в десктопе, а мобильную версию «разобрать потом». Для Тильды это рискованно, особенно если используются Зеро-блоки.
В стандартных блоках адаптив обычно предсказуемее. В Зеро-блоке приходится внимательнее следить за контейнерами, высотой блока, поведением элементов и версиями для разных экранов. В Зеро-блоке есть рабочие области Grid Container и Window Container, а для разных устройств используются свои размеры сетки.
На прототипе нужно проверить хотя бы проблемные места:
Элемент | Что проверить на мобильной версии |
|---|---|
Первый экран | не занимает ли заголовок весь экран |
Меню | помещаются ли разделы и вложенность |
Карточки | не становятся ли слишком длинными |
Таблицы | можно ли читать без горизонтального хаоса |
Форма | не превращается ли в длинный опросник |
Зеро-блок | не мешают ли декоративные элементы тексту |
Подвал | не выглядит ли как свалка ссылок |
Мобильный прототип не обязан повторять всю страницу в полном объеме. Но ключевые экраны нужно показать: первый экран, меню, карточный блок, форму, длинную текстовую секцию и подвал.
Контент нужно подставлять до дизайна
Пустой прототип почти всегда выглядит аккуратно. Прямоугольники не спорят с сеткой, короткие заголовки не переносятся на три строки, карточки одинаковые, а кнопки занимают ровно столько места, сколько нужно.
С реальным контентом все иначе.
Например, карточка мероприятия может включать название лекции, дату, время, формат, имя спикера, отметку о количестве мест и кнопку записи. Если на прототипе эта карточка была обозначена как «заголовок, текст, кнопка», команда не увидит будущую высоту блока. Потом это всплывет в дизайне или уже при сборке.
Для Тильды это особенно важно из-за поддержки. Если контент будет часто меняться, лучше выбирать решения, где редактор может безопасно заменить текст, добавить карточку или поменять порядок элементов. Если вся секция собрана как сложная композиция в Зеро-блоке, обычная контентная правка может превратиться в ручную работу по нескольким разрешениям.
В прототипе лучше использовать не финальные тексты, а рабочие тексты нормальной длины:
Что подставлять | Зачем |
|---|---|
реальные заголовки | проверить переносы и высоту блоков |
реальные названия разделов | понять размер меню |
полный состав карточек | проверить сетку и мобильную версию |
реальные поля формы | оценить длину сценария |
вопросы для блока ответов | увидеть объем текстовой части |
юридические примечания | понять, где они должны жить |
SEO-фрагменты | не добавлять текст в последний момент |
На этом этапе прототип становится менее красивым. Зато он ближе к сайту, который действительно придется собирать.
Форму заявки нужно проектировать как отдельный сценарий
Форма в прототипе часто выглядит слишком просто: имя, телефон, кнопка.
В реальном проекте форма — это не один блок, а сценарий.
Нужно заранее понять:
Вопрос | Что фиксировать в прототипе |
|---|---|
какие поля нужны | имя, телефон, тип услуги, комментарий |
какие поля обязательные | чтобы не перегрузить форму |
куда уходят заявки | почта, CRM, таблица, другой сервис |
что видит пользователь | сообщение об успехе или ошибке |
нужна ли страница благодарности | для аналитики и понятного завершения |
что происходит при повторной отправке | чтобы не плодить дубли |
На прототипе стоит показать не только нормальное состояние формы, но и ошибки: не заполнено поле, неправильный телефон, не выбран тип услуги, заявка отправлена, заявка не отправлена.
Повторяемые сущности лучше описывать как структуру
На сайте услуг почти всегда есть повторяемые сущности: услуги, тарифы, отзывы, вопросы, заявки. В прототипе они выглядят как карточки. Для сборки важнее понять, как эти карточки будут обновляться.
Если услуг мало, их можно вести вручную. Если услуг много, появляются вопросы: нужна ли отдельная страница услуги, нужен ли список, нужны ли фильтры, как связаны услуги и тарифы, как передавать выбранную услугу в форму.
В Тильде для повторяемых товарных сущностей есть Каталог товаров, фильтры, параметры и варианты. Фильтры настраиваются через интерфейс каталога и могут использовать параметры товара, характеристики, наличие, категории и другие свойства. Но для обычного сайта услуг каталог не всегда нужен. Иногда проще сделать отдельные страницы услуг и аккуратную перелинковку.
На прототипе можно описать структуру так:
Сущность | Поля | Где используется |
|---|---|---|
Услуга | название, описание, состав, срок, цена от | главная, страница услуги, форма |
Тариф | название, что входит, стоимость, ограничение | блок стоимости |
Отзыв | текст, имя, описание клиента | блок отзывов |
Заявка | имя, телефон, тип услуги, комментарий | форма и CRM |
Вопрос | вопрос, ответ, связанная услуга | FAQ |
SEO-структуру нужно закладывать до сборки
Сайт начинают с главной страницы. Потом появляются отдельные услуги, страницы под разные запросы, статьи, FAQ, сравнения, дополнительные посадочные. Если это не продумать заранее, структура быстро становится случайной.
На этапе прототипа нужно зафиксировать:
Что проектируем | Что должно быть понятно |
|---|---|
главная страница | какие интенты она закрывает |
страницы услуг | чем они отличаются друг от друга |
блоки FAQ | какие вопросы закрывают сомнения пользователя |
перелинковка | куда ведут карточки и связанные услуги |
текстовые зоны | где будет полезный контент |
метаданные | H1, Title, Description, ЧПУ |
расширение | как добавлять новые страницы без хаоса |
Для сайта услуг SEO-страница — это полноценная страница с понятной структурой: заголовок, объяснение услуги, состав, стоимость, этапы, вопросы, связанные услуги, заявка.
Кастомный код нужно отмечать отдельно
Тильда позволяет добавлять собственный код, и это нормально для точечных задач: виджет, небольшая интерактивная логика, событие аналитики, внешний скрипт, карта, калькулятор.
В прототипе любое место с кодом нужно помечать отдельно. Не просто «интерактивный блок», а конкретно: что делает код, от чего зависит, кто будет поддерживать, что нужно проверить после правок.
Пример для нейтрального сайта услуг:
Зона | Что делает код | Риск |
|---|---|---|
калькулятор стоимости | считает примерную цену | формула должна быть понятна |
событие аналитики | фиксирует отправку заявки | нужно проверить после публикации |
интерактивная зона обслуживания | показывает доступность услуги | возможна зависимость от внешнего сервиса |
карта | встраивается через внешний код | может влиять на скорость |
виджет обратной связи | подключается сторонним сервисом | нужен контроль работоспособности |
Пример структуры главной страницы
Для нейтрального сайта услуг главная страница может быть простой:
Блок | Задача |
|---|---|
Шапка | дать навигацию по основным разделам |
Первый экран | объяснить, что это за услуги и куда нажать |
Услуги | показать основные направления |
Преимущества | закрыть базовые сомнения |
Как работаем | объяснить процесс |
Отзывы | добавить социальное подтверждение |
Стоимость | показать порядок цен или тарифов |
Форма заявки | собрать обращение |
FAQ | снять частые вопросы |
Контакты | дать способы связи |
Подвал | служебные ссылки и повтор навигации |
В прототипе важно показать это не как набор одинаковых прямоугольников, а как страницу с рабочей логикой: где основной сценарий, где поддерживающий контент, где технические ограничения, где пользователь принимает решение.
Пример структуры страницы услуги
Отдельная страница услуги нужна, когда одной карточки на главной недостаточно. На ней пользователь должен понять, что входит в услугу, сколько это стоит, как проходит работа, какие есть ограничения и что делать дальше.
Блок | Что фиксировать |
|---|---|
Первый экран | название услуги, короткое описание, кнопка |
Что входит | список работ или состава услуги |
Этапы | понятная последовательность |
Стоимость | таблица или карточки |
Ограничения | что не входит или требует уточнения |
FAQ | вопросы именно по этой услуге |
Похожие услуги | внутренняя перелинковка |
Форма | передача названия услуги в заявку |
Что должно быть в рабочем прототипе
Прототип для сайта на Тильде не обязан выглядеть как почти готовый дизайн.
На этом этапе важнее ясность.
Минимальный состав:
Слой | Что фиксировать |
|---|---|
Структура | страницы, порядок блоков, навигация |
Контент | реальные по длине заголовки, карточки, поля формы |
Сборка | стандартный блок, Зеро-блок, форма, код |
Адаптив | ключевые мобильные экраны |
Формы | поля, ошибки, результат отправки, интеграции |
SEO | H1, Title, Description, ЧПУ, перелинковка |
Поддержка | кто редактирует сайт после запуска |
Риски | места, где нужна проверка до дизайна |
Итог
Прототип сайта на Тильде должен фиксировать не только будущий интерфейс. В нем должны быть способ сборки, реальные объемы контента, мобильная логика, форма заявки, SEO-структура, повторяемые сущности, места с кастомным кодом и зоны риска.
Тильда ускоряет работу, когда проект учитывает ее механику. Если игнорировать платформу на этапе прототипа, скорость уходит на сборке: появляются переделки, спорные решения, ручная поддержка и попытки догнать макет, который изначально проектировался без учета инструмента.
Поэтому прототип для Тильды лучше делать немного сухим: с пометками, таблицами, состояниями, реальными текстами и мобильными экранами.
На презентации это выглядит менее эффектно. На сборке за это обычно говорят спасибо.