Дизайн-бриф: що це і як його скласти для проєкту

Більшість дизайн-проєктів, які пішли не так, зламалися не у Figma. Вони зламалися ще до першого екрана, коли клієнт і дизайн-команда почали роботу з різними картинками в голові. Клієнт уявляє сміливий редизайн, дизайнер чує «освіжити головну». Маркетологу потрібно більше заявок, власник хоче, щоб сайт «виглядав дорого», і ніхто не записує, що з цього важливіше.

Саме для цього існує дизайн-бриф. Тож що таке бриф, якщо коротко? Це стислий структурований опис дизайн-проєкту: навіщо він потрібен, для кого, що треба зробити, які є обмеження і як вимірюватимемо успіх. Його складають до початку робіт, погоджують з усіма, хто прийматиме результат, і використовують як точку відліку для кожного рішення надалі.

У статті розбираємо, що включити в бриф, чим він відрізняється від креативного брифу і технічного завдання, що змінюється для сайту, мобільного додатка і брендингу, і як скласти бриф покроково. Наприкінці є шаблон, який можна скопіювати. Ми використовуємо таку структуру на старті кожного проєкту з розробки UI/UX дизайну, тож усе нижче перевірено на реальних клієнтських задачах.

Що таке дизайн-бриф і навіщо він проєкту

Якщо потрібне визначення в одне речення: дизайн-бриф — це погоджений опис дизайн-задачі простою мовою, який пояснює команді, яку проблему вирішити і як оцінювати рішення. Це не мудборд, не список улюблених кольорів і не договір, хоча він бере потроху з кожного.

Добрий бриф виконує три функції.

Створює спільне розуміння задачі. Усі учасники, від власника бізнесу до людини, яка щотижня оновлюватиме сайт, читають один і той самий опис цілей, аудиторії та обсягу робіт. Розбіжності з’являються в перший день, коли їх дешево виправити, а не на третьому колі правок.

Захищає проєкт від scope creep. Scope creep — це повільне розростання проєкту через дрібні доповнення: ще одна сторінка, ще одна мовна версія, ще одна роль користувача, «а заодно можна ще…». Кожне доповнення виглядає безневинно, але разом вони ламають терміни і бюджет. Бриф фіксує скоуп проєкту письмово, тож будь-яка зміна стає помітним рішенням, а не тихим дрейфом.

Дає основу для оцінки. Жодна агенція не назве надійні терміни чи вартість, не розуміючи обсяг робіт, обмеження і очікування. Що повніший бриф, то точніша оцінка і то менше неприємних сюрпризів згодом.

Крім того, бриф дає стейкхолдерам зрозумілу точку погодження. Коли бриф затверджено, команда знає, хто ухвалює рішення і про що домовилися.

Люди, які вперше замовляють дизайн, часто питають: навіщо бриф, якщо агенція все одно ставитиме питання? Відповідь у швидкості та якості. Без брифу перші дві-три зустрічі йдуть на збір базової інформації, яку можна було записати за годину. З брифом ці зустрічі одразу переходять до суті: варіантів, ризиків і пріоритетів. Ще одна неочевидна користь: складання брифу змушує команду клієнта домовитися всередині ще до залучення агенції. Часто найцінніший результат вправи не сам документ, а розмова між маркетингом, продажами і керівництвом про те, навіщо насправді потрібен проєкт.

Дизайн-бриф vs креативний бриф vs технічне завдання

Ці документи часто плутають, а в Україні особливо часто ставлять знак рівності між брифом і ТЗ. Насправді вони мають різні задачі.

Креативний бриф. Використовують переважно в рекламі та маркетингових кампаніях. Він зосереджений на повідомленні: яку одну ідею донести, до якої аудиторії, яким тоном, через які канали і з яким закликом до дії. Відповідає на питання «що люди мають подумати і відчути?».

Дизайн-бриф. Використовують для дизайну продукту, сайту, додатка чи бренду. Він зосереджений на проблемі, яку має вирішити дизайн, на користувачах, обсязі результатів і обмеженнях. Відповідає на питання «що треба спроєктувати, для кого і як ми зрозуміємо, що це працює?».

