ArtVision: рабочий процесс в радиологии

ArtVision разрабатывает медицинское программное обеспечение с 2004 года. По данным сайта компании (октябрь 2026), платформа насчитывает более 3000 лицензий рабочих мест радиолога и более 40 интеграций с медицинскими информационными системами.

Я работал над ней с декабря 2021 по март 2026 года дизайнером в продуктовой команде, вместе с аналитиками и разработчиками. Основное время ушло на сервис для радиологов в радиологической информационной системе (РИС). Кроме него, я проектировал планирование исследований, конструктор протоколов, интерфейс для лаборантов (2023) и развивал единую систему компонентов.

Кроме перечисленного, участвовал в проектировании интерфейсов функций платформы, описанных на сайте компании: PACS/РИС, диагностическая станция и веб-вьюер, шаблоны заключений, голосовой ввод, цифровая патология (ЛИС), телерадиология, постобработка КТ и ИИ-модули (разметка КТ, второе мнение, приоритизация исследований). Внутреннюю логику, технологии и результаты работы модулей не раскрываю: это под NDA.

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

СИСТЕМА. Новые решения встраивались в существующий продукт со сложившейся логикой. Каждое изменение нужно было проверять вместе с его последствиями для связанных сценариев.

ОБЛАСТЬ. За названиями полей, статусов и действий стоят рабочие процессы врачей и лаборантов. Чтобы спроектировать интерфейс, сначала нужно разобраться в значении данных и границах задачи.

ГИБКОСТЬ. Медицинским документам и процессам нужна настраиваемость, а каждая дополнительная возможность увеличивает число решений, которые принимает пользователь и команда разработки.

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

Параллельно развивал единую дизайн-систему для линейки продуктов: UI-kit с документацией, светлую и тёмную темы, цветовые стили на примитивах и токенах. Изменение, сделанное один раз, применяется ко всем интерфейсам, а не правится в каждом макете вручную. Отдельно улучшал передачу макетов разработчикам.

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

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

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