Дизайн согласовали. А дальше что? Как я веду проект до реализации

Дизайн можно согласовать за один звонок. А вот довести его до реализации — совсем другая задача.

После согласования макетов проект не заканчивается. Наоборот, начинается этап, где появляется особенно много мелочей: какие экраны уже готовы, что ждём от клиента, какие вопросы нужно уточнить, что передано в разработку, где ещё нужны состояния и что внезапно изменилось по ходу работы.

Если всё это держать только в переписке, часть решений довольно быстро начинает теряться. Поэтому в проектах я стараюсь организовывать не только дизайн, но и сам процесс вокруг него.

Дизайн — это только часть проекта

Когда смотришь на проект со стороны, может показаться, что работа дизайнера выглядит примерно так: Задача → Figma → согласование → готово. В реальности между этими точками находится довольно много работы.

Нужно понять, какие материалы уже есть, какие решения согласованы, что ещё находится в работе, какие вопросы требуют ответа и что зависит от других участников проекта.

Например, я могу уже закончить дизайн страницы, но не считать её полностью готовой, если:

• клиент ещё не подтвердил контент;
• не определена логика одного из сценариев;
• отсутствует мобильная версия;
• не продумано состояние ошибки;
• разработчику нужны дополнительные пояснения;
• соседний экран ещё влияет на итоговое решение.

Поэтому для меня «макет нарисован» и «этап завершён» — не всегда одно и то же.

Я фиксирую проект в отдельном пространстве

Для небольших и средних проектов мне часто достаточно обычной Google Таблицы. Никакой сложной PM-системы?Project Management — система управления проектами: задачи, статусы, сроки, ответственные. Может быть простой (таблица) или сложной (Jira, Asana, Trello). здесь не требуется.

В ней можно держать основные задачи, этапы, статусы, сроки и комментарии. Главное — чтобы в любой момент было понятно, что происходит с проектом прямо сейчас. Например:

Это не заменяет Figma. И не заменяет коммуникацию с клиентом. Таблица решает другую задачу: она держит контекст проекта в одном месте.

Статус важнее самой задачи

Одна из самых полезных вещей в таком подходе — возможность быстро увидеть не только список задач, но и их состояние. Например:

• Готово — можно двигаться дальше.
• На согласовании — решение есть, но ждём подтверждения.
• Ожидаем клиента — без внешнего ответа задача не двигается.
• В работе — сейчас над ней работает дизайнер.
• Нужно уточнить — пока недостаточно информации для нормального решения.
• Передано в разработку — дизайн готов, но работа ещё продолжается на стороне реализации.

Такая простая классификация помогает избежать ситуации, когда через несколько дней приходится вспоминать: «а мы это уже согласовали или только обсуждали?»

Особенно полезно это становится, когда в проекте одновременно несколько экранов, ролей и пользовательских сценариев.

Я отдельно фиксирую то, что зависит от клиента

Это кажется мелочью, но именно такие вещи часто становятся причиной задержек. Например, дизайнер может ждать:

• тексты;
• фотографии;
• юридическую информацию;
• цены;
• структуру каталога;
• подтверждение сценария;
• доступ к существующему сервису;
• комментарии по макету.

Если просто написать об этом в Telegram, сообщение через несколько дней оказывается где-то между мемом, голосовым сообщением и ещё двадцатью рабочими вопросами.

Поэтому я предпочитаю фиксировать такие зависимости отдельно. Тогда понятно: что нужно → от кого нужно → зачем нужно → что произойдёт после получения. Это уже не просто список задач. Это управление зависимостями внутри проекта.

Правки тоже должны иметь историю

Есть ещё одна ситуация, знакомая практически каждому дизайнеру. Макет согласовали. Через неделю появляется сообщение: «а давайте всё-таки вернём тот вариант, который был до этого».

И тут возникает вопрос: какой именно вариант? Если решения нигде не зафиксированы, приходится открывать старые версии, искать сообщения и восстанавливать контекст.

Поэтому полезно сохранять хотя бы ключевые решения: что изменили → почему изменили → кто согласовал → когда. Не нужно превращать проект в юридический архив. Достаточно, чтобы через неделю можно было восстановить логику решения.

Реализация начинается ещё в Figma

Организация проекта не заканчивается таблицей. Часть будущих проблем можно убрать ещё на этапе дизайна. Например, если я передаю разработчику только красивый desktop-экран, у него неизбежно появятся вопросы:

• что происходит на мобильном?
• что будет, если данных нет?
• что происходит при ошибке?
• как выглядит loading?
• что происходит после отправки формы?
• какие элементы можно редактировать?
• что происходит с длинным текстом?
• какие состояния есть у компонента?

Поэтому я стараюсь проектировать не только основное состояние интерфейса, но и его поведение. Это напрямую связано с тем, насколько спокойно проект потом переходит в разработку.

Подробнее про состояния, Auto Layout и структуру Figma я писал в статье Почему интерфейс в коде выглядит не так, как в Figma.

Handoff — это не «держи ссылку на Figma»

Передача макетов тоже является отдельным этапом. Хороший handoff?Процесс передачи макетов из дизайна в разработку. Хороший handoff включает не только экраны, но и правила, состояния, спецификации и ответы на вопросы. для меня — это не сообщение: «вот ссылка на Figma, если что, спрашивайте».

Перед разработкой должно быть понятно:

• где находится актуальная версия;
• какие экраны готовы;
• какие компоненты используются;
• какие состояния предусмотрены;
• какие решения требуют особого внимания;
• какие вопросы ещё открыты.

Чем сложнее продукт, тем важнее эта часть. В простом лендинге можно объяснить многое голосом. В SaaS, CRM, личном кабинете или сложном B2B-продукте такой подход быстро перестаёт работать.

Дизайнер иногда становится связующим звеном

Мне кажется, здесь есть важный момент. Product Designer?Продуктовый дизайнер — специалист, который работает не только с визуалом, но и с логикой продукта: сценариями, состояниями, бизнес-задачами и метриками. работает не только с пикселями. Между бизнес-задачей, пользователем, клиентом и разработкой постоянно возникают связи, которые кто-то должен удерживать.

Поэтому в некоторых проектах дизайнер фактически частично выполняет функции координатора: задача → исследование → UX → UI → согласование → правки → handoff → реализация.

При этом я не считаю, что дизайнер должен превращаться в полноценного project manager или аккаунт-менеджера?Специалист, который ведёт коммуникацию с клиентом: собирает обратную связь, следит за сроками, координирует работу команды. В продуктовом дизайне часть этих функций иногда берёт на себя дизайнер.. Моя задача всё-таки остаётся дизайнерской.

Но если я понимаю, что определённое решение влияет на следующий этап, я предпочитаю зафиксировать это сразу, а не надеяться, что кто-нибудь вспомнит об этом через неделю.

Почему я не пытаюсь автоматизировать всё

Можно построить огромную систему из таск-трекеров, статусов, уведомлений, интеграций и десятков полей. Но сама по себе система не делает проект организованным. Если человеку приходится тратить больше времени на обновление статусов, чем на сам проект, что-то пошло не так.

Поэтому я выбираю инструменты от сложности задачи. Для одного проекта может хватить Google Таблицы и Figma. Для команды из нескольких специалистов уже логичнее использовать полноценный таск-трекер?Инструмент для управления задачами: Jira, Asana, Trello, Linear, YouTrack. Позволяет видеть статусы, ответственных и связи между задачами.. А если проект небольшой, иногда достаточно хорошо организованной Figma и нормальной переписки.

Инструмент вторичен. Важнее принцип: информация не должна жить только в голове одного человека.

Что это даёт клиенту

Для клиента такой подход означает довольно простую вещь: ему не нужно каждый раз спрашивать, что происходит с проектом. Понятно:

• что уже сделано;
• что сейчас в работе;
• что нужно согласовать;
• что требуется от него;
• что будет следующим этапом.

Это снижает количество лишних сообщений и помогает быстрее принимать решения. А для дизайнера это ещё и способ сохранить собственный фокус. Потому что когда у проекта есть понятная структура, гораздо проще заниматься дизайном, а не постоянно восстанавливать в голове его состояние.

Проект заканчивается не тогда, когда закончилась Figma

Хороший дизайн должен пережить момент, когда дизайнер перестаёт смотреть на него каждый день. Он должен быть понятен клиенту. Понятен разработчику. Понятен команде. И главное — его решения должны сохраняться, когда проект переходит из одного этапа в другой.

Поэтому я воспринимаю организацию проекта как часть своей работы Product Designer. Не потому что дизайнер обязан становиться аккаунт-менеджером. А потому что хороший интерфейс бессмысленно спроектировать идеально, если сам процесс его создания постоянно теряет решения и контекст.

Figma отвечает за то, что мы проектируем. Процесс отвечает за то, как это решение доедет до реального продукта.

И иногда простая Google Таблица оказывается для этого полезнее ещё одного сложного сервиса.