Технічне завдання (ТЗ). Використовують для розробки. ТЗ описує функції, дані, інтеграції, вимоги до швидкодії та безпеки настільки детально, щоб розробники могли це реалізувати і протестувати. Відповідає на питання «як саме має поводитися система?». ТЗ зазвичай пишуть після брифу і discovery, а не замість них. Якщо клієнт приходить з «ТЗ» на дві сторінки, найчастіше це насправді бриф, і це нормально.

Є ще SOW (statement of work): договірний документ або додаток до договору зі скоупом, де перелічені результати, терміни, умови оплати і критерії приймання. Часто його складають на основі брифу і ТЗ. Комерційна пропозиція агенції теж спирається на бриф: без нього вона буде або дуже приблизною, або міститиме багато припущень.

Що включити в дизайн-бриф

Це головна частина документа. У кожному блоці нижче є питання, на які варто відповісти клієнту. Довгих есе не треба: зазвичай вистачає двох-трьох чітких речень на питання.

Порядок блоків невипадковий. Спершу йде контекст і цілі, бо без них неможливо оцінити жодне дизайн-рішення. Далі аудиторія та обсяг робіт, які визначають, що саме проєктувати. Потім бренд, контент і технічні обмеження, які звужують простір рішень. І наприкінці бюджет, терміни й погодження, які перетворюють бриф на робочий план. Якщо на якийсь блок поки немає відповіді, не пропускайте його, а позначте як відкрите питання: так команда одразу бачить, що треба з’ясувати на discovery.

Компанія та контекст проєкту

Дизайнерам потрібен контекст, щоб ухвалювати правильні рішення. Бриф, що починається з «Нам потрібен новий сайт», змушує їх вгадувати.

Дайте відповіді на питання:

• Чим займається компанія, хто ваші клієнти і як ви заробляєте? (бізнес-модель)

• Як ви хочете, щоб вас сприймали порівняно з конкурентами? (позиціонування бренду)

• Що є зараз: поточний сайт або продукт, його сильні сторони і що не працює?

Додайте посилання на поточний сайт чи застосунок, за можливості доступ до аналітики і будь-які попередні дослідження. Що більше команда знає про відправну точку, то менше часу витратить на те, щоб відкривати її заново.

Цілі та метрики успіху

Цей блок найчастіше заповнюють розмитими побажаннями. «Сучасний дизайн» і «кращий користувацький досвід» — це не цілі. Ціль — це бізнес-результат.

Дайте відповіді на питання:

• Які бізнес-цілі має підтримати проєкт? Наприклад, більше якісних заявок, вищі онлайн-продажі, менше звернень у підтримку, вихід на новий ринок.

• Які KPI покажуть успіх і які в них поточні значення? Конверсія, кількість запитів на демо, середній чек, активація користувачів.

• Що змусить вас сказати «проєкт спрацював» через пів року після запуску?

Корисний фільтр — SMART-цілі, тобто конкретні, вимірювані, досяжні, релевантні й обмежені в часі. «Збільшити кількість заявок із сайту на 30 % протягом шести місяців після запуску» — це SMART-ціль. «Зробити сайт привабливішим» — ні.

Цільова аудиторія

Дизайн завжди створюють для когось. Без чіткої аудиторії команда проєктує для себе або для особистого смаку клієнта.

Дайте відповіді на питання:

• Хто основні групи користувачів і яка з них найважливіша для цього проєкту?

• Яку «роботу» вони хочуть виконати, коли приходять на сайт чи в застосунок? (Jobs to be Done, JTBD)

• Які в них основні болі сьогодні і з чим вони вас порівнюють?

Якщо у вас є персони з попередніх досліджень, додайте їх. Якщо немає, кілька речень про кожну групу однаково набагато краще, ніж нічого. Дизайн-команда може перетворити їх на повноцінні персони під час discovery.

Обсяг робіт і результати

Цей блок визначає, що саме буде зроблено. Це головний захист від scope creep.

Дайте відповіді на питання:

• Які сторінки або екрани входять у проєкт? Ідеально, якщо є чернетка карти сайту або список ключових екранів додатка.

• Які user flows найважливіші? Наприклад, залишити заявку, записатися на демо, оформити замовлення, зареєструватися.

• Які дизайн-матеріали ви очікуєте отримати? Вайрфрейми, фінальні макети, клікабельний прототип, UI kit або дизайн-систему, іконки, ілюстрації, анімації.

