Согласование сайта происходит несколько раз: сначала утверждается структура, потом прототип, затем дизайн, функциональность и в конце готовый сайт. На каждом этапе принимаются свои решения, и следующий этап на них опирается. Поэтому сроки зависят не только от скорости разработки, но и от того, как устроено согласование: сколько длится каждое, сколько в нем кругов правок и не возвращается ли проект к уже принятым решениям.
Если этот порядок понятен с самого начала, согласование перестает быть узким местом. Ниже о том, что утверждать на каждом этапе, как собирать замечания и как отличить исправление ошибки от изменения решения.
Что утверждается на каждом этапе
Структура
На этом этапе решается, какие страницы и разделы будут на сайте, как они связаны и что находится в меню. Это самый дешевый момент для изменений: страниц еще нет, поменять их состав можно за один разговор.
Проверить стоит главное: все ли услуги или категории на месте, понятно ли, куда пойдет человек с главной, нет ли лишних разделов. Утвержденная структура становится основой для всего остального.
Прототип
Прототип показывает, какие блоки будут на страницах и в каком порядке, без окончательного дизайна. Здесь согласуется логика: что человек видит первым, где цена, где форма заявки, какие вопросы закрывает каждый блок.
На прототипе удобно спорить о порядке и содержании, потому что внимание не отвлекают цвета и картинки. Поправить порядок блоков проще всего именно здесь.
Дизайн
Дизайн-макет добавляет к прототипу визуальный стиль: шрифты, цвета, фото, графику, детали. Обычно сначала согласуется одна ключевая страница, чаще главная, а потом по ее образцу оформляются остальные.
Здесь важно смотреть не только на компьютерную версию. Как макет выглядит на телефоне, лучше обсудить на этом же этапе, а не после сборки.
Функциональность
Формы, квизы, калькуляторы, каталог, оплата, интеграции — все, что работает, а не только выглядит. Здесь согласуется поведение: куда уходит заявка, что видит человек после отправки, как считается цена, что происходит при ошибке.
Эти решения удобнее проверять на работающей версии, а не на картинке. Поэтому функциональность часто согласуется уже на собранных страницах.
Готовый сайт
На последнем этапе проверяется сайт целиком: тексты, ссылки, формы, отображение на разных экранах. Это время для исправления ошибок и мелких доработок, а не для пересмотра структуры или стиля.
Почему нужен один список замечаний
Замечания, присланные по одному в разное время и в разные каналы, трудно собрать в картину. Одно сообщение пришло в мессенджер, второе на почту, третье голосом, и два из них противоречат друг другу. Чтобы ничего не потерять, их все равно приходится сводить в один список, только позже.
Удобнее сразу собирать замечания в одном документе или таблице и передавать их одним пакетом после просмотра этапа. Тогда видно все целиком, противоречия заметны заранее, а работа над правками идет одним заходом, а не десятью мелкими.
Способ передачи может быть любым: текст, голосовое сообщение, запись экрана с комментариями. Длинную запись я сама разбираю в список задач, спорные пункты уточняю отдельно и только потом вношу изменения. Главное, чтобы замечания по одному этапу приходили вместе.
Для каждого замечания полезно указать место (страница и блок), что не так и, если есть идея, как исправить. Если правка важная, а не вкусовая, это тоже стоит отметить.
Зачем один ответственный со стороны заказчика
Когда на макет смотрят несколько человек, у каждого свое мнение. Это нормально и даже полезно, но если разработчик получает замечания от всех напрямую, он вынужден выбирать между ними сам. А выбор между директором и маркетологом — не его решение.
Поэтому со стороны заказчика лучше назначить одного человека, который собирает замечания коллег, снимает противоречия и передает итоговый список. Он же утверждает этап. Это не значит, что мнение остальных не учитывается: просто договариваться внутри компании проще, чем через разработчика.
Хорошо, когда этот человек может принимать решения или быстро получать их. Если каждое утверждение ждет согласования у руководителя, который смотрит макет раз в неделю, проект будет идти в его темпе.
Ошибка или изменение решения
Это различие влияет на сроки и смету, поэтому его полезно понимать с обеих сторон.
Ошибка — это когда сделано не то, о чем договорились. Неправильная цена, не тот телефон, блок, который в макете был, а на сайте пропал, форма, которая не отправляется. Исправление ошибок входит в работу.
Изменение решения — это когда сделано то, что согласовали, но теперь хочется по-другому. Новый блок в утвержденном макете, другой порядок разделов после сборки страниц, замена одобренных фотографий, новая функция. Это нормальная часть жизни проекта, но это новый объем работ: его нужно оценить и согласовать до выполнения.
Граница иногда неочевидна. Если сомневаетесь, к чему относится правка, просто спросите. Мне проще сразу сказать, что это изменение и сколько оно займет, чем разбираться потом. Все дополнительные работы, как сказано на странице услуг и цен, согласовываются до выполнения.
Сколько кругов правок нормально
Точного числа нет, и обещать, что одного согласования всегда хватит, было бы нечестно. Обычно правки на каждом этапе сходятся за несколько итераций, если замечания приходят списком, а решения не пересматриваются.
Сильнее всего согласование затягивают правки, которые меняют уже выбранное направление. Десять мелких замечаний в одном списке обрабатываются быстрее, чем одно, которое меняет направление дизайна. Поэтому крупные вопросы лучше поднимать раньше, на структуре и прототипе, а на дизайне и готовом сайте оставлять детали.
Как может выглядеть список замечаний
Условный пример для этапа дизайна. Формат удобно вести в таблице, которую видят обе стороны.
| Страница и блок | Что не так | Предложение | Тип |
|---|---|---|---|
| Главная, первый экран | Заголовок теряется на фото | Затемнить фото или сдвинуть текст | Правка дизайна |
| Услуги, карточки | Неверная цена у второй услуги | Исправить по актуальному прайсу | Ошибка в данных |
| Контакты | Нет схемы проезда | Добавить карту | Новый элемент |
Последний столбец помогает сразу увидеть, что относится к исправлениям, а что к новым задачам. Если после запуска правки продолжаются, их удобно передавать тем же списком: так устроена доработка сайта на Тильде — какая страница, что изменить и какие материалы использовать.
Если вы планируете сайт и хотите заранее понять, как будет устроено согласование именно в вашем проекте, опишите задачу в квизе на сайте. Я отвечу лично и расскажу, какие этапы и точки согласования будут у вас.