Когда говоришь «редизайн», почему-то всегда представляется, что это смена одной картинки на другую. Так ли это при редизайне сайта? И да, и нет. Визуал действительно меняется, иногда — радикально. Но за ним стоит еще тонна кропотливой работы «под капотом», которая как служба — на первый взгляд не очень-то видна.

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

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

Погнали!

Есть расхожая поговорка: «если вам что-то кажется, то скорее всего, вам не кажется». Так вот, с редизайном она ни капельки не работает, потому что многим кажется, что это — просто смена устаревшего дизайна на более свежий. А на деле это смена ВООБЩЕ ВСЕГО: и картинок, и бизнес-логики, и стека технологий.

Чтобы разобраться, как это работает, посмотрим на вполне осязаемый Land Cruiser. Да, вот ту огромную тачку, на которой любят ездить сильные мира сего. Был когда-то малыш Land Cruiser 80 — легенда автопрома с неубиваемой подвеской, деталями на совесть и отменной проходимостью. (Ну ладно, до него еще были 70, 60 и постарше, но кто их вспомнит сейчас вообще). С годами он морально устарел, поэтому случился редизайн и появились новые, улучшенные версии — Land Cruiser 100, а потом и Land Cruiser 200.

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

Смекаете? Пользуясь аналогией, получается вот что:

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

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

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

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

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

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

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

А там, где устаревший код и технологии, всегда ходят рядом:

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

Если мы все-таки хотим использовать старый код при редизайне, на этом сложности не заканчиваются. Допустим, мы перерисовали дизайн, структура сайта при этом кардинально не изменилась, но дополнения все равно есть: добавились новые фишки, кое-где — новая бизнес-логика, чтобы соответствовать рынку и вечно растущим потребностям пользователей. Чтобы внести такие изменения, нужно залезть в старый код и доработать его. 

И тут вас ждут новые приколы:

1. Сначала старый код нужно банально обновить, а это точно повлечет за собой длительную отладку из-за несовместимости версий. Сколько ошибок при этом будет, насколько они окажутся критическими и как дорого и долго их придется устранять, никто на старте вам не скажет. Но есть реальный риск, что исправление этих ошибок окажется куда дороже, чем переписать код с нуля.
2. Чужой код — потемки в 9 из 10 случаев. Часто он написан плохо, системой контроля версий в нем вообще не пахнет (а значит, его изменения нельзя отследить, отменить или восстановить в любое время), внутри использованы старые библиотеки (а это опять риск уязвимостей) и полно «костылей». Чтобы разгрести такое, нужно быть очень богатым мазохистом. 

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

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

Например, интернет-магазин сразу для B2B- и В2С-пользователей или маркетплейс. Сфера бизнеса непростая, бизнес-логика сложная, данных очень много, кастомизаций — тоже. Или заказчику крайне важно, чтобы сайт работал без перерывов хотя бы на секунду. Или всё вместе.

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

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

Например, на проекте «Океан бизнес-сувениров» код сайта заказчика был изначально грамотно написан на Laravel. А поскольку сам по себе бизнес-процесс был сложным (это и много опта, и много SKU, и много кастомизаций, и целых два личных кабинета), мы приняли решение взять его за основу для редизайна. Это тот самый редкий случай, когда редизайн действительно коснулся больше визуальной части проекта, чем переделок «под капотом», хотя те тоже были.

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

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

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

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

Бывает история, когда дизайн нравится, платформа устраивает, но код — откровенно плохой: «а давайте дизайн оставим, а код напишем новый?!».

Перенос дизайна в таком случае — очень увлекательная история, и редко со счастливым концом. Даже если у заказчика сохранились какие-то исходники макетов сайта (а такое вообще редко кто хранит), в 9 случаях из 10 они неактуальны: дизайн уже не совпадает с сайтом после его доработок, пользовательские сценарии устарели. А если даже дизайн на руках, нет никакой гарантии, что по ходу его не придется дорабатывать под нужды пользователей, тренды и лучшие практики отрасли.

Да и в целом, насколько рационально натягивать сову на глобус осовременивать старый дизайн, если можно сделать абсолютно новый продукт, который точно будет отвечать потребностям рынка и конечного клиента как с точки зрения визуала, так и с точки зрения технологий? Да еще и прослужит в итоге дольше? Ответ напрашивается, но озвучьте его сами :)

Когда речь идет о редизайне, по факту есть всего два варианта:

1. Редизайн, который на самом деле рестайлинг — когда за основу можно взять старый годный код и просто его доработать, обновив параллельно визуал. Важно помнить, что так бывает не часто — только если старый проект сделан прямыми руками на относительно современных технологиях.
2. Редизайн, который на самом деле разработка с нуля — когда проще и дешевле всё сделать заново, чтобы получить годный продукт, который прослужит 3−5 лет.

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

Окей, совсем недавно вы заморочились и вложили N-ные суммы в редизайн (равно переделку с нуля) своего проекта. Но тут стоит помнить, что в этом мире нет ничего стабильного и через 3−5 лет эту историю придется повторить, ведь любой, даже самый прогрессивный, дизайн со временем устаревает. С бэкендом — та же история. 

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

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

Так что у редизайна с хеппи эндом по факту всего два сценария:
1. Подешевле в моменте, подороже потом — адекватная системная техподдержка одной командой разработчиков сразу после запуска проекта и больше никаких переделок на ближайшие 3−5 лет. Сценарий для тех, кто хочет вложиться и забыть о проблеме на несколько лет.
2. Подороже в моменте плюс игра вдолгую — то же самое, плюс периодический рефакторинг кода и редизайн отдельных разделов, когда редизайн сайта превращается из проекта в непрерывный процесс. Сценарий для тех, кто готов думать и вкладываться стратегически уже сейчас, чтобы проект прослужил не стандартные 3−5 лет, а все 8−10 до полной переделки с нуля.

В какой лиге играть, выбирать только вам :)

Успехов!