Прямо вкажіть і те, що не входить у проєкт. «Шаблони блогу не входять у перший етап» економить тижні непорозумінь.

Бренд і візуальні референси

Візуальні вподобання суб’єктивні, тож бриф має зробити їх максимально конкретними.

Дайте відповіді на питання:

• Чи є брендбук (логотип, кольори, шрифти, правила для зображень)? Він незмінний чи відкритий до змін?

• Які сайти або застосунки вам подобаються і що саме подобається в кожному? Якщо можете, зберіть їх у мудборд.

• Від яких референсів конкурентів ви хочете відрізнятися і чому?

Списки «що подобається і що ні» напрочуд корисні. «Подобається, як цей сайт працює з вільним простором, не подобаються стокові фото людей, що тиснуть руки» дає дизайнеру більше орієнтирів, ніж «чисто і сучасно».

Контент і технічні обмеження

Дизайн не існує у вакуумі. Він має працювати з реальним контентом і реальними технологіями.

Дайте відповіді на питання:

• Хто надасть контент: тексти, фото, відео, дані про товари? Коли він буде готовий?

• Яку CMS використовуватиме сайт або на які платформи орієнтований продукт (web, iOS, Android)?

• Які інтеграції потрібні: CRM, платіжні сервіси, служби доставки, онлайн-запис, аналітика?

• Скільки мовних версій буде на старті і чи плануються нові? Для українських компаній типовий набір UA та EN, інколи ще кілька мов для експортних ринків.

• Чи є вимоги до доступності, наприклад відповідність WCAG?

Контент найчастіше забувають. Дизайн без реального контенту дає макети, які «ламаються», щойно приходять справжні тексти. Особливо це помітно в мовних версіях: англійський текст зазвичай коротший за український, і кнопка, яка ідеально виглядала англійською, може не вмістити український варіант.

Бюджет, терміни та погодження

Багато клієнтів не називають бюджет, сподіваючись на вигіднішу пропозицію. На практиці діапазон бюджету допомагає агенції запропонувати реалістичний обсяг, а не «мрію», яку згодом доведеться різати.

Дайте відповіді на питання:

• Який діапазон бюджету і чи є гнучкість?

• Чи є фіксовані дати: запуск продукту, виставка, рекламна кампанія? Які ключові етапи?

• Хто ухвалює рішення, хто дає зворотний зв’язок і скільки раундів правок заплановано на кожному етапі?

Процес погодження заслуговує на окрему увагу. Проєкт з однією людиною, яка ухвалює фінальне рішення, рухається в рази швидше, ніж проєкт, де п’ятеро дають суперечливі коментарі до кожного екрана.

Якщо точного бюджету ще немає, це не проблема. Опишіть задачу якомога детальніше, і агенція запропонує кілька варіантів обсягу: базовий, оптимальний і розширений. Реалістичну оцінку термінів і вартості ми даємо саме після брифу, бо лише тоді зрозуміло, що саме треба зробити.

Особливості брифу для різних проєктів

Структура вище підходить для більшості проєктів, але кожен тип потребує кількох додаткових деталей. Нижче — короткі приклади для трьох найпоширеніших типів.

Бриф на дизайн сайту

Бриф на дизайн сайту варто доповнити:

• Картою сайту. Навіть чернетка списку сторінок з ієрархією допомагає оцінити обсяг і спланувати навігацію.

• CMS. На якій системі працюватиме сайт (WordPress, Webflow, власна CMS) і хто редагуватиме контент після запуску.

• SEO-вимогами. Які сторінки зараз приводять трафік і мають зберегти свої URL, які запити важливі, як будуть організовані мовні версії (UA/EN), щоб пошукові системи правильно їх розуміли.

• Відповідальністю за контент. Хто пише й погоджує тексти, хто надає зображення, хто підтримуватиме сайт.

Для редизайну додайте дані аналітики поточного сайту: топ сторінок входу, основні джерела трафіку і точки конверсії. Бриф на редизайн без цих даних часто призводить до гарного сайту, який втрачає пошуковий трафік.

