Разработка сайта с агентством: поэтапный гайд от Курсора

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

Мы — агентство Курсор. Любим маму, HR-продукты и сложные B2B-проекты. Особенно для IT, телекома и консалтинга. Но в целом разрабатываем нешаблонные сайты для тех, кто хочет отличаться, и упаковываем визуальные коммуникации компаниям из разных сфер.

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

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

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

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

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

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

И накидываем смету — пока что не суперподробную, но уже с расчётом примерной стоимости этапов и ставок.

И таймлайн, и смету делаем на основе опыта с похожими проектами и нашей экспертной оценки: учитываем сложность проекта, сроки и риски.

Договор — штука важная, поэтому его обязательно нужно хорошенько изучить. И кстати — у агентств не принято писать что-то «мелким шрифтом». Все они стараются максимально подробно всё расписать. Это защищает и агентство, и клиента.

Для разных форматов работы — разные виды договоров. Обычно мы предлагаем спринты, Т&М (Time & Material) или фиксированный (Fixed Price).

Т&М (Time & Material) — сколько сделали, за столько нам и заплатили. Гибкий подход, который позволяет, если что, перестроить всё на ходу.

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

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

Как выбрать? Исходить из степени определённости.

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

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

А что по спринтам? Спринтами мы тоже работаем, но иногда в них просто нет смысла. Например, странно нарезать на спринты совсем небольшие проекты, где этапы длятся всего 3–4 дня.

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

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

Вытаскиваем инфу с сайтов конкурентов: смотрим, кто, что и как делает в вашей и смежных областях.

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

И если у клиента есть любимые полезные материалы по его области, мы просим прислать их.

Бывает, что мы даже проводим интервью с людьми в сфере (да, даже с конкурентами). В этом этапе клиент почти не участвует — только когда нужна дополнительная информация.

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

На этом этапе мы пытаемся понять, как клиент видит сайт, и показываем своё видение. А потом ищем вариант, который понравится всем.

Если просто, то шерстим интернеты и смотрим, кто какие делает сайты. Причём не только в нише клиента.

У сбора референсов две основные цели:

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

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

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

🚩 Рэд флаг: если вам скидывают мудборд и не предлагают вместе его разобрать. Мудборд без сопровождения дизайнеров, которые его собирали, — это просто доска с кучей картинок. Так никакого продуктивного обсуждения у вас не выйдет.

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

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

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

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

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

Наконец-то появляется визуал. Сначала мы собираем только 3–4 экрана с ключевыми блоками: так нам не придётся переделывать целый сайт, если будут правки.

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

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

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

Берём дизайн-концепцию с вайрфреймами и делаем на их основе весь сайт. Если вы активно участвовали в предыдущих этапах, то этот будет суперпростым и безболезненным.

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

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

Собираем в Фигме (или Фигмазаменителе) систему, чтобы и нашим, и вашим разрабам было максимально удобно фиксить и развивать сайт в будущем.

Пилим UI-кит — отдельный файл со всеми строительными блоками дизайна. Туда входят цвета, шрифты, состояния кнопок, описанные анимации и полноценный макет.

🚩 Рэд флаг: если в конце работы вам не прислали UI-кит. Смело его требуйте.

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

А если сайт кастомный, покупаем и настраиваем сервер. Обычно у нас есть тестовое окружение (как раз сам сервер) и продовое. Тестовое доступно только нам, там мы тестируем сайт на баги. Продовое — реальное: сайт доступен пользователям и работает с их данными.

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

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

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

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

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

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

Базово мы прикручиваем аналитические инструменты Яндекса и Гугла. А за дополнительную плату можем ещё и мониторинг через Телеграм-бота привязать. Тогда вам будет приходить статистика по посещениям и общему состоянию сайта. А если возникнут неполадки или сайт ляжет, вы узнаете об этом в течение 2 минут.

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

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

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

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

Формат договора тоже играет роль. Если работаем по Т&М, то просто подписываем приложения к договору и периодически обновляем их. А если по фиксе — заключаем новый договор на поддержку.