VS Ecosystem
Внутренняя система выпуска и учёта лицензий на ПО, которое работает без доступа в интернет.
cover.jpg
Коротко
О компании
Vidau Systems — B2B-разработка ПО для медиавещания. Продукты компании устанавливаются в инфраструктуру заказчика — телеканалов и вещателей.
Контекст
Продукты Vidau работают в инфраструктуре заказчика, у которой нет выхода в интернет: всё работает локально, внутри изолированной сети.
Лицензии на эти продукты выдавались вручную. Данные жили в разных местах, единого реестра не было, запросы на изменение приходили файлами и разбирались глазами.
Задача
Собрать лицензирование в один управляемый процесс на стороне Vidau.
Главное ограничение задачи было техническим: прямой интеграции между Vidau и заказчиком не существует, поэтому файловый обмен остаётся в сценарии при любом дизайне. Проектировать нужно было вокруг него.
Основной риск в процессе был связан с ошибкой при сверке: пропущенный изменённый параметр приводит к выдаче неверного ключа.
Что сделала
- Разобрала процесс лицензирования вместе с системным аналитиком и зафиксировала его в BPMN, чтобы понять, где именно человек принимает решение
- Спроектировала реестр лицензий как точку входа, где состояние всех лицензий видно в одной таблице
- Связала статус лицензии с набором допустимых действий в карточке — недопустимое действие в интерфейсе отсутствует
- Спроектировала сценарий обработки запроса на изменение: первая версия была формой, на которой изменения терялись, вторая — сравнением с типизацией строк
- Держала решение устойчивым к меняющемуся скоупу: логика лицензии проектировалась отдельно от логики каталога
Роль и команда
Продуктовый дизайнер в команде из продакта, системного аналитика и лид-дизайнера. Около года, 2025 год.
Результат
Дизайн Лицензионного портала согласован с продуктом и подготовлен к передаче в разработку. До реализации проект не дошёл: в компании не хватило ресурсов разработки.
Метрик по проекту нет, система не запускалась, эффект на процесс не измерялся.
Подробнее о процессе
Ограничение, которое определило весь дизайн
У инфраструктуры заказчика нет выхода в интернет. Продукт работает локально, внутри изолированной сети, поэтому прямая интеграция между Vidau и заказчиком технически невозможна.
Отсюда следует конструкция всего процесса: заказчик формирует файл запроса, отправляет его, Vidau выпускает файл лицензии в ответ.
Это ограничение снимает целый класс решений. Автоматическая синхронизация, онлайн-активация, проверка лицензии по сети в этом контуре недоступны.
Задача сузилась до одного участка: сделать предсказуемым тот шаг, где человек на стороне Vidau принимает решение о выдаче.
bpmn-fragment.jpg
Что было не так с процессом
Процесс существовал и работал, но держался на внимании конкретных людей.
Состояние было размазано. Данные о лицензиях хранились в разных инструментах. Ответ на вопрос «что сейчас с лицензиями этого заказчика» собирался вручную из нескольких источников.
Изменения приходилось искать глазами. Запрос на изменение приходил файлом. Сотрудник открывал его и сверял с тем, что было выдано раньше. Ничто в этом процессе не подсвечивало, что именно поменялось.
Правила жили в голове. Что можно сделать с конкретной лицензией, зависело от её состояния. Эти правила нигде не были выражены, поэтому корректность операции зависела от опыта сотрудника.
Ключевой риск здесь связан не со скоростью работы. Ошибка при сверке приводит к выдаче лицензии по неверным данным, а исправление в закрытом контуре стоит ещё одного цикла файлового обмена.
before-process-schema.jpg
Кто пользователь
Основной пользователь Лицензионного портала: администратор Vidau, сотрудник, который ведёт лицензии и обрабатывает входящие запросы. Рядом с ним инженеры, которые сталкиваются с лицензированием при установке продуктов.
Заказчик участвует в процессе на своей стороне: формирует запрос и получает файл лицензии. Полноценным пользователем портала он не становится.
Весь интерфейс дальше спроектирован под человека, который принимает решение о выдаче.
Как менялся проект
Проект шёл около года, и большую часть этого времени менялась сама концепция продукта.
Изначально Ecosystem задумывалась как единая среда с библиотекой всех продуктов компании, ближе к магазину приложений. Отсюда название. Постепенно скоуп сужался, и в итоге остались две части: лицензирование и установщик.
Для дизайна это означало, что опираться на финальные требования было нельзя, их не существовало. Решение приходилось строить так, чтобы оно не разваливалось при следующем сужении: логика лицензии проектировалась отдельно от логики каталога, интерфейс не завязывался на функции, которые могли исчезнуть.
product-scope-timeline.jpg
Моя роль и scope
Продуктовый дизайнер в команде из продакта, системного аналитика и лид-дизайнера.
За что отвечала я:
- реестр лицензий целиком;
- карточка лицензии, модель статусов и логика допустимых действий;
- сценарий обработки запроса на изменение: структура, шаги, первая версия экрана сверки;
- разбор процесса лицензирования вместе с аналитиком.
Что было командной работой:
- финальная визуальная типизация строк в экране сверки, доработка с лид-дизайнером;
- описание процесса в BPMN, вместе с системным аналитиком;
- границы скоупа и приоритеты, с продактом.
Доступ к пользователю был: я показывала экраны администратору Vidau, который в реальности ведёт лицензии, и он оценивал решения как эксперт — говорил, подходит вариант или нет. Формальных исследовательских тестов при этом не проводилось.
Ключевые решения
Это ядро системы, поэтому начинаю с него.
Решение 1. Обработка запроса на изменение
Сценарий состоит из трёх шагов: загрузка файла запроса, сверка изменений, выдача ключа.
change-request-wizard.jpg
Первая версия и почему она не сработала
Сначала я спроектировала сверку как форму: список полей с инпутами и выпадающими списками, куда подтягивались данные из запроса.
На реальном объёме данных стала видна проблема. Строки выглядели одинаково, изменённый параметр ничем не отличался от неизменённого. Экран показывал данные, при этом главная задача шага — заметить разницу — оставалась на внимании человека. Форма воспроизводила ту же слабость, что была в ручном процессе.
change-request-form-v1.jpg
Что сделали вместо
Экран перестал быть формой и стал сравнением.
Каждая строка получила тип: изменённая, новая, удалённая. Тип задан визуально, поэтому просмотр превращается в сканирование.
Решение по каждой строке принимается явно, через принять или отклонить. Выдача ключа доступна после того, как все изменения обработаны, поэтому пропустить строку молча нельзя.
Trade-off. Явное решение по каждой строке добавляет действий на больших запросах. Мы приняли эту цену осознанно: цикл исправления в закрытом контуре дороже, чем несколько лишних кликов.
Про роль: первую версию сценария и его логику проектировала я. Проблему читаемости увидела и принесла в команду тоже я. Финальную визуальную типизацию строк собирали в паре с лид-дизайнером.
change-request-compare.jpg
Решение 2. Состояния строки
Типизация строк оказалась самой проработанной частью проекта, поэтому выношу её отдельно.
Строка имеет состояния: обычная, наведение, изменённая, новая, отклонённая, удалённая. Состояния различаются визуально и сочетаются между собой без конфликта: отклонённая изменённая строка остаётся читаемой.
Это то, что делает экран сверки рабочим. Администратор читает историю того, что произошло с каждым параметром, поверх самих данных лицензии.
row-states-legend.jpg
Рекомендация к правке макета. Сейчас типы различаются только цветом. Стоит добавить иконку типа изменения, иначе различие теряется при дальтонизме и в чёрно-белой печати портфолио.
Решение 3. Действия зависят от статуса
Лицензия проходит через статусы: доступна, выдана, аннулирована, истёкшая.
Набор действий в карточке определяется статусом. Недопустимое действие в интерфейсе отсутствует, оно не блокируется с объяснением. Так правила перестают жить в голове сотрудника и становятся частью системы.
Карточка разделена на два блока: основные данные лицензии и параметры. Первый отвечает на вопрос «что это за лицензия», второй — на вопрос «что в неё входит».
license-card-statuses.jpg
Заглушка — нужны данные от автора. В какой статус переходит лицензия после действия «Освободить». Как только это известно, сюда встанет схема переходов на 4 состояния, и модель статусов закроется полностью.
Решение 4. Реестр лицензий
Реестр — это точка входа в систему. Таблица со статусами и фильтрами, из которой видно состояние всех лицензий и можно провалиться в конкретную.
Статус вынесен в отдельный столбец и кодируется цветом, потому что сотрудник приходит в эту таблицу за состоянием. Первый вопрос к реестру звучит как «что требует действия».
license-registry.jpg
Рекомендация к правке макета. Сейчас все номера лицензий выглядят одинаково, длинные GUID. Стоит заменить на разные читаемые идентификаторы, иначе таблица выглядит как заглушка.
Краевые случаи
Часть состояний была учтена, часть осталась за периметром. Проект остановился до разработки, и до полной проработки валидаций дело не дошло.
Учтено:
- ошибка при загрузке некорректного файла запроса;
- истечение срока действия как отдельный статус лицензии.
Не проработано:
- файл запроса, относящийся к другому заказчику;
- детальные сценарии восстановления после ошибки загрузки.
Это ограничение проекта. Если бы работа продолжилась, следующим шагом была бы именно проработка валидаций на входе: файловый обмен без сети означает, что некорректный файл попадёт в систему рано или поздно.
upload-error-screen.jpg
Чем закончился проект
Дизайн Лицензионного портала согласован с продуктом и подготовлен к передаче в разработку. Реализация не началась из-за нехватки ресурсов разработки.
Система не запускалась, поэтому количественных результатов у проекта нет, и качественной обратной связи от пользователей тоже.
Что остаётся от проекта как от дизайнерской работы: описанная модель статусов, правила допустимых действий и сценарий сверки изменений, готовые к реализации, когда ресурсы появятся.
Заглушка — нужна рефлексия автора. 2-3 предложения о том, что оказалось сложнее ожидаемого и какой компромисс остался в решении. Без этого блока кейс выглядит завершённым, но теряет один из сигналов зрелости.
