Мой вклад
Предложил дополнять пользовательские истории Use Cases для ключевых процессов, проектировал интерфейсы и интерактивные прототипы. Вместе с аналитиками и разработчиками уточнял состояния, ограничения и передачу решений в разработку.
Корпоративная платформа для управления энергопотреблением крупного оператора связи. Я помогал переводить сложную бизнес-логику в сценарии и интерфейсы, где большие таблицы, карточки сущностей и их состояния во времени работают как единая система.
Контекст и роль
Платформа объединяла расчёты потребления и стоимости, договоры, объекты, приборы учёта и энергоменеджмент. Для каждого раздела нужно было учитывать связанные данные, права доступа и исключения.
Мой вклад
Предложил дополнять пользовательские истории Use Cases для ключевых процессов, проектировал интерфейсы и интерактивные прототипы. Вместе с аналитиками и разработчиками уточнял состояния, ограничения и передачу решений в разработку.
Командная работа
Бизнес-правила и приоритеты формировались совместно с продакт-менеджером, аналитиками и заказчиком. Реализацию проверяли вместе с разработчиками и QA.
Было
участник
потребность
ценность
Остаются вопросы
При передаче задачи нужны уточнения
Стало
роль и цель
потребность и действия
ценность и ответ системы
Дополнительно зафиксировано
Меньше вопросов на этапах от аналитики до QA
Как инициатор я подготовил первые 16 Use Cases в качестве примера и получил обратную связь от участников процесса. При передаче задач в разработку вопросов к пользовательским историям и прототипам стало меньше.
Историчность · Инициативы
Для расчётов и проверки пользователю нужно было видеть состояние объекта на выбранную дату, отличать исторические значения от текущих и понимать влияние инициатив. Интерфейс должен был сохранять контекст периода и защищать закрытые данные от случайного редактирования.
Я участвовал в проектировании механизма историчности и предложил решение, которое взяли за основу интерактивного прототипа. Оно связывало просмотр состояния на дату с временным действием инициатив, не допуская редактирования закрытых периодов.
Карточки · Таблицы
Карточки содержали десятки полей и несколько смысловых разделов, а таблицы — связанные показатели и действия. Пользователю важно было быстро перейти к нужной части и увидеть детали, не теряя исходный список.
Я предложил разбить длинную карточку на смысловые разделы и оставить их названия рядом с содержимым. Пользователь быстрее переходит к нужным данным и сохраняет ориентацию в объёмном интерфейсе.

Изначально каждый прибор учёта был отдельной раскрывающейся таблицей: на экране помещалось мало ПУ, а повторяющаяся информация занимала значительную часть площади. Я предложил единую таблицу с раскрывающимися строками. После обсуждения с разработчиками и продакт-менеджером решение приняли за основу.
Вывод
Я проектировал решения не только для одного раздела. Формат Use Cases стал способом фиксировать и передавать важную информацию между этапами разработки, а интерфейсные паттерны можно было применять в других частях платформы.
Для команды
Use Cases дополнили пользовательские истории и снизили количество вопросов к сценариям и прототипам при передаче задач в разработку.
Для продукта
Локальную навигацию и раскрывающиеся строки реализовали в коде и затем использовали в других разделах. Историчность и инициативы проработали на уровне интерактивного прототипа и запланировали для следующих релизов.