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

Продуктовый и UX/UI-дизайн · 6–8 месяцев · Доработки выпущены

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

Контекст и задача

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

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

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

Моя роль

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

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

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

Список моделей и быстрый предпросмотр

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

Я адаптировал таблицу к обновлённым компонентам дизайн-системы и добавил предпросмотр графа. Он позволяет изучить структуру модели прямо из списка. Для работы с большим количеством моделей это отдельный сценарий быстрого просмотра перед переходом к редактированию.

Из предпросмотра можно скачать визуализацию в PNG. Я проработал связанные действия и состояния этого сценария.

Граф и таблица на одном экране

В редакторе предусмотрены два синхронизированных представления модели: граф и таблица. Администратор может оставить один вид или открыть оба одновременно.

Граф показывает структуру и связи между статусами. Таблица даёт возможность работать с данными в списке. Изменения в одном представлении отражаются в другом.

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

Работа с графом

Графический редактор был построен на готовом решении с открытым исходным кодом, которое дорабатывала команда разработки.

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

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

Статусы и их типы

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

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

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

История версий

После сохранения изменений создаётся новая версия модели. Я спроектировал историю, в которой можно посмотреть автора и подробный состав изменений.

Записи отражают добавление, редактирование и удаление сущностей: какие статусы и другие элементы были затронуты. Для версий доступен предпросмотр.

История связывает сохранённое состояние модели с действиями, которые к нему привели. Она также служит точкой входа в сравнение и восстановление версий.

Сравнение двух версий

Администратор может выбрать любые две версии из истории и открыть их рядом.

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

Я проработал выбор версий и интерфейс их совместного просмотра

Восстановление с сопоставлением статусов

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

Я проработал сценарий сопоставления статусов — маппинг. В процессе восстановления администратор задаёт соответствия между статусами, чтобы учесть различия моделей.

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

Работа с командой и реализация

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

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

Результат

Все перечисленные доработки вошли в релиз.

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

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

Презентация и защита решения

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

Защита прошла успешно. Моё участие в проекте включало не только проектирование и работу с разработкой, но и представление результата более широкой команде.
Made on
Tilda