Этапы создания сайта: от идеи до запуска

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

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

Основные цели могут включать:

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

Цели следует формулировать через действия посетителей. Например, «получать заявки на проектирование» или «позволить покупателю самостоятельно оформить заказ».

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

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

Анализ целевой аудитории помогает определить содержание страниц и последовательность действий пользователя.

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

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

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

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

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

Техническое задание можно уточнять до начала программирования. Все изменения после согласования желательно фиксировать отдельно с оценкой их влияния на состав работ и общий срок.

Прототип показывает структуру страниц и расположение основных элементов без окончательного визуального оформления.

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

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

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

Контент желательно готовить до завершения дизайна. Реальный объем текста и количество изображений влияют на размеры блоков и расположение элементов.

Все факты, цены, контакты и характеристики должен проверить заказчик. Разработчики могут структурировать и оформить материалы, но не могут подтверждать внутреннюю информацию компании.

После согласования общего визуального решения оформляются остальные типовые страницы и состояния элементов.

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

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

На этом этапе сайт подключают к системе управления (например, 1С-Битрикс наш любимый). Она позволяет сотрудникам редактировать тексты, добавлять товары, менять цены и публиковать материалы без изменения программного кода.

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

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

Для большого каталога может использоваться автоматическая загрузка товаров из файла или учетной системы (1С). Перед импортом нужно привести данные к единому формату и определить правила заполнения обязательных полей.

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

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

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

Получите доступы

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

Получите инструкции

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

Либо просто заключите договор на обслуживание и успокойте свои нервы!

После публикации сайт нужно повторно проверить в рабочей среде. И это делают исполнители (у них есть тестировщик на это дело), но также это можете сделать вы, по всем перечисленным пунктам выше!

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

Отсутствие готового контента. Тестовые тексты не показывают реальный объем информации. После загрузки материалов блоки могут потребовать переработки.

Изменение требований без фиксации. Устные изменения легко потерять или понять по-разному. Новые требования следует добавлять в общий список с описанием влияния на проект.

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

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

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

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

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