VS Ecosystem
Внутренняя система выпуска и учёта лицензий на ПО в закрытом контуре, изолированном от сети ради защиты данных.
B2BWeb
Коротко
О компании
Vidau Systems занимается B2B-разработкой ПО для медиавещания. Продукты компании устанавливаются в инфраструктуру заказчика: телеканалов и вещателей.
Контекст
Продукты Vidau работают в закрытом контуре заказчика: инфраструктура намеренно изолирована от внешней сети, чтобы данные не могли из неё утечь.
Лицензии на эти продукты выдавались вручную. Данные жили в разных местах, единого реестра не было, запросы на изменение приходили файлами и разбирались глазами.
Задача
Собрать лицензирование в один управляемый процесс на стороне Vidau.
Главное ограничение задачи было техническим: прямой интеграции между Vidau и заказчиком не существует, поэтому файловый обмен остаётся в сценарии при любом дизайне. Проектировать нужно было вокруг него.
Основной риск в процессе был связан с ошибкой при сверке: пропущенный изменённый параметр приводит к выдаче неверного ключа.
Что сделала
- Разобрала процесс лицензирования вместе с системным аналитиком и зафиксировала его в BPMN, чтобы понять, где именно человек принимает решение
- Спроектировала реестр лицензий как точку входа, где состояние всех лицензий видно в одной таблице
- Связала статус лицензии с набором допустимых действий в карточке: недопустимое действие в интерфейсе отсутствует
- Спроектировала сценарий обработки запроса на изменение: первая версия была формой, на которой изменения терялись, вторая стала сравнением с типизацией строк
- Держала решение устойчивым к меняющемуся скоупу: логика лицензии проектировалась отдельно от логики каталога
Роль и команда
Продуктовый дизайнер в команде из продакта, системного аналитика и лид-дизайнера. Около года: с 2025-го, работа над дизайном продолжалась ещё в начале 2026-го.
Результат
Дизайн Лицензионного портала согласован с продуктом и подготовлен к передаче в разработку. До реализации проект не дошёл: в компании не хватило ресурсов разработки.
Подробнее о процессе
Ограничение, которое определило весь дизайн
Инфраструктура заказчика представляет собой закрытый контур: она намеренно изолирована от внешней сети, чтобы данные не могли из неё утечь. Продукт работает локально, поэтому прямая интеграция между Vidau и заказчиком технически невозможна.
Отсюда следует конструкция всего процесса: заказчик формирует файл запроса, отправляет его, Vidau выпускает файл лицензии в ответ.
Это ограничение снимает целый класс решений. Автоматическая синхронизация, онлайн-активация, проверка лицензии по сети в этом контуре недоступны.
Задача сузилась до одного участка: сделать предсказуемым тот шаг, где человек на стороне Vidau принимает решение о выдаче.
Что было не так с процессом
Процесс существовал и работал, но держался на внимании конкретных людей.
Состояние было размазано. Данные о лицензиях хранились в разных инструментах. Ответ на вопрос «что сейчас с лицензиями этого заказчика» собирался вручную из нескольких источников.
Изменения приходилось искать глазами. Запрос на изменение приходил файлом. Сотрудник открывал его и сверял с тем, что было выдано раньше. Ничто в этом процессе не подсвечивало, что именно поменялось.
Правила жили в голове. Что можно сделать с конкретной лицензией, зависело от её состояния. Эти правила нигде не были выражены, поэтому корректность операции зависела от опыта сотрудника.
Ключевой риск здесь связан не со скоростью работы. Ошибка при сверке приводит к выдаче лицензии по неверным данным, а исправление в закрытом контуре стоит ещё одного цикла файлового обмена.
Кто пользователь
Основной пользователь Лицензионного портала: администратор Vidau, сотрудник, который ведёт лицензии и обрабатывает входящие запросы. Рядом с ним инженеры, которые сталкиваются с лицензированием при установке продуктов.
Заказчик участвует в процессе на своей стороне: формирует запрос и получает файл лицензии. Полноценным пользователем портала он не становится.
Весь интерфейс дальше спроектирован под человека, который принимает решение о выдаче.
Как менялся проект
Проект шёл около года, и большую часть этого времени менялась сама концепция продукта.
Изначально Ecosystem задумывалась как единая среда с библиотекой всех продуктов компании, ближе к магазину приложений. Отсюда название. Постепенно скоуп сужался, и в итоге остались две части: лицензирование и установщик.
Для дизайна это означало, что опираться на финальные требования было нельзя, их не существовало. Решение приходилось строить так, чтобы оно не разваливалось при следующем сужении: логика лицензии проектировалась отдельно от логики каталога, интерфейс не завязывался на функции, которые могли исчезнуть.
Моя роль и scope
Продуктовый дизайнер в команде из продакта, системного аналитика и лид-дизайнера.
За что отвечала я:
- реестр лицензий целиком;
- карточка лицензии, модель статусов и логика допустимых действий;
- сценарий обработки запроса на изменение: структура, шаги, первая версия экрана сверки;
- разбор процесса лицензирования вместе с аналитиком.
Что было командной работой:
- финальная визуальная типизация строк в экране сверки, доработка с лид-дизайнером;
- описание процесса в BPMN, вместе с системным аналитиком;
- границы скоупа и приоритеты, с продактом.
Доступ к пользователю был: я показывала экраны администратору Vidau, который в реальности ведёт лицензии, и он оценивал решения как эксперт: говорил, подходит вариант или нет. Формальных исследовательских тестов при этом не проводилось.
Ключевые решения
Решение 1. Обработка запроса на изменение
Сценарий состоит из трёх шагов: загрузка файла запроса, сверка изменений, выдача ключа.
Первая версия и почему она не сработала
Сначала я спроектировала сверку как форму: список полей с инпутами и выпадающими списками, куда подтягивались данные из запроса.
На реальном объёме данных стала видна проблема. Строки выглядели одинаково, изменённый параметр ничем не отличался от неизменённого. Экран показывал данные, при этом главная задача шага (заметить разницу) оставалась на внимании человека. Форма воспроизводила ту же слабость, что была в ручном процессе.
Что сделали вместо
Экран перестал быть формой и стал сравнением.
Каждая строка получила тип: изменённая, новая, удалённая. Тип задан визуально, поэтому просмотр превращается в сканирование.
Решение по каждой строке принимается явно, через принять или отклонить. Выдача ключа доступна после того, как все изменения обработаны, поэтому пропустить строку молча нельзя.
Про роль: первую версию сценария и его логику проектировала я. Проблему читаемости увидела и принесла в команду тоже я. Финальную визуальную типизацию строк собирали в паре с лид-дизайнером.
Решение 2. Действия зависят от статуса
Лицензия проходит через статусы: доступна, выдана, аннулирована, истёкшая.
Набор действий в карточке определяется статусом. Недопустимое действие в интерфейсе отсутствует, оно не блокируется с объяснением. Так правила перестают жить в голове сотрудника и становятся частью системы.
Карточка разделена на два блока: основные данные лицензии и параметры. Первый отвечает на вопрос «что это за лицензия», второй на вопрос «что в неё входит».
Решение 3. Реестр лицензий
Реестр служит точкой входа в систему. Таблица со статусами и фильтрами, из которой видно состояние всех лицензий и можно провалиться в конкретную.
Статус вынесен в отдельный столбец и кодируется цветом, потому что сотрудник приходит в эту таблицу за состоянием. Первый вопрос к реестру звучит как «что требует действия».
Результат
Дизайн Лицензионного портала согласован с продуктом и подготовлен к передаче в разработку. Реализация не началась из-за нехватки ресурсов разработки.
