Этапы разработки сайта удобнее оценивать по решениям, которые команда приняла и проверила. Сначала становится понятно, какую задачу решает сайт. Затем появляются структура и сценарии, макеты, работающая система, подтверждение её готовности и запуск. На каждом переходе нужен конкретный результат: согласованная схема страниц, проверенный выбор товара, успешно доставленный запрос.
Работа идёт с зависимостями и возвратами. Контент нужен уже при проектировании, ограничения интеграции могут изменить форму заказа, а проверка готового сайта иногда обнаруживает проблему в первоначальном сценарии. Разберём этот путь на одном проекте — от намерения владельца до работы на основном домене.
Учебный проект: каталог производителя с запросом комплектации
Представим производителя торговых стеллажей. Компания хочет, чтобы посетитель выбрал подходящую серию, указал комплектацию и передал запрос отделу продаж. Менеджер уточняет детали и готовит предложение. Это учебный пример: компания, решения и события ниже придуманы для объяснения процесса и не описывают клиентский проект Студии Вебирус.
В первом выпуске согласованы каталог серий, страницы изделий, выбор доступных вариантов и форма запроса. Итоговую стоимость рассчитывает менеджер; сайт должен передавать ему выбранную комплектацию. Источник номенклатуры — учётная система производителя. Фотографии, понятные описания и правила совместимости готовят сотрудники компании вместе с редактором.
У проекта есть два главных сценария. Посетитель, знакомый с продукцией, быстро находит нужную серию. Посетитель, которому ещё требуется выбор, сравнивает варианты и понимает, что включить в запрос. Если формат сайта пока не определён, сначала стоит разобраться, когда бизнесу подходит лендинг, а когда — корпоративный сайт. Дальше рассматриваем уже выбранный многостраничный каталог.
Задача и границы: что должно измениться для бизнеса
На входе нужны сведения о покупателях, текущем процессе продаж и продукте. Владелец объясняет, зачем нужен сайт, менеджер показывает, какая информация необходима для предложения, ответственный за каталог описывает источник данных. Подготовить материалы для такого разговора поможет отдельная статья о брифе на разработку сайта.
Фразу «нужен современный каталог» команда переводит в наблюдаемое поведение. Для нашего проекта оно звучит так: покупатель находит серию, понимает доступные варианты, собирает запрос и отправляет его; менеджер получает контакты и однозначно определённую комплектацию. Это ещё не обещание роста продаж. До появления реальных посетителей можно проверить работоспособность сценария, а влияние сайта на бизнес оценивать после запуска.
На этом же этапе согласуют состав первого выпуска и ограничения. Например, в учебном проекте не решено, как публиковать остатки: учётная система содержит внутренние статусы, которые покупателю непонятны. Поэтому наличие не обещают в карточке; менеджер уточняет его при подготовке предложения. Если показ остатков обязателен для бизнеса, вопрос нельзя просто отложить: нужно определить источник, частоту обновления и поведение при устаревших данных до утверждения объёма.
Результат этапа — описание цели, аудитории, основных сценариев, состава выпуска и открытых вопросов. Владелец бизнеса утверждает приоритеты, руководитель продаж — пригодность будущего запроса для работы, руководитель проекта — зависимости и состав работ. Переход к проектированию возможен, когда команда одинаково понимает, что должна сделать первая версия и какие нерешённые вопросы могут это изменить.
Структура и прототип: как покупатель доберётся до запроса
Проектирование начинается с согласованных сценариев и образцов реальных материалов. Для каталога нужны не только названия разделов, но и примеры изделий: с разным количеством вариантов, длинными названиями, отсутствующей фотографией. Разработчик параллельно изучает доступную выгрузку из учётной системы. Так команда выясняет, какие сведения есть, какие нужно подготовить и как они связаны.
В учебном проекте выясняется, что обозначения в учёте удобны сотрудникам склада, но не помогают покупателю выбрать серию. Команда сохраняет внутренние идентификаторы для обмена и добавляет понятные покупателю названия. Затем собирает схему каталога и простой прототип страниц: список серий, карточку изделия, выбор вариантов, состав запроса и подтверждение отправки.
Проверяют конкретную задачу: «Найдите стеллаж для своего магазина, выберите вариант и покажите, что отправите менеджеру». Желательно привлекать людей, похожих на будущих покупателей. Сотрудник производителя может пройти путь по привычке и не заметить непонятное обозначение. Если посетитель не понимает разницу между серией и комплектацией, пересматривают названия, группировку и объяснения в прототипе.
Проверка рискованных предположений через прототипы описана, например, в GOV.UK Service Manual. Это руководство для цифровых государственных услуг, а не обязательный порядок разработки любого сайта; здесь полезен сам принцип проверки решения до полной реализации.
Одновременно проводят небольшую техническую проверку самой рискованной зависимости. В нашем случае разработчик сопоставляет несколько изделий и вариантов с выгрузкой, проверяет устойчивые идентификаторы и возможность обновления. Макет фильтра по характеристике нельзя считать готовым к реализации, пока неизвестно, откуда эта характеристика берётся.
Результат — схема страниц, проверенный путь покупателя, состав данных и понятный способ обмена. Руководитель продаж подтверждает, что состав запроса достаточен; ответственный за каталог — корректность терминов и вариантов; технический специалист — реализуемость обмена. Владелец утверждает выбранный сценарий. Подробное оформление этих требований разбирается в статье о техническом задании на сайт.
Дизайн: представить согласованный сценарий на реальном содержимом
На входе у дизайнера есть структура, прототип, требования к состояниям и образцы контента. Для учебного каталога он готовит список серий и карточку изделия, показывает выбор вариантов, состав запроса, ошибки ввода и подтверждение. Проверяет эти решения на телефоне и широком экране.
У контента здесь прямое влияние на макет. У одного изделия короткое название и одна фотография, у другого — длинное название, схема и несколько вариантов. Если рисовать только удобную карточку с условным текстом, можно не заметить, что реальные характеристики не помещаются или выбор комплектации становится непонятным.
Допустим, на прототипе различие вариантов объяснялось одним предложением. При подготовке материалов выяснилось, что покупателю нужна схема расположения полок. Дизайнер добавляет место для схемы, редактор готовит объяснение, специалист производителя проверяет его точность. Если новое содержание меняет сам порядок выбора, команда возвращается к прототипу, затем обновляет макет.
Согласование привязывают к версии и объёму. Владелец утверждает визуальное решение, ответственный за продукт проверяет изображения и формулировки, разработчик уточняет поведение элементов. Для перехода нужны согласованные макеты значимых страниц и состояний на нужных размерах экрана. Общее «нравится» без проверки выбора вариантов и ошибок формы оставляет важную часть решения открытой.
Разработка: собрать страницы, данные и передачу запроса
Согласованные макеты, сценарии и правила данных становятся входом в реализацию. Разработчики собирают интерфейс, систему управления содержимым, каталог и обмен с учётной системой. Редактор готовит материалы параллельно; сотрудники производителя проверяют изображения, характеристики и доступные комплектации.
В учебном проекте заранее разделяют ответственность за поля. Номенклатура и варианты приходят из учётной системы; редакционные описания и подборки фотографий ведутся на сайте. Обновление выгрузки не должно стирать работу редактора. Это решение проверяют на пробном обновлении, а не оставляют до загрузки всего каталога.
Отдельно реализуют путь запроса. В нём должны сохраняться выбранные изделия и варианты, а менеджеру нужно получить именно ту комплектацию, которую видел посетитель. Проверка в браузере помогает исправить неверный ввод, но не заменяет проверку данных на сервере: клиентские ограничения можно обойти. Это различие объясняет MDN в руководстве по валидации форм.
Поведение при сбое согласуют как часть сценария. В нашем примере запрос сначала сохраняется на сайте, затем передаётся в систему продаж. Если передача временно не удалась, запрос остаётся виден ответственному сотруднику; повторную отправку организуют так, чтобы не создавать дубль. Сообщение посетителю соответствует подтверждённому состоянию: о принятии запроса можно говорить после его сохранения. Конкретный способ хранения, уведомления и повторов выбирают для используемой системы.
Результат этапа — работающий сайт в закрытом тестовом окружении с содержимым и связанными системами. Показ пустых шаблонов подтверждает только часть реализации. Для перехода к итоговой проверке покупатель должен пройти согласованный путь, каталог — обновиться без потери материалов, а запрос — дойти до сотрудника в правильном составе. Результат демонстрируют руководителю проекта и представителям бизнеса, отвечающим за эти операции.
Проверка и приёмка: подтвердить готовность всего пути
На входе есть версия сайта с реальным содержимым и согласованные критерии. Команда проверяет её технически, представители бизнеса — со стороны покупателя и своих рабочих процессов. Проверки отдельных функций во время разработки уже выполнены; теперь важно убедиться, что они работают вместе.
Для нашего каталога показательный проход выглядит так: человек открывает сайт с телефона, находит серию, выбирает допустимую комплектацию, отправляет запрос и получает понятное подтверждение. Менеджер открывает полученную запись и проверяет изделия, варианты и контакты. Ответственный за каталог меняет запись в источнике, обновляет сайт и убеждается, что описание и фотографии сохранились.
Нужны и отклонения от удачного пути: пустой результат фильтра, неверный контакт, временно недоступный обмен, повторная отправка, изделие с неполными данными. Для каждого случая должно быть согласованное поведение. Если данные не позволяют безопасно выбрать вариант, выпускать такой выбор как будто всё заполнено нельзя: нужно исправить данные или согласовать другой сценарий.
Удобство и доступность проверяют по мере проектирования и разработки. W3C WAI рекомендует оценивать доступность рано и на протяжении работы; автоматическая проверка сама по себе не подтверждает соответствие всем требованиям. На итоговом проходе, например, проверяют управление выбором и формой с клавиатуры и понятность сообщений об ошибках.
Замечания связывают с критериями. Ошибка передачи комплектации блокирует основной сценарий. Новое пожелание сравнивать изделия рядом расширяет согласованный объём: владелец решает, включать ли его в текущий выпуск, после оценки влияния на структуру, макеты и реализацию. Существенные ошибки исправляют и перепроверяют затронутый путь.
Переход к запуску утверждает уполномоченный представитель заказчика на основании результатов проверки. Оставшиеся допустимые замечания фиксируют с ответственными и дальнейшим порядком решения. Подробные проверки владельца вынесены в чек-лист приёмки готового сайта.
Запуск: перенести проверенный результат и подтвердить работу на домене
Запуск начинается с принятой версии, согласованного состава публикации и готовности людей, которые будут работать с сайтом. Технический специалист проверяет доступы, настройки домена, HTTPS, резервное копирование и возможность восстановления. Ответственные со стороны производителя знают, где смотреть запросы и кто реагирует на сбой обмена.
После переноса повторяют критический путь на основном домене. Отправка из тестового окружения не подтверждает работу производственных настроек почты и интеграций. В нашем проекте запускающий специалист и менеджер вместе проверяют контрольный запрос: он сохранён, содержит правильную комплектацию и доступен для обработки. Контрольную запись помечают как тестовую.
Также проверяют настройки публичных страниц. Если из тестового окружения перенесён запрет индексации noindex, Google будет исключать доступные ему страницы с этим правилом из поиска. Механизм описан в документации Google Search Central. Ограничения снимают для страниц, предназначенных для поиска; закрытые и служебные страницы сохраняют нужную защиту.
Результат запуска — работающий сайт на основном домене и подтверждённый процесс обработки запросов. Владелец получает сведения о проверках и ответственных за эксплуатацию. После запуска наблюдают за ошибками и реальными обращениями, чтобы отделить технические сбои от вопросов к содержанию и сценарию. Search Console позволяет проверять состояние индексации и работу сайта в поиске Google; запуск сам по себе не гарантирует индексацию, позиции или продажи.
Куда возвращается проект, когда проверка не пройдена
Причина замечания определяет, какое решение нужно пересмотреть. Возврат фиксируют так же, как первоначальное согласование: что выяснили, что меняется, кто утверждает новую версию и какие связанные результаты придётся перепроверить.
Схема выделяет часть зависимостей проекта. Сплошные стрелки показывают передачу входных материалов и результатов, пунктирные — возвраты после проверки. Если покупатель не понимает выбор, пересматривают прототип; если запрос передаётся неправильно — реализацию. Эти связи действуют вместе с остальными этапами, описанными выше.
| Что обнаружили в учебном проекте | К чему возвращаются | Что проверяют после изменения |
|---|---|---|
| Покупатель путает серию и комплектацию | Термины и прототип выбора | Понимание пути, подписи в макетах, состав передаваемого запроса |
| В выгрузке нет характеристики для согласованного фильтра | Источник данных и требования к каталогу | Заполнение характеристики либо утверждённый другой способ поиска |
| Настоящая схема изделия не читается на телефоне | Макет и подготовка изображения | Читаемость схемы на нужных размерах экрана |
| Менеджеру приходит другой вариант изделия | Сопоставление данных и реализация обмена | Полный путь от выбранного варианта до полученной записи |
Контент и интеграции проходят через несколько этапов. Отсутствующие правила совместимости влияют на прототип, макет и серверную проверку. Изменившийся формат выгрузки затрагивает реализацию и повторные проверки. Такие зависимости включают в план до обещания даты запуска. Подробно их влияние на календарь разобрано в статье о сроках разработки сайта; универсального срока для описанного набора этапов нет.
Владелец может оценивать ход проекта по трём вопросам: какой результат уже подтверждён, что мешает следующему переходу и чьё решение требуется. Ответ «макеты утверждены, но правила вариантов ещё не переданы» точнее описывает готовность, чем общий процент выполнения. Если обсуждаете разработку сайта под ключ со Студией Вебирус, согласуйте порядок работы и состав конкретного проекта по его задачам и зависимостям.
