Создание сайта — многоэтапный процесс, состоящий далеко не только из собственно программирования. Чтобы разработать сайт, который будет соответствовать вашим бизнес-задачам и приносить прибыль, необходимо учесть десятки нюансов на старте и грамотно управлять всем процессом.
В этой статье я расскажу об основных этапах создания сайта и выделю аспекты, которые не лежат на поверхности, а также поделюсь личным опытом и лайфхаками.
Если вы задумались о создании сайта с нуля, прежде всего определитесь с задачами, которые он должен решать. Успешный сайт — это не просто визитка компании в интернете, а полноценный инструмент продаж. Он должен учитывать ваши бизнес-цели, потребности целевой аудитории и текущие тренды.
Если раньше вы успешно работали офлайн, то вы, без сомнения, знаете свою офлайн-аудиторию и главных конкурентов. Ситуация онлайн может несколько отличаться: вам могут быть доступны более широкие аудитории, список конкурентов окажется иным и т. д. Поэтому перед началом работы досконально изучите онлайн-рынок самостоятельно или привлеките подрядчика.
На основе анализа вы сможете точно понять, как создать конкурентоспособный сайт с точки зрения дизайна и функциональности. Идеально, если вы соберете основные моменты в некоем техническом задании — оно вам понадобится в дальнейшем при сотрудничестве с разработчиком. В ином случае исполнитель предложит вам заполнить свой бриф.
Читайте по теме:
Системный анализ конкурентов: семантика, объявления, сайт, отдел продаж
Анализ конкурентов: оцениваем угрозы, преимущества и свое место на рынке
Как проводить анализ аудитории и продукта перед запуском рекламы
Определившись с тем, что вы хотите от будущего сайта, можно начинать подготовительные работы и поиск подрядчика. Давайте разберем основные тонкости, которые нужно учитывать на старте.
Если у вас нет собственного домена, начать стоит с его покупки.
Насколько важна история домена? Новички, как правило, первым делом фокусируются на разработке самого продукта, а не на его продвижении — для такого случая подходит нулевой домен, то есть который ранее не использовался.
Можно приобрести домен с историей, полагая, что продвигать такой сайт будет проще. Для SEO-продвижения важна репутация сайта и количество ссылок на него с весомых ресурсов. С этой точки зрения тематические домены компаний, которые в силу различных причин перестали работать, могут обладать хорошими показателями. К новым же доменам такого доверия нет, поэтому, по мнению многих SEO-специалистов, в первые несколько месяцев они могут не достигать значимых позиций в поиске.
Этот вопрос спорный, но в любом случае есть и подводные камни — например, санкции от поисковых систем, наложенные на домен. Поэтому покупать чужой высвободившийся домен, на котором раньше был другой сайт, следует с осторожностью, консультируясь со знающими людьми. Если есть сомнения, имеет смысл склониться в пользу нового домена.
Купить домен можно на сайте регистратора домена, там же рекомендую сразу приобрести и хостинг. Например, Ru-Center и Reg.ru иногда предлагают выгодные пакетные предложения. У Ru-Center есть пакеты даже с адаптацией под известные движки WordPress и Joomla — для пользователей, которые еще не определились с системой управления, не понимают, какие им необходимы требования к хостингу, и, скорее всего, рассматривают бесплатные системы управления.
Стоимость хостинга зависит от дискового пространства и от количества доменов. Если у вас один домен, требуется небольшое дисковое пространство и вам пока не нужно большего — смело берите самый дешевый хостинг.
Перед разработкой сайта необходимо определить источники контента, подготовить первичные данные и тексты, а также продумать механику их обновления. К базовому контенту относится текст главной страницы, для разделов о компании, основных услугах и контактах. Для каждого динамического раздела, например, новостей, необходимо подготовить по 3–4 материала, чтобы можно было смотреть не одинаковые тексты во всех примерах, а тексты разного объема и с разными картинками.
Для разных категорий сайтов могут быть свои нюансы. Так, в случае создания интернет-магазина важно понимать, откуда будут браться товары и цены, кто и как часто будет их обновлять. Если речь идет о сайте-визитке, нужно систематизировать и описать услуги. Если о сервисе онлайн-консультаций — как пользователи будут задавать вопросы, кто на них будет отвечать. На продающем сайте должна быть Политика конфиденциальности и необходимые юридические документы. Кроме того, с недавних пор компании обязаны на своих сайтах публиковать информацию о СОУТ (спецоценке условий труда).
Важный вопрос — подготовка изображений. Несмотря на то, что существует большое количество бесплатных стоков, не факт, что типовые картинки с веселыми лицами менеджеров подойдут к тематике и стилистике вашего сайта. Возможно, придется озаботиться покупкой платных изображений, запросить фото товаров у поставщиков или воспользоваться услугами фотографа.
Больше о контенте для сайта:
15 вопросов, на которые нужно ответить при создании посадочной страницы
Эффективность посадочных страниц: 22 способа сделать конверсию выше
Как создать идеальный лендинг: структура, контент и изображения
Обычно разработчика, будь то знакомого, исполнителя с бирж фриланса или компании, выбирают по рейтингам или через сарафанное радио. Дать четкие критерии идеального исполнителя нельзя.
Единственный совет — вам с ним должно быть комфортно, поскольку взаимодействовать придется не один месяц.
Хороший разработчик — это ваш заинтересованный партнер. Если постоянно возникают недопонимания, доверительная атмосфера не складывается и интуиция подсказывает, что что-то не так, не бойтесь менять исполнителя.
Читайте также:
Важно определиться с методологией разработки: классической или гибкой. Первый вариант означает, что вы фиксируете на старте все пожелания и договоренности, получаете доскональную смету и далее в оговоренные сроки видите конечный результат.
Гибкие методологии предполагают поэтапную работу заказчика и исполнителя, когда для каждого из них фиксируется пул задач, сроки и стоимость. Такой способ подходит в том случае, если вы без запуска не понимаете, насколько удобными окажутся те или иные решения на практике и не готовы сразу делать сайт целиком. Для этого в короткие сроки запускается MVP (minimum viable product, минимально жизнеспособный продукт) и далее продукт постепенно развивается и дорабатывается.
Могу привести пример разработки сайта по гибкой методологии. Сейчас мы в DD Planet работаем с клиентом — сетью медицинских центров. В начале заказчик обратился с целью создания простого сайта-визитки, который необходимо было быстро продвинуть в топ. Далее по мере роста потребности в более активном продвижении и ресурсов на обработку потока заявок сайт трансформировали в информационный ресурс с новостями и материалами о заболеваниях и методах лечения.
Сейчас мы уже работаем над добавлением личного кабинета, интернет-магазина и записи к врачу. Так, компания поэтапно проходит путь от простого лендинга к функциональному сайту в комфортном для себя режиме.
Разрабатывать сайт можно как на платных, так и бесплатных платформах.
Начинают обычно с бесплатных систем управления сайтом с открытым исходным кодом (WordPress, Joomla, Drupal, Opencart и др.). Такой вариант подходит, если у вас нет потребности в нестандартном дизайне и возможностях за рамками предлагаемых шаблонов, а также серьезных требований к безопасности и продвижению сайта. Собрать сайт на такой платформе может фрилансер. При грамотной разработке он вполне успешно работает, приносит деньги и до поры до времени не нуждается в серьезных изменениях.
По мере роста бизнеса бесплатными движками уже не обойтись и лучше перенести сайт на более стабильную и безопасную платформу. Среди наиболее популярных платных CMS: «1C-Битрикс», NetCat, Umi.CMS и др. Это коробочные решения с более широким встроенными возможностями, чем у бесплатных платформ. Они позволяют разрабатывать довольно сложные сайты без лишних трудозатрат и «костылей», а также лучше подходят для активного SEO-продвижения.
Кроме того, для наиболее сложных и нетиповых проектов может потребоваться кастомная разработка. Она предполагает написание сайта с помощью фреймворков без использования коробочных решений. Такой способ обычно используют онлайн-агрегаторы, крупные информационные сайты, социальные сети и сложные интеграционные сервисы.
Чтобы в самом начале представлять, как будет выглядеть ваш сайт, необходимо разработать его прототип.
После того как вы на этапе аудита выявите потребности целевой аудитории и конкурентные «фишки», у вас появится понимание нужной функциональности. Далее UX/UI-специалист распределяет его на сайте с учетом принципов юзабилити. В результате получаются схематичные отображения, которые передаются на проработку дизайнеру.
Прототипирование может осуществляться любым удобным образом, в идеальном виде — с помощью специальных программ. Например, Axure — один из наиболее известных инструментов — позволяет создавать наглядные кликабельные прототипы. Вы сможете уже в прототипе частично протестировать кнопки, переходы на другие страницы, выпадающие списки и т. д.
На моей практике был забавный случай. Мы показали клиенту прототип, а он сказал: «О, круто, давайте побольше цветов добавим, чтобы было поярче — и можно публиковать». Ему настолько понравилось то, что он увидел с точки зрения внешнего вида и возможностей: как всё открывается, пролистывается и прыгает — что не понял, что это еще не готовый сайт, а только прототип.
Прототипирование может быть неуместно, когда на старте невозможно предусмотреть всё и каждый функциональный блок обсуждается и реализуется отдельно. В этом случае лучше ориентироваться на поэтапную разработку и запуск MVP в кратчайшие сроки. Прототипы мы обычно создаем для крупных проектов со сложным интерфейсом и функционалом, для того чтобы всё зафиксировать — как вариант технического задания. Далее с ростом проекта и прототипы, и дизайн-макеты могут дорабатываться.
В любом случае не стоит воспринимать прототип как строгое и окончательное решение — по мере отрисовки интерфейса дизайнер может предложить практические решения в куда более интересном виде, чем отраженные схематично в прототипе.
Приступаем непосредственно к разработке. Чтобы по окончании проекта вовремя получить нужный результат, не полагайтесь полностью на сознательность исполнителя — обязательно управляйте процессом.
Перед стартом работ необходимо утвердить с подрядчиком сроки. При этом важно соблюсти баланс для обеих сторон: бизнеса и разработки. Не стоит пускать всё на самотек, чтобы подрядчик не чувствовал себя расслабленно, но и не загоняйте его в слишком сжатые сроки, если результат вам нужен позднее.
С одной стороны, может показаться, что высокие темпы будут мотивировать команду, однако на самом деле они приведут к ухудшению результатов. Любая авральная работа дает эффект лишь в краткосрочной перспективе, а затем продуктивность снижается. Обычно разработка ведется поточно, когда из одной задачи следует другая или параллельно выполняются несколько задач. Если лишить команду сил чересчур высокими темпами на одной задаче, результаты следующей будут заметно ниже.
Как правило, сроки определяются совместно и предполагают дедлайн сдачи проекта уже после проведенного тестирования, всех корректировок и контентного наполнения.
При планировании сроков и бюджета обязательно заложите риски — рекомендую порядка 20%. Эти средства можно будет быстро и без лишних оформлений преобразовать в трудозатраты в случае каких-либо изменений на проекте. Если в техническом задании или прототипе что-то оказалось не учтено, вы сможете поставить нужную задачу разработчику сразу, а не ждать сначала сдачи проекта.
Что касается сроков, обычно в компаниях существуют внутренние коэффициенты на специалистов, которые позволяют объективно оценить сроки и риски. В основном учитываются лаги между исполнением задач, время передачи информации между командами (например, с верстки на программирование), а также дополнительные риски в зависимости от конкретных проектов.
Некоторые планируют работу по проектам по старинке через почту. Если сайт небольшой, это допустимо, однако если задач предстоит много, удобнее ставить их через специальные сервисы.
Таких систем достаточно много, в DD Planet мы, например, для проектов по разработке используем Microsoft Azure, где отображаются спринты, user stories, задачи, сроки и статусы. Заказчику предоставляется доступ в этот сервис, где он может ставить задачи и отслеживать процесс их выполнения.
С проектами по дизайну удобно работать в платформе InVision. Она позволяет дизайнерам публиковать макеты по проекту и обсуждать их с заказчиком. Преимущество в том, что есть возможность указать на конкретное место в макете и прокомментировать его.
Для более мелких вопросов (по тому же дизайну или техподдержке) раньше мы пользовались Worksection, где можно зафиксировать задачи из почты, продемонстрировать клиенту проекты, получить комментарии и т. д. Сейчас для этого используем «Битрикс-24». Среди прочих возможностей в нем есть удобные списки задач с дедлайнами и уведомлениями.
Приведенные выше системы не только помогают планировать задачи, но также являются прозрачными инструментами для контроля результатов. Тем не менее, не полагайтесь только на них — чтобы держать исполнителя в тонусе, необходимо регулярно взаимодействовать с ним лично.
У любого проекта должен быть календарный план-график разработки, который поможет вам отслеживать ход работы на каждом этапе. Если подрядчик говорит, например, что проект будет готов через три месяца — этого недостаточно, обязательно требуйте подробную разбивку по срокам реализации всех задач, которые вы будете контролировать.
Стандартный спринт в рамках agile-методологии составляет две недели. Как правило, на это время планируется определенный пул задач, а по прошествии периода вам должны продемонстрировать результаты. Допускается планировать и по одной неделе, но не чаще, поскольку это неудобно ни для разработчика, ни для бизнеса.
Не полагайтесь на слова, а обязательно проверяйте всё лично, чтобы предотвратить возможные форс-мажоры. У любого проекта должен быть тестовый стенд под паролем, где размещается программируемый сайт. Изначально он представляет собой копию сайта или пустую версию системы управления, на которой постепенно публикуется разрабатываемый сайт. Размещается такой стенд на поддомене того же хостинга, где и сам сайт, или на поддомене разработчика. В таких условиях оптимально и тестировать сайт, и показывать заказчику промежуточный результат работы.
Также есть стенды по направлениям (например, для верстки или разработки), предбоевой сайт и боевой. Обязательно проговаривайте с исполнителями сроки публикации всех изменений на стендах. Лично мне очень помогает правило: если я своими глазами не увижу опубликованных на нужном стенде результатов, значит, задача еще не выполнена.
Помимо регулярного контроля проекта в рамках спринтов, предусмотрите возможности для оперативной коммуникации, а также коротких созвонов для обсуждения промежуточных статусов. Это поможет вам не задаваться вопросами, а видеть реальную картину разработки.
Для коммуникации с заказчиком и внутри команды мы, например, практикуем несколько видов чатов в Skype: с клиентом по каждому проекту, общий по разработке и по направлениям. В ряде проектов для этих целей используется Slack.
Периодичность созвонов определяется индивидуально — как правило, один или несколько раз в неделю. Для крупных проектов я рекомендую ежедневные статус-митинги по 15 минут. На них проговариваются текущие задачи, проблемы и статусы, после чего они фиксируются в соответствующих чатах. Для созвонов можно использовать Skype или сервис веб-конференций Webex. Как показывает практика, аудиоформата вполне достаточно. Если есть необходимость в видео, можно использовать Zoom.
На собственно разработке дело не заканчивается. Финальные стадии создания сайта — тестирование и техподдержка.
По ходу разработки и по окончании проекта в обязательном порядке проводится тестирование. Оно состоит из нескольких этапов.
Первый этап — пользовательское тестирование, когда сайт оценивается с позиции бизнеса или обычного пользователя: вся ли запланированная функциональность работает, всё ли логично и понятно. Для этого необязательно использовать тестировщика: от менеджера больше пользы, поскольку он сможет увидеть то, на что у профессионала может замылиться глаз.
Далее проходит функциональное тестирование, с помощью которого детально проверяется работоспособность всех функций. Его реализует тестировщик по сценариям. Для отдельных проектов могут использоваться автоматические тесты.
Очень важно кросс-браузерное и кросс-платформенное тестирование. Оно осуществляется с помощью специальных инструментов, например, BrowserStack, который позволяет эмулировать просмотр сайта в нужных устройствах и различных браузерах. Также осуществляется тестирование с помощью физических устройств наиболее часто используемых моделей. По умолчанию сайт ориентируется на последние версии браузеров, но иногда возникает потребность в поддержке отдельных версий браузеров или устройств.
Например, у нас в DD Planet есть клиент, целевая аудитория которого активно пользуется телефонами Xiaomi — и ему важно, чтобы сайт работал корректно на конкретных моделях Xiaomi. Еще один заказчик долго не мог отказаться от поддержки четвертой версии Android, поскольку его целевая аудитория из регионов пользовалась старыми моделями телефонов, не поддерживающими последние версии. А с одним сайтом мы долго мучались, адаптируя его под устаревшие версии Opera, которая в тот момент перестала автоматически обновляться.
Вывод следующий: изучайте вашу целевую аудиторию и формируйте список нужных устройств и браузеров. Не стоит игнорировать редкие версии и модели, если ими пользуется значительная часть ваших клиентов.
Нагрузочное тестирование позволяет эмулировать ситуацию высокой нагрузки — например, большого количества посетителей, одновременно активно пользующихся сайтом. С помощью специальных программ тестировщик оценивает время отклика сайта при различных, в том числе и стрессовых, нагрузках. На основании собранных им данных принимается решение о том, стоит ли проводить дополнительную оптимизацию сайта.
Для сложных проектов также требуется интеграционное тестирование. Как правило, все интеграции эмулируются в виде заглушек, проверяются в псевдоинтеграционном режиме и отлаживаются на предбоевом стенде.
После завершения функционального, нагрузочного и интеграционного тестирования сайт готов к запуску. В зависимости от потребностей и особенностей проекта могут также потребоваться дополнительные виды тестирования: SEO, скорости загрузки страниц, мониторинг качества конкретной платформы (такие тесты есть, например, у «1C-Битрикс») и т. д.
Гарантированная техподдержка обычно предоставляется на срок от полугода до года. Если в этот период будут выявлены ошибки, не всплывавшие ранее, недотестированные или допущенные по вине разработчика, вам их исправят бесплатно по гарантии.
В дальнейшем поддержка может требоваться как разово, так и на протяжении всей жизни сайта — в зависимости от масштабов проекта. Она необходима, поскольку постоянно развиваются технологии, появляются новые возможности, да и сам сайт не стоит на месте, а эволюционирует по мере роста бизнеса.
Небольшая подготовка сайта к продвижению в дальнейшем сильно облегчит вам жизнь. Поставьте коды систем аналитики и настройте цели. Даже если вы не планируете сразу их анализировать, вам будет гораздо проще опираться на уже накопленные данные, когда вы решите давать рекламу.
Читайте больше: Как подготовить бизнес к запуску рекламы
Итак, в этой статье вы узнали про основные стадии создания сайта для бизнеса и нюансы, которые стоит учитывать на каждом из этапов. Желаю успешного применения этого руководства на практике и создания максимально эффективных сайтов!
На исследование основных показателей в Яндекс Метрике достаточно одного часа. В статье мы покажем, как находить эти показатели и объясним,…
Рассказываем, какие интересные и полезные исследования вышли в мае 2022 года. Какие каналы для общения с клиентами выбирает бизнес —…
В мае Яндекс увеличил количество мест в товарной галерее и добавил два новых формата Большого баннера на главной. Директ…
Я пришел в digital 11 лет назад, когда учился в аспирантуре института биоорганической химии им. академиков М. М. Шемякина и Ю. А. Овчинникова. Тогда я просто…
Как сформулировать CTA, решает общий контекст коммуникации с пользователем. Какая формулировка сработает лучше, определяет тестирование. Но что…
Магазины в Telegram уже были давно. Как они выглядят и насколько удобны — другой вопрос. Некоторые из них — просто…