Для інтернет-магазину до брифу варто додати ще кілька пунктів: кількість товарів і категорій, способи оплати (наприклад, LiqPay, WayForPay чи оплата частинами), служби доставки, з якими працюєте, облікову систему і маркетплейси, на яких уже продаєте. Ці інтеграції сильно впливають на структуру кошика й оформлення замовлення, тому дизайнер має знати про них до того, як почне малювати checkout.

Бриф на дизайн мобільного додатка

Бриф на мобільний додаток варто доповнити:

• Гайдлайнами платформ. Чи має додаток точно дотримуватися iOS Human Interface Guidelines і Material Design, чи використовувати повністю власний інтерфейс на обох платформах?

• Онбордингом. Що новий користувач має зрозуміти і зробити за першу хвилину?

• Ключовими user flows. Три-п’ять задач, які визначають успіх, наприклад реєстрація, заповнення профілю, перше замовлення чи бронювання.

• Функціями пристрою. Камера, геолокація, сповіщення, офлайн-режим, біометрія.

Для наявного додатка додайте відгуки з App Store і Google Play та звернення в підтримку. Це безкоштовне дослідження користувачів.

Бриф на брендинг

Бриф на брендинг варто доповнити:

• Логотипом. Новий логотип чи оновлення наявного? Де його використовуватимуть: сайт, іконка застосунку, упаковка, вивіски, мерч?

• Фірмовим стилем. Які елементи потрібні крім логотипа: палітра, типографіка, графічні елементи, стиль фото, шаблони.

• Tone of voice. Як бренд має звучати в текстах? Офіційно чи дружньо, експертно чи з легкістю?

• Архітектурою бренду. Чи є суббренди, продукти або послуги, яким потрібна власна айдентика в межах однієї системи?

Детальніше про склад роботи читайте в статті про те, що входить у розробку бренд-айдентики. А якщо плануєте повноцінний проєкт айдентики, наша сторінка послуги брендингу показує, як ми його структуруємо.

Як скласти дизайн-бриф: покроково

Скласти бриф — це не стільки про вміння писати, скільки про збір правильної інформації від правильних людей. По суті, бриф — це кілька коротких розмов, зведених в один документ. Ось процес, який ми рекомендуємо.

Крок 1. Зберіть внутрішні вимоги. Перед зверненням до агенції проведіть короткі інтерв’ю зі стейкхолдерами всередині компанії. Спитайте відділ продажів, з чим мають труднощі клієнти, підтримку, що вони чують щодня, маркетинг, що їм потрібно від сайту, а керівництво, як виглядає успіх. Запишіть відповіді.

Крок 2. Проведіть аналіз конкурентів. Складіть список з трьох-п’яти конкурентів і запишіть, що в них добре, а що погано. Це дає брифу конкретні референси і допомагає описати, чим ви хочете відрізнятися.

Крок 3. Заповніть анкету-бриф. Використайте блоки з цієї статті або анкету агенції. Дайте відповідь на кожне питання, навіть якщо це «поки не знаємо». Чесне «невідомо» корисніше за вигадану відповідь.

Крок 4. Проведіть discovery-воркшоп. Для всього, що більше за простий лендинг, робоча сесія з дизайн-командою — найефективніший спосіб завершити бриф. За дві-чотири години команда ставить уточнювальні питання, перевіряє припущення і перетворює відкриті питання на рішення. На складних проєктах це переростає в повноцінну discovery-фазу з дослідженнями, прототипуванням і детальним скоупом.

Крок 5. Перевірте і отримайте погодження. Надішліть фінальний бриф усім, хто ухвалює рішення, і отримайте явне погодження. З цього моменту будь-яка зміна цілей чи обсягу стає свідомим рішенням, яке може вплинути на терміни й бюджет.

Скільки триває весь процес? Для лендингу чи невеликого корпоративного сайту бриф можна підготувати за два-три дні. Для більшого сайту, клієнтського кабінету чи мобільного додатка закладіть один-два тижні, включно з внутрішніми інтерв’ю і воркшопом. Цей час окупається: він значно коротший за затримки, які дають нечіткі цілі посеред проєкту.

Практична порада: ведіть бриф у спільному документі, а не в листуванні. Коментарі, версії й рішення залишаються в одному місці, а нові люди в проєкті розбираються за п’ятнадцять хвилин, а не перечитують місяці переписки.

