Коли бриф на редизайн — доречний документ
Бриф на редизайн — це не загальна форма збору даних. Він потрібен для сайту, який уже працює в чомусь добре, а в чомусь — ні, і бриф має описувати зміни, а не просто побажання. Якщо команда переробляє корпоративний сайт на 40 сторінок, лендінг або портал продукту, у брифі слід зазначити, що саме має змінитися, а що має лишитися без змін.
Це важливо, бо робота над редизайном починається з уже наявної реальності. Уже є карта сайту, старі тексти, код відстеження, форми та CMS із власними звичками. Якісний бриф показує дизайнеру або агентству, де болить, які частини стабільні, а до яких небезпечно торкатися без плану.
Сприймайте його як документ для управління змінами. Це звучить сухо, але допомагає всім залишатися чесними. Фрилансер краще оцінить обсяг роботи, внутрішня команда уникне здогадок, а клієнтська сторона перестане сприймати кожну стару сторінку як чисте полотно.
Якщо ви шукаєте, як написати бриф на редизайн і як написати бриф на редизайн сайту покроково, почніть із рішення: бриф потрібен для трансформації, а не для початку з нуля. Саме це рішення змінює запитання, які ви ставите, і деталі, які збираєте.
Оцініть поточний сайт, перш ніж щось писати
Почніть із живого сайту. Не зі скриншотів за минулий квартал. Не з пам’яті про «проблему головної сторінки». Відкрийте поточні сторінки й випишіть, що існує, що зламано і про що ніхто не має забути під час редизайну.
Зробіть простий аудит із цифрами. Порахуйте сторінки, які залишаться, сторінки, які зміняться, і сторінки, які буде видалено. Зверніть увагу на сторінки з великим трафіком, форми з високим відсівом, розділи, що плутають користувачів, і контент, який застарів на рік або більше.
Технічні обмеження теж мають бути тут. Якщо поточний сайт залежить від застарілої CMS, кастомного чекаут-флоу або крихкої інтеграції, бриф має це згадати ще до того, як хтось почне малювати новий макет. Редизайн, який ігнорує поточну систему, часто створює другий проєкт: аварійне гасіння наслідків.
Додайте конкретні проблеми користувачів. Наприклад: звернення в підтримку згадують проблеми з пошуком на мобільних; відділ продажів каже, що сторінка з цінами спричиняє повторні дзвінки; редакційна команда не може оновлювати FAQ без допомоги розробника. Такі деталі кращі за загальні фрази на кшталт «сайтом важко користуватися».
Якщо у вас уже є внутрішня документація, додайте посилання. Команда, яка проводить аудит [безпеки сайту](https://ostohlo.com/en/blog/bezopasnost-sajta-zashchita.html) або налаштування аналітики, можливо, вже знає, де поточні ризики, і це зекономить години пізніше.
Визначте межі редизайну та те, що не входить у проєкт
Брифи на редизайн провалюються, коли межі проєкту залишаються нечіткими. Запишіть, що входить у обсяг робіт, простою мовою, а потім — що не входить. Другий список важливий не менше за перший, бо він не дає команді розповзтися в додаткові шаблони, додаткові функції та додаткові кола погоджень.
Будьте конкретні щодо меж. Якщо входять головна сторінка, сторінки послуг і форма зв’язку, так і напишіть. Якщо архів блогу, мовні версії або кабінет користувача не входять у цю фазу, теж зазначте це. Редизайн може зачепити 12 шаблонів, не змінюючи всю систему.
Пункти, що не входять у проєкт, — це не ознака лінощів. Це захист. Якщо прибирання SEO-контенту не входить у межі, напишіть це. Якщо нова фотосесія не передбачена, скажіть про це. Якщо редизайн має залишити того самого провайдера чекауту, це треба зафіксувати чітко, щоб ніхто не пропонував заміну на третьому тижні.
Одна корисна фраза в брифі на редизайн: «Зберегти поточний платіжний процес без змін». Інша: «У цій фазі не змінювати панель клієнта». Просто. Прямо. Важко прочитати неправильно.
Окресліть бізнес-контекст, бренд і контекст користувачів
Бриф на редизайн потребує контексту, але не брендового маніфесту. Підсумуйте бізнес-причину в одному короткому блоці: цілі щодо доходу, якість лідів, навантаження на підтримку, потреби найму або запуск нового ринку. Якщо редизайн підтримує злиття, ребрендинг або перехід із B2B до B2B2C, назвіть це.
Контекст бренду має включати ті частини, що змінилися. Можливо, компанія тепер більше орієнтується на enterprise-сегмент. Можливо, тон став менш грайливим і більш експертним. Можливо, візуальна система має виглядати спокійніше, бо стара версія здавалася надто рекламною. Такі деталі корисні. «Сучасний» — ні.
Контекст користувачів має відображати реальні зміни, а не припущення. Якщо аудиторія стала значно більш мобільною, це змінює шаблони і навігацію. Якщо постійним клієнтам тепер потрібен швидший доступ до акаунта, ніж новим відвідувачам — пояснення, то головна сторінка, меню і кабінет мають це відображати.
Тут достатньо одного речення: «Редизайн має підтримувати три аудиторії — нових лідів, наявних клієнтів і партнерів — без того, щоб головна сторінка тягнула на собі весь процес». Це дає команді дизайнерську задачу, яку можна вирішити, а не просто гасло.
Для великого проєкту може допомогти приклад структури пов’язаного [корпоративного сайту](https://ostohlo.com/en/blog/korporativny-sait-struktura.html) або сайту окремого бізнес-підрозділу, щоб команда краще зрозуміла, як організація вже себе подає.
Окремо опишіть потреби сторінок і структуру сайту
Бриф на редизайн не повинен обмежуватися фразою «нова навігація». У ньому слід назвати структуру сайту, основні шаблони та сторінки, які потребують особливої уваги. Почніть зі списку карти сайту, навіть якщо він попередній. Потім позначте пріоритетні сторінки першими.
Наприклад, сайт на 20 сторінок може потребувати нової головної сторінки, двох шаблонів послуг, макета кейсу, хабу ресурсів і сторінки контакту з іншою формою. Продуктовій компанії може знадобитися сторінка цін, сторінка порівняння та флоу реєстрації на пробну версію. У видавця можуть бути потрібні фільтри архіву та шаблони статей із сильнішими шляхами читання.
Поясніть команді, які типи сторінок повторювані, а які — винятки. Якщо шаблон блогу має витримувати 500 статей, але шаблон кейсу потребує кастомної подачі історії, так і напишіть. Якщо навігація має показувати лише топ-6 розділів, зазначте це. Тут допомагають цифри.
Саме тут варто зафіксувати зміни в ієрархії контенту. Сторінка може залишити той самий зміст, але потребувати іншого порядку: спочатку докази, потім можливості, далі процес, а FAQ — наприкінці. Такий напрямок не дає редизайну перетворитися на косметичну заміну зі старою структурою під капотом.
Деякі команди будують це, спираючись на [платформу вебаналітики та моніторингу сайту](https://ostohlo.com/en/work/astrina.html) або внутрішню карту контенту, щоб побачити, які сторінки вже несуть основне навантаження, а які використовуються недостатньо.
Зазначте міграцію контенту, погодження та відповідальних
Міграція контенту — це місце, де редизайни стають хаотичними. Бриф має вказати, що саме переноситься без змін, що переписується, що архівується і що потрібно створити з нуля. Якщо є 86 старих статей, а мігрувати треба лише 20, ця цифра має бути прописана чітко.
Відповідальність не менш важлива. Хто пише новий текст? Хто перевіряє юридичні формулювання? Хто погоджує заголовок головної сторінки? Якщо одну сторінку погоджують 4 людини, графік це відчує. Бриф має назвати відповідального на кожному етапі, а не лише фінального погоджувача.
Візуальні погодження потребують такої ж уваги. Маркетинг-лідер може погоджувати тон, продукт-лідер — точність функціоналу, а засновник може хотіти фінально подивитися на основне повідомлення. Це нормально, якщо в брифі вказана послідовність. Інакше дизайнер переписуватиме одну й ту саму сторінку тричі через три різні думки.
Власність на матеріали — це практично. Вкажіть, хто надає зображення, іконки, схеми, відгуки та відео. Якщо редизайн залежить від 12 скриншотів продукту, а їх ще немає, це ризик для термінів, а не дрібниця.
Перелічіть технічні, доступнісні та інтеграційні вимоги
Технічні примітки мають бути в брифі, навіть якщо дизайнер не верстає все сам. Вкажіть CMS, хостинг, інструменти для форм, налаштування аналітики та всі системи, з якими редизайн має інтегруватися. Якщо сайт використовує кастомну синхронізацію з CRM або білінговий інструмент, редизайн не може це ігнорувати.
Вимоги до доступності слід формулювати конкретно. Згадайте навігацію з клавіатури, контрастність кольорів, підписи до полів, стани фокусу, субтитри та сумісність із екранними читачами, де це доречно. Якщо в компанії є формальний стандарт, посилайтеся на нього. Якщо ні, попросіть команду дотримуватися визнаних рекомендацій щодо доступності й позначити сторінки, яким потрібна особлива увага.
SEO теж має бути тут, а не як запізніла думка. Бриф має вимагати обробки редиректів, збереження метаданих там, де це потрібно, і плану для сторінок, які перейменовуються або видаляються. Одна невдала карта редиректів може коштувати трафіку тижнями.
Якщо у вашої команди кастомний стек або приватне рішення, вкажіть це. Редизайн для [інфраструктури приватної мережі](https://ostohlo.com/en/work/s4m.html) дуже відрізняється від публічного сайту-візитівки, і бриф має відобразити це обмеження ще до того, як ідеї почнуть множитися.
Вимоги до тестування теж варто записати. Вкажіть, чи команда має тестувати на 3 браузерах чи на 5, чи мобільні брейкпоїнти фіксовані або гнучкі, і чи потрібні документовані QA-нотатки для фінального передання. Такі деталі економлять час у тиждень запуску.
Додайте критерії ухвалення рішень і наступні запитання для команди
Бриф на редизайн не має завершуватися фразою «будь ласка, запропонуйте ідеї». Він має просити команду відповісти на конкретні запитання. Який концептуальний підхід підходить до поточної проблеми сайту? Які ризики вони бачать? Що потребує додаткового дослідження? Які сторінки слід братися першими, а які можуть зачекати?
Попросіть оцінки діапазонами, якщо команда так працює. Попросіть описати залежності. Попросіть назвати, які припущення є найважливішими. Сильний бриф спонукає агентство або внутрішнього дизайнера заповнити прогалини, а не просто показати мудборд і гарний PDF.
У цьому розділі можна також визначити критерії ухвалення рішень. Наприклад: віддати пріоритет зрозумілості замість візуальної новизни або конверсії на сторінці контакту замість декоративності на головній. Якщо в брифі сказано, що редизайн не має погіршити швидкість сторінки більш ніж на вказану межу, команда знатиме, який компроміс найважливіший. Цифри допомагають тримати розмову в реальних межах.
Корисні наступні запитання: які шаблони потребують прототипного тестування? Які зони контенту потребують воркшопу з копірайтингу? Що можна повторно використати з поточної дизайн-системи? Де найбільший ризик запуску? Ці запитання допомагають команді перейти від брифу до плану, не вдаючи, що всі невідомі вже вирішено.
Деякі команди також просять посилання на [вибір CMS](https://ostohlo.com/en/blog/vybor-cms-wordpress-ili-kastom.html), якщо вибір платформи ще відкритий, адже обмеження платформи можуть змінити макет, процес редагування і навіть сам обсяг редизайну.
А якщо бриф впливатиме на запускову підтримку, додайте один рядок про те, що відбувається після go-live. Редизайн, який змінює URL, форми або інтеграції, часто потребує [підтримки сайту після запуску](https://ostohlo.com/en/blog/podderzhka-sajta-posle-zapuska.html) протягом кількох тижнів, а не лише одноденного передання.
Перед відправленням прочитайте бриф так, ніби команда ніколи не бачила сайт. Якщо бракує кількості сторінок, якщо пункт про те, що не входить у проєкт, сформульований нечітко, якщо не вказано відповідального за погодження — виправте це зараз. У цьому й різниця між брифом на редизайн, який рухає роботу вперед, і тим, що просто запускає зустріч.
