Більшість команд просять не той проєкт.
Кажуть «редизайн», коли мають на увазі «перебудова». Кажуть «перебудова», коли мають на увазі «редизайн». Двоє слів звучать взаємозамінними. Проєкти за ними — ні. Редизайн — це шість тижнів візуальної роботи поверх робочої інфраструктури. Перебудова — це три-шість місяців заміни інфраструктури з візуальною роботою як її малою частиною.
Вибір неправильного — дорогий. Виберете редизайн, коли мала бути перебудова — відвантажите красивий сайт, що все ще вантажиться чотири секунди. Виберете перебудову, коли редизайн би вистачило — витратите три місяці на заміну коду, що працював.
Цей пост — це фреймворк, який ми використовуємо, щоб зрозуміти, який проєкт ви насправді робите.
Визначення
Редизайн. Візуальна і контент-робота. Структура сайту лишається переважно тією ж. Код лишається. CMS лишається. Що змінюється: типографіка, колір, лейаут, копірайт, можливо, IA.
Перебудова. Робота з кодом і інфраструктурою. Часто інший стек, інший CMS, інший хостинг. Візуальний дизайн може лишитись, може трохи змінитись, може бути повністю перероблений. Платформа під ним — це і є проєкт.
Гібрид. Редизайн видимого сайту поверх перебудови платформи. Це поширеніше за будь-яку чисту опцію. Це правильна відповідь, коли видимий сайт має identity-проблеми, а платформа — технічні, і вирішення їх окремо означало б два проєкти.
Сигнали для редизайну
Ви, ймовірно, потребуєте редизайну (не перебудови), коли:
Платформа працює нормально. Lighthouse-бали пристойні, CMS використовний, деплої рутинні. Команда не уникає торкатись коду. Що не так — це те, що бачить користувач.
Бренд зрушив. Нове позиціонування, нова аудиторія, новий тон. Сайт каже одне; компанія — інше. Візуальна і контент-робота виправляє те, що зламано.
IA застаріла. Сторінки існують у неправильних місцях, навігація неправильна, конверсійні шляхи додавались і прибирались з часом без чистки. IA-керований редизайн виправляє більшість цього. Див. наш пост про IA для маркетингових сайтів щодо методу.
Конкретна секція не дотягує. Bounce на сторінці цін зависокий. Секція кейсів не отримує трафіку. Контактна форма має 70% drop-off. Таргетна робота з редизайну, не перебудова.
Ви описали б проблему як «відчувається застарілим» або «не відображає, хто ми тепер». Це візуальні і контент-проблеми.
Сигнали для перебудови
Ви, ймовірно, потребуєте перебудови (не редизайну), коли:
Платформа — пляшкове горло. Не можна додати login клієнта, бо CMS цього не підтримує. Додавання нового типу сторінки забирає тиждень через те, як структуровані шаблони. Редактори мають пінгувати інженерію за рутинні зміни. Платформа стоїть на шляху роботи.
Продуктивність не можна виправити без перебудови. Сайт на WordPress з 47 плагінами. Lighthouse-бали — 30, і такими і були два роки. Кожне «покращення продуктивності» — пластир. Фундаментальна архітектура не дозволить продуктивності, яку треба.
Команда не може відвантажувати на цьому. Інженери уникають торкатись кодової бази. Баги виправляють днями. Онбординг нового розробника — місяць. Платформа — це технічний борг, що накопичується.
Безпеку або комплаєнс не підтримати. Старий PHP, неподдержувані залежності, оригінальний фреймворк — end-of-life. Не вийде дійти до комплаєнсу звідси без заміни субстрату.
Ви описали б проблему як «ми переросли це» або «не можемо швидко рухатись на цьому». Це проблеми платформи.
Сигнал гібрида
Гібридний паттерн (редизайн + перебудова одночасно) — правильний, коли обидва списки вище звучать правдиво. Платформа — проблема ТА бренд зрушив. IA застаріла ТА CMS не може підтримати кращу IA. Продуктивність погана ТА візуальний дизайн теж застарілий.
Це найпоширеніше, коли сайту більше трьох-чотирьох років. Бренди зрушують, технології рухаються, що було правильною відповіддю у 2022 — не у 2026.
Гібрид дорожчий за будь-яку чисту опцію. Це не 2x — є реальні ефективності у робленні їх разом (IA-робота інформує нову структуру коду; brand-робота інформує дизайн-систему). Але це не малий проєкт.
Редизайн, що мав бути перебудовою
Команда прийшла до нас рік тому. Хотіли редизайн. Сайт відчувався повільним, бренд зрушив, конверсія була погана. Ми майже взяли бриф на редизайн.
Спочатку ми зробили аудит продуктивності. Знахідки:
- Сайт був на legacy-CMS, що команда активно намагалась замінити.
- Час завантаження сторінок — 4-6 секунд, без виходу з CMS не виправити.
- Додавання нової фічі (клієнтський портал, який хотіли запустити у 2026) було неможливим на поточній платформі.
- Brand-редизайн виглядав би красиво і все ще вантажився повільно, все ще блокував би запуск порталу.
Ми штовхнули назад. Правильний проєкт — це перебудова, що включає роботу з редизайну. Вони думали про редизайн, бо редизайн звучав менше і менш ризиковано. Аудит показав, що «менше» означало «неправильно».
Ми зробили гібрид. Зайняло п'ять місяців. Новий сайт був швидшим, клієнтський портал запустився вчасно, brand-робота лягла. Якщо б вони зробили редизайн першим, перебудову зробили б через півроку все одно, з brand-роботою на переробку поверх нової платформи. Чисто: дев'ять місяців роботи, два редизайни заплачено, перебудова все ще попереду.
Вибір правильного проєкту першим заощадив рік.
Перебудова, що мала бути редизайном
Протилежний випадок: команда прийшла з проханням про повну перебудову. Сайту чотири роки. Команда впевнена, що це неправильний стек, неправильний CMS, неправильний хостинг.
Ми попросили їх обрати три конкретні проблеми, які перебудова вирішить. Список:
- «Завантаження сторінки повільне». Аудит: насправді 1.8s LCP, що нормально. CEO був на телефоні 2017 у підвальному офісі.
- «CMS погана». Розслідування: CMS — Sanity, команда використовувала через неправильний workflow. Два дні навчання це виправили б.
- «Не можемо оновити brand-колір». Інспекція: він був hardcoded у трьох місцях. Pull request змінив би їх усі за годину.
Жодне з цього не було проблемою платформи. Фрустрація команди була реальною, але причина — не та, що думали. Перебудова була б шість місяців заміни коду, що працював, із завершенням у сайті, що має ті самі проблеми, бо проблеми не в коді.
Ми зробили тижневий аудит, двотижневий таргетний фікс і чотиритижневий редизайн візуальної ідентичності. Команда отримала більшість того, що хотіла, за сім тижнів замість шести місяців. Оригінальна платформа вижила. Заощадили тризначну суму інженерного часу і квартал велосіті.
Фреймворк
Три питання, у порядку:
- Чи може платформа підтримати те, що треба відвантажити у наступні 12 місяців?
- Якщо ні — потрібна перебудова (або гібрид). - Якщо так — далі до 2.
- Чи може команда відвантажувати на поточному коді у розумному темпі?
- Якщо ні — потрібна перебудова (або гібрид). - Якщо так — далі до 3.
- Чи видима проблема — це бренд, IA або контент?
- Якщо так — потрібен редизайн. - Якщо ні — аудитуйте далі. «Видима проблема» може насправді бути проблемою платформи у переодяганні.
Більшість команд провалюються на кроці 2. Вони адаптувались до повільного темпу і не усвідомлюють, скільки тертя платформа додає, поки не побачать, як виглядає невзятий темп.
Коли пропустити фреймворк
Якщо платформа end-of-life (фреймворк не підтримується, хостинг депрекейтиться, CMS-компанія мертва), вам потрібна перебудова попри все інше. Ринок диктує таймінг.
В іншому разі: не пропускайте фреймворк. Ціна вибору неправильного — величезна.
Розмова, яку ми ведемо
Коли клієнт приходить з «нам потрібен редизайн» або «нам потрібна перебудова», наша перша задача — зрозуміти, який проєкт їм насправді треба. Розмова зазвичай йде так:
- Яка конкретна проблема, яку ви хочете виправити?
- Що ви пробували? Що спрацювало, що ні?
- Покажіть найгіршу сторінку.
- Покажіть, що редактори роблять у типовий тиждень.
- Покажіть, чого інженери уникають торкатись.
До кінця цієї розмови ми зазвичай знаємо, який проєкт правильний. Близько 30% часу клієнт погоджується одразу. Близько 50% — він здивований і потребує дня подумати. Близько 20% — штовхається назад, і ми або приймаємо його кадрування (іноді він знає свою ситуацію краще), або розходимось мирно.
Якщо дивитесь на «редизайн чи перебудова» і хочете другу думку, почніть розмову. Чесно скажемо, який проєкт робите, і якщо це не той, який нам варто робити для вас — теж скажемо.