Хто має брати участь у підготовці брифу. Бриф, написаний однією людиною, зазвичай відображає одну точку зору. Залучіть тих, хто оцінюватиме результат: людину, яка ухвалює рішення, маркетинг, продажі чи підтримку, які чують, що питають клієнти, і того, хто знає технічні обмеження. Одна годинна зустріч, на якій ці люди разом відповідають на питання брифу, часто економить тижні суперечливих відгуків згодом.

Як дизайнер використовує бриф. Добрий бриф не лягає в шухляду після старту. Дизайнер повертається до нього на кожному етапі: формує дослідження і перелік питань до користувачів, обирає напрям концепцій, аргументує рішення на презентаціях. Коли клієнт каже «мені не подобається», бриф допомагає перевести розмову з особистих смаків на цілі: чи працює цей варіант на аудиторію і задачі, які ми записали. Тому формулюйте цілі й аудиторію так, щоб за ними можна було оцінити макет.

Типові помилки в дизайн-брифі

Більшість проблем, які ми бачимо в брифах, повторюються. Кожна коштує часу, грошей або обох.

Розмиті цілі. «Хочемо сучасний сайт» не дає ні напрямку, ні способу оцінити результат. Дизайн-команда вгадує, клієнт відхиляє варіанти, і проєкт ходить по колу правок.

Немає критеріїв успіху. Без вимірюваних критеріїв погодження перетворюється на питання смаку. Проєкт можна «завершити», так і не зрушивши жодної бізнес-метрики.

Дизайн «комітетом». П’ять стейкхолдерів, п’ять думок і немає людини з останнім словом. Зворотний зв’язок суперечить сам собі, кожне коло додає нові побажання. Рішення просте: призначте одну людину, яка ухвалює фінальне рішення, а коментарі інших збирайте до того, як вони потраплять до дизайн-команди.

Немає контент-плану. Дизайн погоджують з текстом-заглушкою, потім реальний контент приходить із запізненням і не вміщається. Макети переробляють, запуск зсувається на тижні.

Забагато рішень, замало проблеми. «Додайте чат-бот, 3D-анімацію і темну тему» описує функції, а не потреби. Добрий бриф пояснює проблему і дає команді запропонувати найкраще рішення.

Приховані обмеження. CMS, обов’язкова інтеграція чи фіксована дата запуску з’являються посеред проєкту. Кожне з них може знецінити вже зроблену роботу.

Копіювання чужого брифу. Шаблон корисний як структура, але відповіді мають бути вашими. Бриф, переписаний з іншого проєкту або згенерований без участі команди, дає загальні формулювання, які не допомагають ухвалювати рішення.

Усе це дешево виправити на етапі брифу і дорого виправляти потім.

Швидка самоперевірка перед відправкою: чи зможе дизайнер, який ніколи не чув про вашу компанію, прочитати бриф і за дві хвилини переказати, навіщо проєкт, кому він служить, що треба зробити і як оцінюватимуть успіх? Якщо так, бриф готовий. Якщо дизайнеру треба буде поставити більше кількох базових питань, бриф варто доопрацювати.

Шаблон дизайн-брифу

Нижче шаблон, який можна скопіювати в документ і заповнити. Це і бриф для дизайнера, і чек-лист для вас: якщо рядок порожній, це питання, на яке треба відповісти до старту робіт. Приклади умовні.

Як користуватися шаблоном на практиці? Заповніть його самостійно, навіть якщо в деяких рядках буде «не знаємо». Потім надішліть агенції разом із посиланнями на поточний сайт і доступом до аналітики. Після першої зустрічі агенція поверне доповнену версію з уточненнями, відкритими питаннями і пропозицією щодо етапів. Ця версія і стає робочим документом проєкту.

Бриф для конкурсу кількох агенцій. Якщо ви обираєте підрядника з кількох кандидатів, дайте всім однаковий бриф і однакові питання для відповіді: як вони бачать задачу, який процес пропонують, які ризики помічають і що потрібно від вас. Так пропозиції можна порівнювати між собою, а не лише за ціною і портфоліо. Окремо попросіть кожну команду поставити уточнювальні питання до брифу: якість питань часто краще за презентацію показує, наскільки глибоко агенція розібралася в задачі.

Збережіть фінальну версію брифу разом із макетами: через рік вона пояснить новим людям, чому дизайн саме такий.