Ошибки при разработке сайтов: отсутствие аналитики и развития после запуска
То, что сайт разработан и запущен, еще не означает, что можно больше ничего не делать и продажи резко пойдут вверх. Впереди еще много работы.
Во‑первых, непосредственно перед запуском проект надо протестировать на реальных пользователях и исправить выявленные проблемы. Не в плане работоспособности всех функциональных элементов (естественно, что корректная их работа должна быть обеспечена), а в плане простоты выполнения стоящих перед пользователями задач. Как это можно сделать?
Самый простой и наименее затратный способ — это попросить своих знакомых, друзей или родственников протестировать сайт. Важно не ставить перед ними задачу вида: «Посмотри мой сайт, походи по нему и скажи как он тебе». Результатом такой постановки задачи будут просто необоснованные критика или восхищение сайтом. Вы должны перед каждым человеком поставить какую- то одну конкретную задачу, например: «выбрать и купить товар», «выяснить условия сотрудничества», «оформить подписку» и др. Далее смотреть за действиями и фиксировать моменты, с которыми возникли проблемы. Соответственно, после понимания проблемных мест попытаться их исправить. Поэтому попытайтесь понять проблемные места сайта хотя бы после его создания, а далее приложите все усилия к улучшению сайта.
Более затратные, но и более эффективные методы — это тестирование на фокус‑группах, относящихся к целевой аудитории. Формат примерно тот же, но полученные данные обычно более объективные — знакомые и друзья часто не относятся к целевой аудитории сайта, к тому же часто на их действия и отзывы накладывает отпечаток личные взаимоотношения.
Еще хорошо себя зарекомендовала разработка интерактивных прототипов сайта еще на этапе проектирования сайта и тестирование взаимодействия на них. Но если рассматривать большинство проектов, то редко кто этим будет заниматься при проектировании сайта (на полноценное прототипирование обычно просто не выделяется бюджет).
Во‑вторых, как минимум в первый месяц после запуска нужно анализировать данные о поведении пользователей на сайте, выявляя сложности в работе сайта и исправляя выявленные таким образом недочёты. По отчётам Яндекс Метрики и Google Analytics можно составить очень хорошее представление о реальном поведении целевой аудитории на вашем сайте. Хорошо работает A/B-тестирование — отображение на сайте для разных пользователей различных вариантов отдельных блоков сайта и последующее сравнение эффективности. Например, половине аудитории показываем красную кнопку "Купить", а второй половине — зелёную. И сравниваем продажи. Если отклонения существенные, то оставляем для всех тот вариант, который показал лучшие результаты. Оба метода очень хорошо зарекомендовали себя в повышении конверсии сайтов.
В‑третьих, надо работать над привлечением аудитории и над содержательной частью сайта. Если вы создали сайт и считаете, что продажи сразу вырастут — вы ошибаетесь. Сайт — это всего лишь инструмент, без посещаемости толку от него ноль. Поэтому обязательно нужно продумать каким образом вы будете приводить трафик на сайт. Это могут быть и поисковая оптимизация, и контекстная реклама, и партнерская сеть, и баннерная реклама, и внешняя реклама со ссылкой на сайт и так далее. Важно продумать бюджет, так как зачастую он в разы или в десятки раз превышает стоимость создания сайта (если, например, брать период за год). Помимо увеличения посещаемости сайта важно планировать бюджет на написание и размещение контента, т.к. развитие самого сайта, во‑первых, важно для поисковых систем, а, во‑вторых, для самих посетителей, чтобы они возвращались к вам снова и снова.
Тематические статьи
Ошибки при разработке сайтов: старт проекта без целей, задач и проектирования
Часто, когда встает вопрос о создании сайта, цели и задачи не формулируются или формулируются нечётко. В этом случае вы никогда не получите то, что хотели, так как разработчикам просто непонятно что именно вы хотите.
Ошибки при разработке сайтов: субъективный подход к дизайну и стремление к самовыражению
Как часто можно услышать это: «Сайт должен быть стильным», «Сайт должен внушать доверие», «Мой дизайн должен быть эксклюзивным и непохожим на другие» и другие варианты необъективных критериев. «Стильное, лаконичное, внушающее доверие» — это все субъективные оценочные критерии, которые зависят от восприятия каждого конкретного человека.
Как написать функциональное техническое задание?
Всё просто: нормальным русским языком описывайте нужные функции в формате сценария использования. Пункты ТЗ должны быть объективными, просто изложенными и элементарным способом проверяемыми требованиями.
Сценарий лучше всего описывать в по схеме: [роль пользователя] может [действие], [описание целей пользователя, а также необходимых шагов и вариантов развития событий]. Оптимально — разбивать описание больших компонентов на маленькие составляющие.
Водопадная модель разработки
Водопадная модель разработки программного обеспечения — это процесс разработки, в котором все необходимые этапы проходят строго последовательно.
Разработка ПО по водопадной модели начинается со сбора и анализа требований, затем следует фаза проектирования и прототипирования. После завершения полного проектирования начинается этап программной реализации. После завершения этапа программирования разработанный продукт тестируется на соответствие требованиям. Затем осуществляется интеграция и запуск, после чего проект переходи в фазу поддержки и сопровождения.
Итеративная модель разработки
Итеративная (итерационная, инкрементная или эволюционная) модель разработки программного обеспечения — это процесс, который осуществляется небольшими этапами, в ходе которых ведется анализ полученных промежуточных результатов, выдвигаются новые требования и корректируются предыдущие этапы работы.
Жизненный цикл проекта при итерационной разработке разбит на последовательность итераций. Каждая из этих итерации, по сути, является водопадным проектом в миниатюре, то есть включает в себя все ключевые процессы разработки ПО и результатом работы по каждой итерации обычно является пригодная для использования версия продукта.
Создание дизайна сайта или веб‑приложения
Создание дизайна для сайта или веб‑приложения — это самый субъективно оцениваемый этап разработки, часто вызывающий сложности как на этапе постановки задачи, так и на этапе сдачи‑приёмки выполненных работ.
Задача этапа дизайна — разработка графических макетов интерфейса. К интерфейсу обычно выдвигаются вполне понятные технические требования — он должен быть понятен, удобен и позволять делать то, ради чего он создавался. В этой статье разберём основные подходы, позволяющие создать действительно качественный дизайн сайта.
Использование экономических критериев в веб‑разработке для оценки целесообразности реализации
В этой статье будут затронуты некоторые особенности разработки и поддержки ПО, которые основываются на экономических критериях оценки целесообразности.
Создание сайта быстро, дешево, индивидуально и качественно
Альтернативное название статьи: «Ищем в стоге сена отсутствующую там иголку».
Как зависит качество разработанного сайта от количества выделенных ресурсов и менеджмента проекта?
Самый простой ответ на этот вопрос: прямо пропорционально. На разработку действительно хорошего проекта требуется много времени, а плохой — можно «на коленке» за пару часов собрать. При профессиональном менеджменте результат проекта гарантированно лучше, чем в случае, когда менеджмента нет или он неэффективный.