Ошибки при заказе сайта: что приводит к переделкам

Ошибки при заказе сайта возникают не только из-за неудачных технических решений.

Часть проблем появляется со стороны самого заказчика:

• решения согласуют несколько человек без общего ответственного,
• реальные материалы передают слишком поздно,
• правки приходят из разных каналов,
• а новые требования добавляют после утверждения структуры и дизайна.

В результате команда возвращается к уже сделанной работе, сроки сдвигаются, а первоначальный проект постепенно меняется.

Заказчику при этом не нужно разбираться в программировании или самостоятельно проектировать сайт. Его задача проще, дать команде достоверную информацию о бизнесе, вовремя принимать решения и отделять обязательные требования от пожеланий, которые появились уже по ходу работы.

Ошибка 1. Смотреть только на итоговую цену

Низкая стоимость сама по себе не говорит о плохой разработке. Ошибка возникает, когда предложения сравнивают только по последней строке сметы, не выясняя, какой объём работ стоит за каждой суммой.

В одном проекте могут быть учтены структура, дизайн внутренних страниц, мобильная версия, работа с контентом, аналитика и запуск. В другом часть этих задач оплачивается отдельно.

Критерии сравнения подробно разобраны в материале о том, как выбрать веб-студию и что проверить до договора. Для самого проекта важно заранее понимать, какой результат входит в согласованный объём.

Ошибка 2. Нет человека, который принимает итоговое решение

Сайт часто обсуждают директор, маркетолог, отдел продаж и другие сотрудники. Это нормально, пока понятно, кто собирает их мнения и принимает окончательное решение.

Проблемы начинаются, когда один участник просит сократить первый экран, другой хочет добавить туда ещё несколько смыслов, а третий через неделю возвращает первоначальный вариант. Исполнитель не может самостоятельно определить, чьё мнение считать главным.

Со стороны заказчика нужен человек, который собирает обратную связь внутри компании и передаёт команде согласованную позицию. Для отдельных вопросов он может привлекать маркетолога, технического специалиста или руководителя продаж, но итоговое решение не должно каждый раз начинаться заново.

Чем больше людей участвует в проекте, тем важнее заранее определить, кто собирает их замечания и принимает окончательное решение.

Ошибка 3. Пытаться сделать один сайт одинаково важным для всех

Компания может работать с несколькими типами клиентов:

• розницей,
• оптовиками,
• корпоративными заказчиками,
• дилерами. 

Ошибка не в количестве аудиторий, а в попытке одновременно сделать каждую из них главной.

В итоге на одной странице смешиваются разные предложения, аргументы и сценарии. Посетителю сложнее понять, относится ли информация к его ситуации и что делать дальше.

До проектирования стоит определить приоритетные группы клиентов и основные действия для каждой из них. Если ясности пока нет, полезно сначала определить бизнес-цели сайта и его роль для компании.

Остальные аудитории при этом не обязательно исключать. Для них можно предусмотреть отдельные страницы и маршруты внутри общей структуры.

Ошибка 4. Откладывать реальный контент до готового дизайна

Структуру и дизайн невозможно полностью отделить от содержания.

На этапе прототипа может казаться, что для услуги достаточно небольшого описания и формы. Позже выясняется, что клиентам нужны технические характеристики, документы, несколько вариантов решения, фотографии объектов или подробные кейсы.

Если эти материалы появляются после утверждения макета, часть страницы приходится проектировать заново.

Не обязательно приходить к разработчику с полностью написанным сайтом.

Но состав информации желательно понимать заранее:

• какие есть услуги или товары,
• фотографии,
• характеристики,
• документы,
• кейсы,
• цены и другие материалы.

Подробнее об этом рассказано в статье что подготовить из контента до разработки сайта.

Ошибка 5. Передавать правки кусками и по разным каналам

Несколько сообщений утром, письмо вечером, голосовое от руководителя и ещё один список через два дня легко превращаются в противоречащие друг другу указания.

Команде становится трудно понять итоговый смысл правок.

Например, один комментарий требует увеличить блок. Позже другой сотрудник предлагает удалить информацию, ради которой блок увеличивали. Исполнитель успевает сделать первую правку, а затем возвращается назад.

Обычные замечания удобнее собирать по этапу и передавать одним согласованным пакетом. Так противоречия можно заметить до того, как начнётся повторная работа.

Ошибка 6. Согласовывать дизайн только по принципу «нравится или не нравится»

