Меня зовут Лена Плинер. Я занимаюсь UX/UI-дизайном CRM, ERP, SaaS‑платформ и сервисов, веб‑ и мобильных приложений. Сотрудничаю с заказчиками и командами как попроектный дизайнер.

Контекст
Я работаю по схеме Time & Materials (T&M) над проектами с высокой степенью неопределённости, где на старте часто только общее представление о продукте, его структуре или задачах.

С учётом моего опыта я вывела для себя минимальное количество часов в первом блоке работы, позволяющее получить основу для будущего проекта — 40.

В этой статье

➡ Покажу, как проходит первый ключевой этап работы — от сбора вводных материалов до набора проектных артефактов, которые формируются в первый блок часов.

➡Расскажу, каких данных достаточно для старта работы и как эти разрозненные данные превращаются в структурированную основу интерфейса.

➡Объясню, какие именно артефакты создаются на этом этапе, как они оформлены и какую пользу дают на следующих этапах.

Статья будет полезна тем, кто запускает новый продукт, развивает существующую систему или внедряет новый функционал в условиях, когда ТЗ нет, а требования формируются по ходу.

Почему эта тема важна

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

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

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

Кто мой клиент

В процессе работы я взаимодействую с клиентом и его командой, состав которой зависит от стадии и задач проекта. Это могут быть: основатель/CEO продукта, владельцы бизнеса, тимлид, менеджер продукта, аналитики, маркетологи, исследователи, разработчики, тестировщики, дизайнеры, пользователи.

Почему важен первый блок

Фокус первого блока — создание фундамента для последующих этапов: систематизация вводной информации, согласование сценариев, ролей, состояний и переходов.

Первый блок представляет собой стартовую проработку. Без него невозможно создать интерфейс, который работает как система: поддерживает сценарии, адаптируется к росту данных и изменению бизнес-требований, не ломается в реальных сценариях использования.

Всё, что делается в первом блоке, можно условно стандартизировать по типам материалов и разбить на этапы:

1. Сбор и систематизация информации.
2. Анализ логики продукта.
3. Проектирование (опционально).

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

1. Сбор и систематизация информации

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

Продолжительность этапа
От 5-ти часов

Что влияет на продолжительность

• Количество источников и их разнообразие: таблицы, скринкасты, видео, голосовые и текстовые сообщения.

• Степень формализованности информации. Иногда материалы приходят в виде голосовых сообщений, переписок, что требует дополнительного структурирования перед началом анализа.

• Наличие/отсутствие действующего системы.

Артефакты этапа
FigJam-доска с навигацией: структурированные вводные материалы, глоссарий (термины/cущности), ссылки на источники, план проекта.

Процесс
В зависимости от проекта и ситуации клиент может передать как собранный пакет материалов, так и отдельные разрозненные вводные. Это могут быть:

• презентации и текстовые описания;

• внутренние документы в Excel, Google Docs, Notion и т. д.;

• голосовые сообщения и переписки;

• ссылки на текущие интерфейсы или MVP;

• схемы в FigJam, Miro;

• скриншоты, фото с доски, наброски от руки;

• видео с демонстрацией работы системы или объяснением процессов;

• формальное описание задачи.

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

После установочного созвона я собираю вводные материалы в единую структуру на проектной доске (FigJam) и на этой же доске добавляю навигацию к артефактам (например, ссылки на Figma) и размещаю те артефакты, которые уместно держать прямо на доске.

Систематизирую по темам, составляю список нераскрытых или двусмысленных описаний, которые требуют конкретизации и дополнительной информации.

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

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

Фиксирую всё, что может повлиять на архитектуру интерфейса. Дополняю проектную доску новыми вводными материалами и ссылками на новые артефакты по мере работы.

2. Анализ логики

Цель этапа
Превратить вводные данные в описание функционала и согласованные пользовательские сценарии.

Продолжительность этапа
От 20-ти часов, если клиент присылает детальное описание, структурированные документы.

Что влияет на продолжительность

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

• Количество ролей и ключевых сущностей: чем их больше, тем больше связей, прав и зависимостей требуется разобрать.

• Сложность бизнес-логики: пересечения процессов, внешние шаги (договоры, сторонние сервисы), ветвления по ролям.

• Уровень вовлечённости клиента: отвечает ли на вопросы, быстро ли уточняет детали, готов ли обсуждать неизвестные параметры.

Артефакты этапа

• документ с описанием функционала;

• описание сценариев (user stories);

• схема бизнес-процессов (опционально);

• сущности и список терминов и определений.

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

Не все перечисленные действия и артефакты обязательны. Они определяются на старте работы и согласовываются с заказчиком.

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

Бизнес-процессы

• как   выстроен процесс работы компании;

• как устроена последовательность операций;

• как перемещаются и обрабатываются данные;

• где проходят границы между онлайн- и офлайн-этапами.

