Этапы разработки сайта: как мы работаем от интервью до запуска

Как мы работаем над сайтом: от интервью до запуска

Разработка сайта/приложения/сервиса и др. часто выглядит для заказчика как чёрный ящик: провели встречу, подписали договор, а дальше? Где-то внутри студии появляются прототипы, макеты и код. Через несколько недель всё это должно превратиться в готовый продукт, которым будут пользоваться люди.

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

В общем виде процесс создания продукта в sadovnikov.digital состоит из шести этапов:

1. Интервью, анализ бизнеса.
2. Концепт и прототипирование.
3. Дизайн и разработка.
4. Тестирование и демонстрация.
5. Запуск сайта.
6. Поддержка после запуска.

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

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

1. Интервью: сначала разбираемся в бизнесе

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

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

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

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

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

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

2. Концепт: сначала логика, потом визуал

После интервью мы не начинаем подбирать цвета и шрифты. Сначала появляется концепт — чёрно-белый прототип будущего сайта (продукта). На этом этапе мы уже проектируем структуру страниц, последовательность секций, содержание блоков, пользовательские сценарии и целевые действия. Если на сайт приходят несколько типов пользователей с разными задачами, учитываем это в структуре и карте пользовательского пути (CJM).

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

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

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

Как мы согласовываем и защищаем решения

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

Поэтому мы объясняем, почему первый экран устроен определённым образом, зачем конкретному сегменту показывается та или иная информация и почему пользовательский сценарий построен именно так. В аргументации используем UX-принципы, анализ конкурентов, доступную веб-аналитику, особенности аудитории и собственный опыт.

Логика обсуждения выглядит так: Задача → решение → ожидаемое поведение пользователя.

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

Но мы разделяем постановку задачи и способ её решения.

Например, заказчик говорит: «Мне кажется, пользователь может не заметить эту кнопку» — это конкретная проблема, которую нужно обсудить. Если же он предлагает сделать кнопку в два раза больше и красной, мы сначала постараемся выяснить, какую задачу должно решить такое изменение. Возможно, проблема действительно в заметности CTA. Но способов увеличить её несколько: изменить расположение, контраст, окружение элемента или последовательность блоков.

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

3. Дизайн и разработка: превращаем концепт в работающий сайт

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

У нас дизайн делает сложное — понятным, а важное — заметным

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

Интерфейс адаптируется под мобильные устройства, планшеты и десктопные браузеры. Учитываем реальные условия использования: мобильный интернет, производительность устройств, размеры изображений и объём загружаемого кода. В зависимости от проекта применяем оптимизацию изображений, отложенную загрузку ресурсов, CDN, серверный рендеринг и другие технические решения. Их задача — уменьшить время загрузки и обеспечить стабильную работу сайта.

Интеграции и автоматизация

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

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

Как мы работаем с правками

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

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

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

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

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

Во втором случае необходимо отдельно обсудить последствия для проекта.

4. Тестирование и демонстрация: проверяем сайт до запуска

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

Отдельно оцениваем доступность интерфейсов (accessibility), производительность и показатели Core Web Vitals. Что правда, технически исправный сайт ещё не обязательно удобен. Поэтому при проверке стараемся временно забыть всё, что знаем о проекте, и действовать как пользователь, который впервые открыл страницу.

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

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

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

5. Запуск: сайт должен быть готов к реальной работе

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

• подключение домена и настройку SSL;
• проверку форм и необходимых интеграций;
• установку Яндекс Метрики (и других метрик-систем);
• настройку целей и событий, если они предусмотрены проектом;
• проверку технических SEO-настроек;
• подготовку sitemap.xml и robots.txt;
• настройку canonical и Open Graph;
• добавление favicon;
• финальную проверку основных пользовательских сценариев.

Состав интеграций определяется задачами бизнеса. CRM подключается, если она используется клиентом и интеграция предусмотрена проектом. Аналогично с коллтрекингом, email tracking и другими сервисами: инструмент должен решать конкретную задачу.

Что входит в базовую SEO-подготовку

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

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

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

6. После запуска: первый месяц эксплуатации

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

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

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

Как заказчик узнаёт о ходе проекта

Для нас прозрачность процесса не менее важна, чем техническая реализация.

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

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

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

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

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

Сайт — результат совместной работы

Мы не считаем эффективной модель, в которой заказчик передаёт подрядчику список указаний, а подрядчик молча превращает их в пиксели и код.

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

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