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

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

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

Мы выстраиваем процесс иначе.

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

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

Условно весь процесс можно разделить на шесть этапов:

1. интервью и анализ бизнеса;
2. концепт и прототипирование;
3. дизайн и разработка;
4. тестирование и демонстрация;
5. запуск сайта;
6. поддержка после запуска.

{здесь вставить изображение: схема из 6 этапов разработки сайта}

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

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

Подробнее об этой позиции мы рассказываем в отдельном материале: «Что на самом деле покупает бизнес, заказывая сайт у студии».
{ссылка на статью /blog/chto-pokupaet-biznes-zakazyvaya-sajt-u-studii}

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

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

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

Собственник или руководитель знает о своём бизнесе вещи, которые невозможно предусмотреть заранее вопросами в Google-форме.

Поэтому разработка сайта у нас начинается с интервью.

Мы разговариваем с собственником, руководителем или другим ЛПР и разбираем:

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

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

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

Нам важно получить ответ на два базовых вопроса:

Что за продукт перед нами?

И:

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

Пока ответы размыты, открывать Figma рано.

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

Мы отдельно разобрали, почему предпочитаем такой подход классическим анкетам и жёстким спецификациям: «Почему мы не используем брифы и жёсткое ТЗ для разработки сайта».
{ссылка на статью /blog/pochemu-my-ne-ispolzuem-brify-i-zhestkoe-tz}

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

После интервью мы не начинаем подбирать цвета и шрифты.

Сначала появляется концепт — чёрно-белый прототип будущего сайта.

На этом этапе мы проектируем:

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

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

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

Поэтому прототип нужен прежде всего для обсуждения логики.

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

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

{здесь вставить изображение: пример ч/б прототипа с короткими комментариями к CJM и CTA}

3. Мы защищаем решения, а не просто показываем макет

Концепт и последующий дизайн мы презентуем заказчику лично.

Причина простая: хороший интерфейс невозможно полноценно объяснить ссылкой на Figma и сообщением «посмотрите, как вам».

У каждого существенного решения должна быть причина.

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

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

То есть стараемся строить разговор по цепочке:

задача → решение → ожидаемое поведение пользователя.

Не:

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

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

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

Фраза:

«Мне кажется, пользователь может не заметить эту кнопку»

— нормальная причина для обсуждения.

Фраза:

«Сделайте кнопку в два раза больше и красной»

— уже готовое дизайнерское решение.

В такой ситуации мы, скорее всего, сначала спросим: зачем?

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

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

По той же причине аргумент уровня:

«Я посоветовался с женой, она сказала, что синий будет смотреться некрасиво»

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

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

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

Подробнее об этом подходе — в статье «Как мы принимаем и защищаем решения в дизайне сайта».
{ссылка на статью /blog/kak-my-prinimaem-i-zashchishchaem-resheniya-v-dizajne-sajta}

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

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

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

Затем интерфейс превращается в работающий сайт.

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

В зависимости от проекта используем оптимизацию изображений, lazy loading, CDN, серверный рендеринг и другие способы уменьшить время загрузки и сохранить нормальный пользовательский опыт.

При этом сайт редко существует изолированно.

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

Но мы не подключаем технологии ради технологий.

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

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

5. Правки — нормальная часть проекта, но не бесконечный процесс

Разработка сайта почти никогда не проходит вообще без изменений.

Это нормально.

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

Проблема начинается, когда под словом «правка» фактически появляется новая задача.

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

Это уже изменение scope проекта: оно может влиять на сроки, бюджет и загрузку команды.

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

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

Для нас важнее разделять две вещи:

правку, которая улучшает согласованное решение,

и

изменение требований, которое создаёт новое решение.

Отдельно эту тему разбираем в статье «Правки при разработке сайта: почему мы не просто делаем всё, что просит заказчик».
{ссылка на статью /blog/pravki-pri-razrabotke-sajta}

6. Тестирование и демо: ищем проблемы раньше пользователей

Перед запуском сайт проходит проверку.

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

В разработке используем в том числе автоматизированные сценарии через Playwright и технические проверки кода. Отдельно смотрим на accessibility, производительность и Core Web Vitals.

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

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

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

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

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

Мы не называем внутреннюю проверку большой «фокус-группой» ради красивой презентации процесса. Формат тестирования зависит от конкретного проекта и доступных ресурсов.

Подробный технический процесс вынесен отдельно: «Как мы тестируем сайт перед запуском».
{ссылка на статью /blog/kak-my-testiruem-sajt-pered-zapuskom}

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

Утверждённый дизайн и работающий localhost — ещё не запущенный проект.

Перед выпуском в production мы доводим инфраструктуру до рабочего состояния:

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

Состав интеграций зависит от бизнеса.

CRM подключается, если она существует у клиента и интеграция входит в задачу проекта. Аналогично с call tracking, email tracking и другими системами: инструменты появляются не «для галочки», а когда у них есть понятная функция.

Базовое SEO на этом этапе тоже не означает полноценное поисковое продвижение. Мы создаём технический фундамент, чтобы поисковым системам было проще корректно индексировать сайт. Семантика, контент-маркетинг, ссылочное продвижение и другие SEO-работы — уже отдельные направления.

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

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

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

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

8. После запуска: месяц, когда начинается реальная эксплуатация

Публикацией работа не обрывается.

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

Также можно смотреть на первые данные аналитики и находить точки для улучшения конверсии.

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

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

{здесь вставить изображение: пример отчёта по проекту / статус этапов / риски / бэклог}

9. Заказчик знает, что происходит с проектом

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

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

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

При необходимости заказчик получает отчётность по проекту:

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

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

При этом мы не пытаемся создавать ощущение, что всё всегда идёт идеально.

Разработка — это работа с неопределённостью. Может обнаружиться техническое ограничение, новая вводная со стороны клиента или наша собственная ошибка.

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

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

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

Это не обезличенный call-центр с формальным SLA 24/7. Это возможность напрямую связаться с человеком, который отвечает за проект и понимает, что с ним происходит.

Сайт — результат совместной работы, а не исполнения указаний

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

Но и обратная крайность нам не близка.

Мы не знаем бизнес клиента лучше него.

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

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

Мы отвечаем за проектирование сайтов, UX, интерфейсы, разработку и техническую реализацию.

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

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

Для нас хороший результат обсуждения — не когда «мы переубедили заказчика».

А когда:

«мы поняли его задачу и вместе нашли решение лучше».

Как начать проект

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

Это как раз можно выяснить вместе.

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

{здесь вставить CTA}

Есть задача по сайту? Начнём с интервью.

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

[Записаться на интервью]