VS Subtitles

Подробнее о процессе

Как устроена работа

VS Subtitles используют для подготовки, редактирования и выпуска субтитров.

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

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

Интервью с редакторами субтитров

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

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

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

Во время работы редакторы одновременно контролируют:

• содержание и последовательность субтитров;
• порядок сюжетов внутри выпуска;
• изменения исходного материала;
• готовность выпуска к эфиру;
• корректность отображения субтитров;
• соблюдение требований к длине текста и переносам строк.

Отображение субтитров регулируется техническими стандартами и внутренними требованиями телеканала. Редактору важно не только проверить содержание, но и убедиться, что текст корректно разделён на строки, не превышает допустимый объём и правильно отображается на экране.

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

Что я узнала

Материалы с интервью не сохранились: записи и заметки остались на рабочих ресурсах, и своей копии я не сделала. Об этом ниже, в разделе «Что я поняла».

Анализ существующих решений

Я изучила зарубежные системы, с которыми ранее работали пользователи.

В них уже были реализованы основные профессиональные сценарии:

• подготовка и редактирование субтитров;
• синхронизация субтитров с видео;
• индикация обновлённых материалов;
• сравнение версий;
• управление выпуском.

Поэтому задача заключалась не в создании процесса с нуля, а в сохранении знакомой логики и улучшении её визуальной реализации.

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

Текст терялся среди визуального шума

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

Большое количество рамок, плашек и визуальных акцентов повышало плотность интерфейса. Текст, с которым непосредственно работает редактор, визуально конкурировал с параметрами и действиями.

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

Цена пропущенного изменения: ошибка в эфире

Исходный текст сюжета мог обновиться уже после того, как для него были подготовлены субтитры.

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

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

К выпускам нужно возвращаться

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

Как я сформулировала задачу

От бизнеса пришло одно требование: заменить зарубежное ПО без переобучения пользователей. По итогам интервью и разбора конкурентов я свела его к трём задачам проектирования.

В каких рамках я работала

Сроки. Главное ограничение проекта. Разработке нужно было успеть реализовать продукт к дедлайну, и это задавало темп всей команде.

Требования телеканала и стандарты. Отображение субтитров регулируется техническими стандартами ГОСТ и внутренними требованиями канала, которым система должна была соответствовать.

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

Доступ к пользователям. Ограничен спецификой корпоративного проекта, описан выше.

Что решили не делать в этой версии

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

Сделать оба направления в оставшиеся сроки было невозможно. Продукт разделили на два самостоятельных направления, а в этом проекте сфокусировались только на онлайн-субтитрах. Офлайн-сценарий оставили на дальнейшее развитие.

Это решение сняло риск сделать оба сценария поверхностно и позволило довести эфирный до рабочего состояния.

Ключевые решения

Текст субтитра стал главным элементом строки

Снизила визуальную плотность. Убрала лишние рамки и внутренние контейнеры: текст, статусы и параметры собраны в единую структуру строки и не конкурируют друг с другом за внимание.

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

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

Убрала второстепенные действия из постоянной видимости. Они доступны через меню строки и не перегружают список. При этом весь сценарий редактирования сохранился: создание нового субтитра, разделение, объединение с предыдущим или следующим и работа через горячие клавиши.

Проработала состояния строки. Помимо базовых Default, Active и Hover добавила доменные состояния: On air означает, что субтитр сейчас находится в эфире, Released означает, что он уже был выдан. Они помогают редактору быстро понимать текущее состояние субтитра относительно эфира.

Обновление заметно на каждом шаге работы

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

Так два типа информации разделены: иконка отвечает за состояние текста, а индикатор за изменения со стороны Dalet. Поэтому редактор может быстро считать оба состояния прямо из списка.

Внутри открытого сюжета над списком субтитров появляется заметная плашка с тремя действиями: Сравнить, Отклонить и Принять. Если изменение очевидное и не требует проверки, редактор может сразу принять или отклонить его, не открывая окно сравнения и не прерывая основной сценарий работы.

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

Так редактор не теряет информацию об обновлении при переходе между выпуском, сюжетом и сравнением версий.

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

Последовательная работа с отличиями

Проверка обновления идёт под таймингом, поэтому главное для редактора понимать объём работы до её начала и не потерять ни одного изменения.

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

Для упрощения проверки я:

• визуально разделила текущую и обновлённую версии;
• выделила разные типы изменений цветом;
• показала общее количество отличий;
• добавила последовательный переход между изменениями;
• вынесла принятие и отклонение версии в отдельные действия.

В результате сравнение стало последовательным сценарием: редактор видит количество изменений, проходит по каждому из них и принимает решение после проверки текста.

Домашний экран забрал историю выпусков из папок

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

Что вынесено на первый уровень и почему:

Время выхода и план. Редактор ориентируется во времени раньше, чем в названиях, поэтому в первой колонке стоит именно оно.

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

Признак «выдан в эфир» отделяет то, что уже отработано, от того, что ещё в работе.

Фильтры по периоду, передаче и состоянию выдачи заменяют ту самую систему папок: сегодня, последние 7 дней, конкретная передача, выданные или невыданные.

Домашний экран стал основной точкой входа в продукт и заменил хранение истории выпусков в отдельных папках.

Интерфейс рассчитан на работу с клавиатуры

Редактор работает под таймингом, и скорость выдачи зависит не от мыши.

Действие	Сочетание
Выдать вручную	Insert
Убрать вручную	Delete
Запустить автовыдачу	Shift+Insert
Остановить автовыдачу	Shift+Delete
Копировать / вставить / выделить всё	Ctrl+X / C / V / A
Удалить	Ctrl+Shift+Del

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

Работа с продактом и дизайн-лидом

Продакт готовил use cases с описанием пользовательских задач, условий и ожидаемого поведения системы.

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

На основе use cases я:

• разбирала пользовательские сценарии;
• определяла структуру экранов;
• проектировала логику взаимодействия;
• разрабатывала user flow и интерфейсы;
• обсуждала спорные случаи с продактом;
• дорабатывала решения после совместных разборов.

Решения также обсуждались с дизайн-лидом. Он следил за масштабируемостью интерфейсов, связью с другими продуктами компании и консистентностью решений.

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

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

Параллельно с работой над VS Subtitles создавалась и развивалась компонентная база компании. Часть решений из продукта переходила в общую систему.

Результат

Мы сохранили знакомые пользователям сценарии профессионального ПО, но сделали интерфейс визуально спокойнее и понятнее.

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

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

Как оценивали эффект

Что я бы измерила, будь доступ к пользователям

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

Что я поняла

Сейчас я бы в первую очередь пересобрала сам процесс работы над продуктом.

Про канал обратной связи. Фидбек шёл через продакта, и до меня доходили в основном технические замечания. Сейчас я понимаю, что это ограничение процесса, а не признак того, что с интерфейсом всё в порядке: у меня не было прямого канала к пользователям, и слабые места логики просто не имели способа до меня добраться.

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

Заранее договориться о метриках. Тогда результат оценивался по наблюдениям продакта уже после запуска. Сейчас я бы зафиксировала метрики до релиза.

Довести связь изменений с субтитрами. Окно сравнения показывает изменённый текст сюжета, дальше система сама раскладывает его на субтитры по заложенным правилам. Но явной связи вида «это изменение затрагивает такие-то субтитры» в интерфейсе не было. Сегодня я бы её добавила.