Сильний дизайн не компенсує файли в чатах, незавершені модулі й вправи без інструкцій. Ця стаття — не процес дизайнера від аудиту до передачі системи. Це те, що експерт збирає до відкриття макета: де лежить правда, що затверджено, чим є кожен блок.
Готовність не означає, що кожне речення вічне. Вона означає: відомо, що можна верстати, що ще зміниться, і хто має останнє слово по тексту.
Чому це варто зробити до макета
Якщо завтра зникне розділ і з’явиться інша модель, сторінку збирають двічі. Правка змісту тоді маскується під «посунь заголовок». Позначте статуси заздалегідь — і дизайнер не співредагує програму без мандата.
Створити єдине джерело правди
Одна папка. Одна логіка імен. Один документ або набір документів, де лежить актуальний текст модуля — не в п’яти Google Doc і трьох чатах. Уроки, вправи, посилання, затверджені формулювання моделей, службові тексти для платформи й листів. Архів окремо, щоб старі версії не маскувалися під поточні.
Структура може бути простою: модуль / урок / вкладення / примітка про статус. Важливіший принцип, ніж краса дисків: людина, яка відкриває проєкт уперше, знаходить правду без екскурсії по переписці.
Позначте власника папки. Якщо «актуальне» може перезаписати будь-хто без правила, джерело правди знову розпадається. Дизайн тоді будується на піску, навіть коли пісок добре названий.

Позначити функцію кожного блоку
До верстки варто знати, чим є абзац. Теорія. Приклад. Визначення. Фреймворк. Дія. Рефлексія. Навігація. Службова інструкція. Якщо все виглядає як суцільний текст, дизайнер змушений здогадуватися. Іноді вгадує. Іноді будує красиву сторінку не для того жесту, який був у задумі уроку.
Позначки можуть бути простими: кольором у документі, коротким тегом, коментарем «це вправа, 10 хвилин, поля для трьох відповідей». Для схем — що є кроком методу, а що підписом прикладу. Для слайдів — що людина має побачити, а що лише почути.
Це не про те, щоб експерт став дизайнером. Це про те, щоб намір уроку був видимий до сітки. Інакше сітка нав’яже свій намір.
Скласти карту «цей блок → цей носій»
Не описуйте всю екосистему курсу. Заповніть просту таблицю передачі: цей текст іде в workbook, цей — лише на слайд, цей — у лист, цей лишається сказаним у відео. Так зникають подвійні макети однієї моделі й офер, який обіцяє шаблон, якого немає в папці.
Зв’яжіть назви в таблиці з назвами в уроці. Різне ім’я моделі в карті й у тексті — уже помилка передачі, не дизайну.

Дизайн починається не тоді, коли відкрито макет, а коли відомо, що вже не зміниться завтра вранці.
Підготувати схеми та вихідні матеріали
Зберіть дані, підписи, логотипи, права на зображення, чорнові ескізи схем. Не треба самостійно «оформлювати» їх у фінальну естетику. Треба, щоб не доводилося шукати, чи можна це фото, як точно називається крок, звідки цифри в таблиці.
Чорнова схема від експерта цінна навіть у вигляді фото з дошки. Вона показує логіку. Чистовик без логіки дизайнер вигадає — і ви отримаєте красиву неправду. Краще незграбний, але чесний начерк.
Логотипи партнерів, шрифтові ліцензії, вимоги платформи до обкладинок — теж частина передачі. Якщо вони з’являються в кінці, система знову ламається під чужі пропорції.
Пройти фінальний чекліст передачі
Перед стартом макетів зафіксуйте письмово лише вхід у проєкт. Обсяг етапу. Статус кожного модуля: затверджено / можна полірувати формулювання / структура ще зміниться. Хто приймає текст. Хто приймає візуал і скільки циклів. Де лежить джерело правди. Що свідомо не входить: продажний копірайт, переклад, відео.
Це не передача дизайн-системи команді після здачі. Це пакет, без якого макет не варто починати. Година на чекліст зберігає тижні на «ми вже зверстали те, що ви вчора викинули».




