Редизайн — на что обратить внимание заказчику

Для начала договоримся о терминологии, дабы избежать разночтений — в этой статье под дизайном понимается не только изменение внешних (визуальных) составляющих, но и работа над структурой сайта, его “технической начинкой” — CMS и кодом.

Редизайн имеет эволюционную природу — сайт работает, появляются идеи по его улучшению, какие-то дополнения, небольшие изменения во внешнем виде, меняются требования пользователей, технического и программного обеспечения (например, разрешения мониторов и возможности браузеров). Что-то из изменений воплощается сразу, что-то откладывается на потом. И в какой-то момент становится понятно количество внесенных изменений (или не внесенных и находящихся в очереди), или же требования к обновлению кода и CMS и т. п. вещи требуют масштабных работ, которые превратят накопившиеся костыли в единую хорошо работающую систему. Или другой вариант — редизайн бывает нужен, чтобы дополнить сайт современным функционалом и/или придать сайту современный вид.

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

  • Постоянные улучшения

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

    А. При подготовке к редизайну с самого начала определите кто с вашей стороны будет отвечать за проект и будет принимать окончательные решения.
    Б. Четко сформулируйте перечень изменений, которые вы хотите сделать, и дайте исполнителям время на оценку необходимого объема работ.
    В. Зафиксируйте объем работ в проекте по итогам предыдущего пункта. К новым идеям переходите после того, как будут реализованы указанные в проекте и проект будет закрыт.

  • Недооценка объема работ и их сложности

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

    Ковыряние в коде не является вашим основным бизнес-процессом. Это задача программистов. Если вы уже подписали договор с конкретным исполнителем, требуйте соблюдения сроков и качества, но не вмешивайтесь в исполнение технических моментов и не пытайтесь обесценить работу ваших партнеров. В конце концов, вы же не говорите стоматологу: “мелочь какая — дырку просверлить и замазкой замазать”.

  • Нечеткость постановки задачи исполнителям

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

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

  • Сложность чужого кода

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

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

  • Несовместимость контента

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

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

  • Невнимание к статистике и тенденциям

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

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

  • Потери наработанных ссылок

    Сайт с течением времени обрастает входящими ссылками. При редизайне ссылки на одни и те же материалы могут поменяться, например, при замене CMS или при переходе с адресов страниц вида http://вашсайт.ru/абракадабра на ЧПУ (человеческие понятные урлы), то есть адреса страниц вида, например, http://вашсайт.ru/раздел/статья

    Чтобы избежать потерь ссылок, необходимо убедиться, что перед тем, как старый сайт будет заменен на обновленный, в файл .htacess на хостинге, где находится сайт, внесен список перенаправления (редиректов) со старых адресов страниц на новые. Обязательно убедитесь в следующих вещах:
    А. Что необходимость редиректов указана в вашем брифе и оттуда эта задача перешла в ТЗ
    Б. Что список страниц для ридеректа (название и текущий URL по каждой) создан на начальных этапах работ.
    В. Что перед переносом на хостинг нового сайта подготовлен .htacess с прописанными редиректами.
    Г. Что редиректы работают после запуска обновленного сайта.

В общем-то, простые пункты, хотя список может быть дополнен и расширен. Тем не менее, даже использование его в текущем объеме уже позволит эффективно осуществить редизайн вашего сайта.