Пример. В оптовой компании продажи начинаются с оформления заявки клиентом. Менеджер фиксирует её в системе, проверяет наличие товаров на складе и согласует условия отгрузки. После этого заявка передаётся в отдел логистики: они формируют маршрут, бронируют транспорт и контролируют отправку. Параллельно бухгалтерия выставляет счёт и проверяет оплату. Часть шагов происходит онлайн (заявка, проверка остатков, выставление счёта), часть офлайн (фактическая погрузка, доставка, подписание бумажных актов).

Роли пользователей
Параллельно бизнес-процессам я подробно изучаю:

• кто из сотрудников будет работать в системе;

• какие у них есть текущие обязанности;

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

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

Результат: формируется матрица «роль × действие × сущность», сценарии по ролям и правила доступа.

Сущности
В рамках анализа продукта я отдельно изучаю сущности системы. Это ключевые объекты, с которыми будут работать пользователи. Для каждой сущности я фиксирую её связи с другими объектами и добавляю атрибуты:

• из каких свойств она состоит;

• как изменяется на разных этапах процесса;

• с какими другими сущностями связана. Например, в заявке могут участвовать сразу три сущности: клиент, объект и подрядчик.

Сценарии
Какие шаги и в каком порядке выполняет роль для решения задачи. Например, менеджер получает заявку от нового клиента, регистрирует его данные, связывается с ним для подтверждения заявки, оформляет заказ на нужные товары, отправляет его на согласование и так далее. Такой сценарий помогает понять, какие действия должен поддерживать интерфейс и в какой последовательности.

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

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

Например, это может быть предложение упростить или изменить часть функционала или обсудить интересное решение у конкурентов.

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

Это помогает двигаться без блокировок и снижает неопределённость до начала проектирования экранов.

3. Проектирование (опционально)

Этап может быть перенесён в следующий блок, если не укладывается в первые 40 часов по объёму/сложности.

Цель этапа
Перевести результаты анализа в поэтапное описание взаимодействия пользователя с системой. Определяю, какие экраны и состояния нужны для реализации сценариев и как они связаны между собой. Это «скелет» для дальнейшего проектирования.

Продолжительность этапа
От 15 часов

Что влияет на продолжительность
Количество сценариев и ролей

Артефакты этапа

• карта информационной архитектуры (карта экранов);

• user flow;

• мокапы или wireframes (опционально)

Процесс

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

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

Зачем нужна карта экранов

• позволяет наглядно зафиксировать архитектуру интерфейса;

• помогает согласовать состав разделов, вложенность и количество экранов;

• упрощает коммуникацию: команда видит объём и структуру до проектирования UI;

• выявляет дубли, пропуски или логические разрывы в системе;

• служит основой для проектирования сценариев и user flow.

Что включаю в карту

• ключевые модули и разделы системы;

• вложенные экраны и типовые состояния;

• возможные промежуточные статусы или условия;

• системные и служебные экраны;

На основе чего строю карту

• функциональные требования и сценарии;

• список сущностей и действий с ними;

• результаты анализа бизнес-процессов;

• гипотезы и допущения, зафиксированные при уточнении требований.

Как формирую карту

• фиксирую модули. Это верхний уровень карты, который ляжет в основу будущей навигации;

• добавляю экраны внутри модулей. Например, список, создание, редактирование, история и т.д.;

• учитываю вложенность: какие экраны вызываются из других. Например, карточка объекта из списка;

• фиксирую состояния. Если экран может быть пустым, недоступным, в статусе ошибки, отражаю это как вариант (не раскладываю, а помечаю);

• помечаю неизвестные или обсуждаемые участки: добавляю комментарии, чтобы команда могла вернуться к ним позже;

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

Особенности карты

• включаю как подтверждённые, так и гипотетические участки. Всё, что требует уточнения, выделяю отдельно и обсуждаю с командой;

• отражаю точки ветвления по условиям, если они влияют на структуру, например, блоки, доступные только в определённых статусах;

• если структура интерфейса сильно различается для разных ролей, например, у каждой роли свои модули и экраны, отражаю это в карте как отдельные блоки;

• если роли работают с одними и теми же модулями, но имеют разный набор действий, например, один только просматривает, другой — редактирует, фиксирую общий экран без детализации прав. Права и доступы описываются отдельно, на уровне сценариев и логики взаимодействия.

User flow
Описанная выше карта экранов показывает структуру интерфейса: модули, вложенные экраны, базовые состояния. Её достаточно, если система устроена просто: список → карточка → создание/редактирование. Например, «Заявки», «Документы», «Клиенты».

User flow нужен, если в сценарии есть шаги, развилки, статусы или участвуют несколько ролей, если он сильно влияет на процессы (критичен для запуска/операций) или содержит много неизвестных данных (неясно, какие экраны и состояния нужны). Это может быть процесс возврата товара, покупка сертификата в подарок, регистрация через SSO с выбором аккаунта.

Часто я использую оба артефакта: карта даёт общую структуру, flow — логику ключевых процессов.

Процесс

