Редактор статусных моделей — настройка жизненного цикла задач
Развивал инструмент, в котором администраторы пространств управляют статусами задач и правилами переходов между ними. Проработал представления модели, историю и сравнение версий, восстановление с сопоставлением статусов и управление справочниками.
Продуктовый и UX/UI-дизайн · 6–8 месяцев · Доработки выпущены
Название продукта и компании не раскрываю в целях конфиденциальности.
Контекст и задача
Статусная модель определяет жизненный цикл задачи: в каком статусе она создаётся, куда может перейти дальше и по каким правилам. Например, задача может последовательно проходить создание, обработку и завершение либо возвращаться на предыдущие этапы.
В продукте изначально использовалась базовая модель со стандартными статусами, настроенная разработчиками. По мере развития системы потребовался инструмент, с помощью которого администраторы пространств могли бы самостоятельно управлять моделями.
Сотрудники работают с задачами по заданным правилам, а администратор настраивает эти правила. Поэтому редактор должен помогать понимать структуру модели, вносить изменения и учитывать их влияние на существующие задачи.
Моя роль
Я подключился к проекту после начала работы тимлида и другого дизайнера. Дальше выполнял основную часть проектирования новых возможностей и доработок редактора.
Вместе с бизнес-аналитиком уточнял требования и прорабатывал пользовательские сценарии. Решения обсуждались на регулярных ревью с владельцем продукта, бизнес-аналитиком, системным аналитиком и тимлидом.
Моя работа охватывала общий список моделей, графическое и табличное представления, предпросмотр, историю и сравнение версий, восстановление и управление статусами. Я участвовал до релиза.
Список моделей и быстрый предпросмотр
На общем экране администратор видит модели и их основные атрибуты: код, название, описание, типы сущностей, пространства, версию и дату последнего обновления.
Я адаптировал таблицу к обновлённым компонентам дизайн-системы и добавил предпросмотр графа. Он позволяет изучить структуру модели прямо из списка. Для работы с большим количеством моделей это отдельный сценарий быстрого просмотра перед переходом к редактированию.
Из предпросмотра можно скачать визуализацию в PNG. Я проработал связанные действия и состояния этого сценария.
Граф и таблица на одном экране
В редакторе предусмотрены два синхронизированных представления модели: граф и таблица. Администратор может оставить один вид или открыть оба одновременно.
Граф показывает структуру и связи между статусами. Таблица даёт возможность работать с данными в списке. Изменения в одном представлении отражаются в другом.
Потребность в совместной работе с двумя видами была сформулирована в бизнес-требованиях. Я проработал их размещение, переключение и взаимодействие на одном экране.
Работа с графом
Графический редактор был построен на готовом решении с открытым исходным кодом, которое дорабатывала команда разработки.
Я развивал взаимодействие с рабочей областью: перемещение, масштабирование, блокировку положения элементов и автоматическое выравнивание.
Блокировка позволяет перемещаться по графу, не сдвигая статусы случайным действием. Автоматическое выравнивание помогает упорядочить расположение элементов после ручных изменений.
Статусы и их типы
Для подготовки моделей я спроектировал отдельные панели управления статусами и типами статусов, доработал создание и настройку статусов.
Тип статуса — верхний уровень классификации. Он задаёт код и цветовую индикацию и может объединять несколько статусов. Например, разные названия начального состояния могут относиться к одному типу.
В интерфейсе важно было различать сам статус и его принадлежность к типу. Цвет задавался на уровне типа, поэтому связанные с ним статусы использовали общую индикацию.
История версий
После сохранения изменений создаётся новая версия модели. Я спроектировал историю, в которой можно посмотреть автора и подробный состав изменений.
Записи отражают добавление, редактирование и удаление сущностей: какие статусы и другие элементы были затронуты. Для версий доступен предпросмотр.
История связывает сохранённое состояние модели с действиями, которые к нему привели. Она также служит точкой входа в сравнение и восстановление версий.
Сравнение двух версий
Администратор может выбрать любые две версии из истории и открыть их рядом.
В представлении сравнения отображаются два графа, а также сведения о пространствах и типах сущностей. Это позволяет изучить два состояния модели одновременно, без последовательного открытия каждого из них.
Я проработал выбор версий и интерфейс их совместного просмотра
Восстановление с сопоставлением статусов
Восстановление версии требовало учитывать задачи, которые уже находятся в текущей модели. Состав статусов в выбранной версии мог отличаться от действующего, поэтому одного выбора прежней версии было недостаточно.
Я проработал сценарий сопоставления статусов — маппинг. В процессе восстановления администратор задаёт соответствия между статусами, чтобы учесть различия моделей.
Правила переноса задач проверял бизнес-аналитик. Моя задача состояла в том, чтобы представить эту логику в интерфейсе: объяснить необходимость сопоставления и дать администратору возможность выполнить его.
Работа с командой и реализация
Проект развивался итерациями. Вместе с аналитиками и владельцем продукта команда определяла объём очередной итерации. Согласованный вариант фиксировали для разработки, пока дизайнеры продолжали прорабатывать следующие возможности.
На ревью проверяли интерфейс и соответствие системной логике. Я также внедрял новые компоненты дизайн-системы в существующие экраны, чтобы развитие функциональности сопровождалось обновлением интерфейса.
Результат
Все перечисленные доработки вошли в релиз.
Администраторы получили синхронизированные представления модели, быстрый предпросмотр и экспорт графа, подробную историю изменений, сравнение версий и сценарий восстановления с сопоставлением статусов.
Мой основной вклад — проектирование этих возможностей в рамках существующего редактора и совместная с аналитиками проработка сложных сценариев. Данных об изменении скорости работы или количества ошибок у меня нет, поэтому результат кейса — выпущенная функциональность, соответствующая согласованным требованиям.
Презентация и защита решения
После реализации мы с тимлидом представили функциональность всему стриму. Презентацию вели совместно, разделив выступление примерно поровну: демонстрировали возможности редактора и объясняли принятые решения.
Защита прошла успешно. Моё участие в проекте включало не только проектирование и работу с разработкой, но и представление результата более широкой команде.