Личное впечатление заказчика имеет значение. Сайт должен соответствовать компании и её позиционированию. Но одной оценки «нравится» или «не нравится» недостаточно, чтобы команда поняла причину правки.

Фраза «хочется ярче» может означать совершенно разные проблемы. Возможно, плохо заметна кнопка. Может быть, теряется основная услуга или первый экран не объясняет предложение.

Полезнее обсуждать конкретную задачу, что посетитель должен увидеть, понять и сделать на этой странице.

Особенно это заметно, когда макет оценивают сотрудники, которые сами не относятся к целевой аудитории. Их личные предпочтения могут отличаться от сценария человека, для которого создаётся страница.

Ошибка 7. Добавлять новые требования, считая проект прежним

Во время разработки появляются новые идеи. Это обычная ситуация.

Допустим, после утверждения структуры компании понадобился калькулятор. Затем решили связать формы с CRM. Позже возникла идея личного кабинета.

Каждая функция может быть оправданной, но вместе они меняют объём проекта. Ошибка возникает, когда новые задачи добавляются, а ожидания по срокам и стоимости остаются прежними.

Сначала стоит определить последствия изменения.

- Нужна ли функция к первому запуску? 

- Какие уже согласованные решения она затрагивает? 

- Можно ли перенести её на следующий этап?

Границы проекта удобнее фиксировать заранее. Заказчику не требуется самостоятельно писать большой технический документ, но полезно понимать, что должно быть отражено в техническом задании на разработку сайта.

Ошибка 8. Вспоминать об интеграциях в конце разработки

Сайт может быть связан с CRM, телефонией, системой учёта, онлайн-записью, оплатой или другими сервисами компании.

До начала проекта заказчику необязательно знать, каким способом программисты будут связывать системы. Достаточно описать существующий процесс.

Например, после отправки формы обращение должно попасть в CRM, сохранить выбранную услугу и прикреплённый файл, а ответственному менеджеру должно прийти уведомление.

Если о таком сценарии команда узнаёт только после создания обычной формы, изменение затрагивает уже не одну кнопку. Может потребоваться изменить поля, обработку данных, интерфейс и тестирование.

Поэтому известные интеграции лучше обозначать ещё до проектирования, даже если технический способ подключения будет выбран позднее.

Ошибка 9. Принимать сайт только по внешнему виду

Красивый первый экран не показывает, работает ли весь проект.

Перед запуском стоит пройти основные сценарии будущего клиента:

• открыть сайт со смартфона,
• перейти на важные страницы,
• отправить формы,
• проверить телефоны и почту,
• посмотреть, что происходит после обращения.

Заказчик не должен выполнять техническое тестирование вместо разработчика. Его часть приёмки связана с другим. Соответствует ли готовый сценарий реальной работе бизнеса.

Например, заявка может технически успешно отправляться, но не содержать данных, которые менеджеру нужны для расчёта. С точки зрения программирования функция работает, а для бизнеса её ещё нужно уточнить.

Порядок приёмки и границы результата лучше закреплять заранее. Отдельно это разобрано в статье о том, что проверить в договоре на разработку сайта.

Ошибка 10. Считать публикацию сайта завершением всей работы бизнеса

После запуска сайт начинает работать с реальными посетителями.

Именно тогда появляются данные, которых невозможно получить по макетам:

• какие страницы открывают чаще,
• откуда приходят обращения,
• какие формы используют,
• где посетители прекращают сценарий.

Если компания планирует получать клиентов из поиска, рекламы или других каналов, источники аудитории желательно учитывать ещё до запуска. То же касается аналитики основных действий.

Это не означает, что сайт нужно постоянно переделывать. На первом этапе достаточно понимать, откуда должны приходить посетители, какие действия считаются значимыми и кто отвечает за актуальность информации после публикации.

Как организовать свою часть проекта

Заказчику не нужно управлять дизайнерами и программистами. Его зона ответственности находится в другом месте.

До старта полезно определить задачу сайта, основные аудитории и известные ограничения. Во время разработки нужен человек, который принимает итоговые решения. Материалы и доступы передаются к тому этапу, на котором они понадобятся, а замечания по возможности собираются в согласованные пакеты.

Если по ходу работы появляется новая задача, сначала стоит оценить её влияние на проект:

• нужна ли она первой версии,
• что уже придётся изменить,
• можно ли перенести её на следующий этап.

Так бизнес сохраняет контроль над смыслом и приоритетами сайта, а команда разработки не тратит время на многократное изменение уже согласованных решений.