1. Беру сценарии из пользовательских историй (user stories) и определяю границы сценария: старт (что запускает действие) и «точку успеха» (когда результат считается достигнутым).

2. Раскладываю шаги пользователя и системы по порядку: что делает роль, что автоматически делает система, где требуются данные/права/подтверждения.

3. Фиксирую развилки и условия: для каждого «да/нет» описываю, как меняется путь, статус сущности и доступные действия (что разрешено/заблокировано).

4. Фиксирую неизвестные и допущения: помечаю, где не хватает данных/правил; выношу вопрос в список уточнений.

5. Проверяю завершённость: поток приводит к явному результату (создан, отправлен, утверждён и т.п.) и соотнесён с бизнес-процессом.

Как оформляю простые сценарии (без карты)
Для понятных действий делаю краткую заметку в одну строку, например: «Отчёты → выбрать период → Сформировать → Отправить → выбрать получателей».

Дополнительно на этапе проектирования фиксирую

• для сложных участков логики или спорных сценариев точечно использую wireframe. Это быстрый способ показать 1–2 альтернативы решения микрозадачи внутри проекта, обсудить их с командой и зафиксировать договорённость;

• короткий чек-лист состояний для каждого экрана: пусто, заполнено, загрузка, ошибка, мало данных, много данных. Сразу отмечаю, для каких состояний понадобится дизайн, чтобы к моменту проработки знать, какие макеты нужно отрисовать.

Такой подход позволяет

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

• построить логику навигации между экранами и разделами;

• выделить модули интерфейса, порядок доступа и связи между ними;

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

• определить, какие экраны нужны и в каких состояниях;

Отчетность

Отдельно хочу раскрыть вопрос отчётности о работе.
Я работаю по схеме Time & Materials (T&M), поэтому мне важно показать клиенту, что за каждым часом стоит конкретная работа. Клиент и его команда могут видеть ход работы в Figma.

Параллельно я веду детальный отчёт, в который включаю всё, что касается работы над проектом: аналитику, работу с документацией, логику, участие в созвонах с командой. Отправляю отчет 1 раз в неделю. Такой отчёт позволяет клиенту видеть структуру работы и расход оплаченных часов.

Правила учёта времени: короткие уточнения и организационные ответы между встречами до 5-ти минут не трекаю.

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

Кратко о взаимодействии с заказчиком

• коммуникация ведется в рабочем чате проекта;

• созваниваемся с заказчиком/командой по мере необходимости для демонстрации артефактов и обсуждения текущих вопросов;

• количество звонков не регламентируется;

• обратная связь по wireframes ведется в комментариях в Figma, чтобы решения оставались привязанными к месту и истории изменений;

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

Как снимаются риски T&M

• Предварительная оценка объёма и бюджета. На этапе первичного общения делаю предварительную оценку по минимальному бюджету и составу ближайших работ.

• Рамки и приоритеты первого блока. Фиксируем приоритеты задач, перечень того, что входит в текущий блок, а что нет. При необходимости пересматриваем приоритеты и порядок работю

• Детализированная отчётность 1 раз в неделю в виде тайм-лога с разбиением по задачам.

• Постоянная видимость прогресса. Доступ к Figma, промежуточные показы по мере готовности артефактов;

• Прозрачная фиксация решений. Решения зафиксированы на проектной доске (как навигация и заметки) и в самих артефактах (Figma/Notion/FigJam).

Что получает клиент в первом блоке

На этапе «Сбор и систематизация информации»

FigJam-доска с навигацией: структурированные вводные материалы, глоссарий (термины/сущности), ссылки на источники.

На этапе «Анализ логики продукта»

• Схема бизнес-процессов (если влияет на сценарии/разделы) (опционально).

• Описание функционала : список возможностей и зависимостей.

• Таблица user stories: «роль → действие →   результат/ограничения».

• Матрица «роль × действие × сущность» и базовые правила доступа.

• Сущности и список терминов и определений.

На этапе «Проектирование» (опционально)

• Карта экранов: разделы, экраны, состояния, связи.

• User flows ключевых сценариев по ролям с условиями переходов и пограничными случаями.

Бизнес-эффект (польза для клиента)

Бизнес-эффект первых 40 часов

Результат работы в первом блоке — опорная база для движения дальше: меньше возвратов и уточнений, короче согласования, точнее оценки следующих этапов.
В итоге команда двигается быстрее при тех же ресурсах, а затраты на переделки и «трение» снижаются.

Предсказуемое планирование

База артефактов позволяет оценивать не только дизайн, но и разработку: объём работ раскладывается в понятный бэклог с приоритетами и зависимостями. Точнее оценки и график, понятная потребность в ресурсах (люди/часы/календарь), меньше разброс между оценкой и фактом и возможность ранее согласовать бюджет и окна релизов.

Гибкость процесса

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

Заключение

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

Будет интересно узнать какие артефакты и нюансы на первом этапе вы считаете важными, чтобы результаты работы поддерживали цели проекта и работу команды.

Спасибо за внимание!