История версий макета: почему нельзя вести проект без неё
Без истории версий макета невозможно доказать, кто и когда внёс правку, откатиться к одобренному варианту или защититься от «а мы же договаривались иначе». Это не фича конкретного инструмента, а условие, без которого проект рано или поздно упирается в спор, который нечем решить. Команды вроде YuSMP Group, которые ведут разработку веб-приложений, формализуют версии макета ещё на этапе дизайна — это снимает половину споров на приёмке. Дальше — что именно ломается без версионирования, почему ручные способы не спасают и как закрыть это без привязки к одному тулу.
Что ломается в проекте, когда истории версий нет
Самый частый сценарий — файл, который превращается в цепочку имён: «макет», «макет_v2», «макет_v2_правки», «макет_v2_ИСПРАВЛЕНО_финал». Через неделю никто не может сказать, какой из них актуален и что именно изменилось между версиями, а новый участник проекта вообще не поймёт, с какого файла начинать. Второй сценарий болезненнее: клиент заявляет «вы же сами одобрили старый вариант», а подтвердить или опровергнуть это нечем — переписка велась в трёх местах, и ни в одном нет привязки к конкретному файлу или дате. Третий — случайная перезапись: кто-то сохранил макет поверх чужих правок во время параллельной работы, и часть работы просто исчезла, а восстановить её неоткуда, потому что предыдущего состояния больше не существует. И последнее — невозможно показать заказчику прогресс по датам: прогресс есть, но предъявить его можно только на словах, а не фактами из системы.
По отдельности каждая из этих ситуаций выглядит как досадная мелочь. Но в проекте, который идёт несколько месяцев и проходит через руки дизайнера, арт-директора и менеджера, они накладываются друг на друга. Спор про «кто одобрил» случается именно тогда, когда до дедлайна остаётся меньше всего времени — а значит, цена отсутствия истории версий всегда выше, чем кажется на старте.
Почему «просто называть файлы по-разному» не работает
Ручное версионирование через имена файлов или папки вроде «Правки_1», «Правки_2_финал» кажется решением, но ломается уже на команде из трёх-четырёх человек. Каждый называет файлы по-своему, папка быстро превращается в свалку, а главное — в имени файла нет места для ответа на вопрос «что и почему изменено». Видно, что версия новая, но не видно, кто её сделал и зачем. Это решение, которое работает ровно до первого конфликта версий — а конфликт версий в проекте с несколькими участниками не «если», а «когда».
У этой проблемы есть зрелое решение в разработке программного обеспечения — системы контроля версий, где каждое изменение фиксируется с автором, временем и комментарием, а любое состояние файла можно восстановить. Сам принцип описан в общих источниках о системах управления версиями, и он напрямую переносится на дизайн-процесс: разница только в том, что макет — это не текстовый файл, а визуальный объект, поэтому версии нужно сравнивать не построчно, а бок о бок.
Как на самом деле работает история версий
Рабочая схема строится на двух уровнях. Автосохранение по чекпойнтам фиксирует промежуточные состояния без участия человека — это страховка от потери правок, даже если никто не вспомнил сохранить версию вручную. Поверх него — ручные именованные версии с коротким комментарием: что изменилось и почему. Этот принцип не привязан к одному инструменту: он одинаково работает для макета в Figma, для уже собранного сайта, для видео-ролика или презентации. Важна не конкретная программа, а то, что у каждой значимой точки проекта есть автор, дата и причина изменения — и к ней можно вернуться в один клик, а не через раскопки переписки.
Отдельно стоит сравнение версий бок о бок: именно оно превращает абстрактное «что-то поменялось» в конкретный ответ на вопрос «что именно». Когда новая и предыдущая версии макета показаны рядом, разница видна сразу — лишние вопросы на созвоне отпадают сами.
Нужна ли студии «семантика» версий, или достаточно автосохранения?
Автосохранения достаточно, чтобы ничего не потерять технически, но недостаточно, чтобы ориентироваться в прогрессе проекта. Полезно разделять мелкую правку (поправили отступ, заменили иконку) и значимое изменение (новая структура блока, другой подход к разделу) — и вести короткий changelog именно по значимым версиям. Не нужна формальная нотация вроде semver из разработки: достаточно одной строки на версию вида «добавили блок с отзывами по запросу клиента» или «переработали шапку после правок на созвоне». Этого хватает, чтобы через месяц восстановить логику решений, не поднимая переписку и не дёргая того, кто вёл проект тогда, а сейчас занят другим.
Такой лёгкий changelog особенно выручает при передаче проекта другому дизайнеру — в отпуск, при смене исполнителя или просто когда проект «подвисает» на несколько недель. Без него новый человек тратит день на то, чтобы понять контекст; с ним — пару минут на чтение пяти строк.
Как это закрывается без привязки к одному инструменту
На практике макет, правки и обсуждение живут в разных местах: дизайн — в Figma, сайт — уже в проде, презентация — отдельным файлом, видео — вообще на внешнем хостинге. Привязывать весь процесс к одному инструменту неудобно, если сам продукт проходит через разные форматы на разных этапах. Konndor собирает клик-комментарии и историю версий в одном месте для всех этих форматов — сайтов, ссылок на Figma, изображений, видео и презентаций — без регистрации для того, кто оставляет правки, и с видимым автором и датой у каждого изменения.
