Клиенты часто просят «этапы с датами»: исследование, дизайн, передача. Календарь так строить можно — и мы так делаем. Но внутри студии So1omon эти слова означают петли. Каждая петля возвращает уточнения в бриф. Если считать процесс строго линейным, правки выглядят как сбой. Если считать петлями — правки выглядят как работа.
Петля 1. Исследование
Здесь мы собираем не «вдохновение», а ограничения: аудитория, носители, юридические требования к тексту, технические рамки вёрстки, кто принимает решения и кто реально будет поддерживать макеты через полгода. Короткое интервью с заказчиком плюс разбор существующих материалов обычно важнее мудборда. На выходе — одностраничный бриф с критериями успеха и списком того, чего мы сознательно не делаем в этой итерации.
Петля 2. Система
До отрисовки всех экранов фиксируем токены: цвет, тип, отступы, радиусы, состояния фокуса и ошибок. Рисуем два-три ключевых шаблона — не больше. Цель — согласовать ритм и характер, а не утвердить весь продукт. Именно на этой петле чаще всего возвращаемся в бриф: выясняется, что «строгий B2B» на деле должен быть теплее, или что табличная плотность важнее красоты карточек. Дешевле узнать это на системе, чем на сорока макетах.
Петля 3. Сборка
Здесь появляются остальные экраны, адаптив, пустые и ошибочные состояния, спецификации и экспорт. Передача у нас — не «скинуть архив», а короткая сессия с командой внедрения: пройтись по токенам, показать спорные места, договориться о том, кто правит гайдлайн после запуска. Если в сборке всплывает системный вопрос, мы не маскируем его локальным костылём — возвращаем в петлю системы и обновляем документ.
Почему так спокойнее
Линейный план обещает контроль и часто дарит разочарование. Петли обещают ясность: на каждом витке видно, что уже решено, а что ещё гипотеза. Заказчик получает меньше сюрпризов, студия — меньше ночных перерисовок. А «финальный макет» становится честным понятием: это версия, согласованная после нужного числа петель, а не файл с самой поздней датой в названии.
Если выстраиваете процесс у себя, начните с простого правила: любая правка должна либо улучшать текущую петлю, либо явно открывать предыдущую. Правки «между делом» без адреса — главный источник хаоса в визуальных системах.