Не хватало экранов
Ключевые сценарии обрывались, не всегда соответствовали поставленной задаче, не были показаны ошибки и крайние состояния.
← Все кейсы
B2G · Лид-роль · Сдача проекта
Как вернул проект в работу и подготовил 67 экранов к сдаче
Я пришёл в проект после нескольких дизайнеров. Заказчик устал повторять требования, решения расходились, а до договорной сдачи оставалось полтора месяца. Нужно было вернуть рабочий контакт, собрать целостный сценарий и защитить его перед заказчиком.
- Моя роль
- Лид-дизайнер; ключевой объём выполнил лично
- Срок
- Полтора месяца до договорного этапа
- Объём
- 67 уникальных экранов без адаптивов
- Результат
- Макеты защитили и передали в срок
Реестр объектов
Карточка разрешения
67 экранов к защите и передачеПроект под NDA. Названия, бренд и данные на экранах изменены.
Целостного решения не было, а срок уже был зафиксирован
Платформа покрывала реестры, документы, согласования и статусы для нескольких ролей. Часть экранов отсутствовала, а одинаковые действия после смены дизайнеров работали по-разному. За полтора месяца нужно было собрать и защитить макеты, которые выполняли условия договора.
Решения расходились
Одинаковые действия выглядели по-разному, поэтому разработке нечего было брать за правило.
Два заказчика
Основной заказчик участвовал регулярно, второй подключался к отдельным решениям.
Полтора месяца
К этой дате нужно было завершить и защитить дизайн-макеты, затем передать их в разработку.
Сначала вернул доверие, затем вернулся к макетам
На первой встрече я в основном слушал и записывал. Когда задал уточняющий вопрос, заказчик резко ответил, что объясняет одно и то же уже шестому человеку. Это показало настоящую проблему: новый макет без понимания накопленных претензий только усилил бы конфликт.
«Я уже шестому человеку объясняю одно и то же»
После разговора я разложил замечания по трём слоям: логика, визуальный язык и потеря контекста при передаче проекта.
Выбрал несколько спорных задач
Сделал варианты экранов и для каждого показал, какую претензию он закрывает. Так разговор перешёл от общих ожиданий к конкретным решениям.
Заслужил доверие конкретными решениями
Я показал, что услышал претензии и могу обосновать каждое изменение. Заказчик согласился заново пройти со мной по задачам и доверил пересборку продукта как единой системы.
Сократил объём со 100+ экранов до 67 уникальных
Я декомпозировал весь перечень, нашёл повторяющиеся сценарии и отделил уникальные экраны от состояний и вариаций. В результате обязательный объём стал понятным: 67 уникальных экранов вместо списка из более чем ста позиций.
Реестры, карточки, формы, статусы и проверки
Если проектировать каждый экран независимо, команда снова и снова обсуждает сортировку, фильтры, расположение действий, обязательность полей, ошибки и пустые состояния. При ограниченном сроке это был главный источник лишних решений.
Поэтому я сначала определял тип сценария и его базовый паттерн, а затем добавлял предметные ограничения конкретного раздела.
База
Сетка, типографика, отступы, цвета и состояния компонентов.
Рабочие паттерны
Таблицы, фильтры, формы, модальные окна, статусы и действия.
Предметная логика
Документы, согласования, иерархии, права и юридически значимые проверки.
Состояния
Пусто, заполнено, ошибка, ограничение доступа и результат действия.
Сначала собрал обязательные сценарии для договорной сдачи
Приоритетом были жизненно важные сценарии, без которых система не выполняла задачи заказчика. Затем я фиксировал общие правила и добавлял состояния, необходимые для защиты целостного решения.
Три вопроса перед началом экрана
Каждый экран проверял по роли в обязательном сценарии. Сначала закрывал критический путь, затем общие правила и только после этого частные случаи.
- 01Без этого ломается основной сценарий?
Если да, экран или состояние попадали в первую очередь.
- 02Это решение повторяется в других разделах?
Если да, сначала фиксировал общий паттерн, а не отдельный макет.
- 03Это общее правило или частное ограничение?
Исключения добавлял поверх базы, не меняя поведение всей системы.
Критический путь→Общие паттерны→Частные случаи
- Шаг 1
Зафиксировал критический объём
Собрал недостающие части сценария и определил, что обязательно должно быть готово к защите в договорный срок.
- команда увидела достижимую границу этапа
- основной путь перестал обрываться
- зависимости стали видны до отрисовки деталей
- Шаг 2
Опёрся на знакомую разработке базу
Ant Design уже использовался командой. Это позволило обсуждать не поведение стандартных контролов, а сложную логику самого продукта.
- сохранил знакомое поведение компонентов
- адаптировал визуальный слой под проект
- отдельно описал предметные паттерны
- Шаг 3
Зафиксировал повторяющиеся правила
Реестры, карточки, формы и ошибки собрал в общие паттерны. Изменение одного правила можно было перенести на весь сценарий.
- единое место главного действия
- общие статусы и сообщения об ошибках
- предсказуемые пустые и заполненные состояния
- Шаг 4
Согласовывал частями, а не в самом конце
Завершённые фрагменты сначала обсуждали внутри команды, затем показывали основному заказчику. Второй заказчик подключался только к отдельным решениям.
- логика не смешивалась с визуальными правками
- повторяющаяся проблема исправлялась во всех местах
- к финалу не копился новый круг системных изменений
Полтора месяца занял весь договорный этап. 67 уникальных экранов я подготовил примерно за один месяц. Адаптивы в это число не входят.
Шесть частей рабочего сценария
В число не входят адаптивы. Показываю шесть типов интерфейсов из итогового объёма.
Плотная таблица, фильтры и статусы должны были работать как единая модель, а не как набор отдельных экранов.
Структура объекта и доступные действия зависят от уровня, на котором находится пользователь.
Собрал сведения, статус и доступные действия в одном месте, чтобы не разносить сценарий по модальным окнам.
Для длинных форм были важны порядок полей, читаемая группировка и понятное завершение действия.
Ошибку показывал рядом с причиной и следующим действием. Общую плашку оставлял дополнением.
Пустой экран объясняет, почему данных ещё нет и что можно сделать, чтобы они появились.
Помогал двум junior-дизайнерам перейти от мелких задач к продуктовым
Оба дизайнера были на проекте с самого начала. Сначала они наблюдали за моей работой и выполняли небольшие графические задачи. Параллельно я учил их разбирать постановки, общаться с аналитиками и проверять собственные решения.
Как уточнять задачу, не пересказывать постановку и добираться до цели пользователя.
Что спросить про роли, ограничения, данные, результат и спорные места до начала макета.
О чём подумать, глядя на постановку, и как связать отдельный экран с полным сценарием.
Как проверить иерархию, главное действие, состояния и ошибки до общего просмотра.
Как не забыть пустые данные, ограничения доступа, длинные значения и редкие роли.
Как спокойно объяснить ход мысли и отделить вкусовую правку от проблемы сценария.
Дейлики, разборы один на один и пятничные демо
Обучение шло рядом с реальными задачами. Темы менялись в зависимости от текущих проблем: постановка, логика сценария, визуальная иерархия, компоненты или подготовка к показу.
Дизайнеры следили за моей работой, брали графические и другие небольшие задачи, затем вместе разбирали результат.
На ежедневных встречах обсуждали задачи и проблемы. Для обучения выделяли время один на один или вместе, по пятницам показывали результат на демо.
Обычные задачи дизайнеры закрывали самостоятельно, ко мне приходили за разбором сложных исключений.
Договорный этапВыполнен
Разработка началась в согласованный срок.
Что изменилось для проекта
За месяц лично подготовил 67 уникальных экранов: реестры, иерархии, карточки, юридически значимые формы, проверки и состояния. Дизайн приняли два заказчика, после чего команда начала разработку.
Разработка получила не набор разрозненных макетов, а согласованный сценарий, общие паттерны и состояния, которые можно было реализовывать последовательно.
Изменилась и работа с заказчиком. Это не числовая метрика, а наблюдение по ходу проекта: вместо диктовки он начал обсуждать со мной решения и спрашивать совета, а мою работу несколько раз отдельно хвалил.
Итог
Выполнили договорный этап, а я прошёл первый проект в лид-роли
Я вернул рабочий разговор с заказчиком, сократил объём со 100+ позиций до 67 уникальных экранов, задал общие правила и лично собрал ключевую часть решения. Макеты защитили, условия договора выполнили, проект передали в разработку вовремя.
Этот проект дал мне первый полноценный опыт лида: отвечать не только за свои макеты, но и за общий результат команды, отношения с заказчиком и развитие двух дизайнеров. За несколько месяцев они перешли от наблюдения и мелких задач к самостоятельной работе с обычными продуктовыми сценариями.