Кейс 3 · Федеральная система · Веб
ВИМИС ОНКО
Мониторинг онкологической помощи: сводные данные по пациентам и прогноз нагрузки клиник страны
- Роль
- единственный дизайнер в команде: экраны системы, конструкторы отчётов, UI-kit. Ведущий дизайнер, БАРС Груп, Казань
- Период
- октябрь 2019 — май 2020 · 8 месяцев
- Формат
- федеральная система здравоохранения, только веб, заказчик — государство
- Пользователи
- главные врачи и чиновники всех уровней, от региональных до федеральных кураторов
- Команда
- несколько системных аналитиков, фронтенд- и бэкенд-разработчики БАРС Груп, кураторы проекта со стороны государства
Коротко для скрининга
- —Единственный дизайнер федеральной системы мониторинга онкологической помощи, БАРС Груп, октябрь 2019 — май 2020.
- —Более 300 экранов: рабочие столы кураторов, карточка пациента, методология, конструкторы отчётов.
- —Конструктор отчётов: пользователь сам группирует, настраивает и сохраняет срезы без разработчиков.
- —UI-kit на основе Ant Design: 385 компонентов, все состояния нарисованы.
- —Работал с системными аналитиками, разработкой БАРС и кураторами от государства.
- —Проект не пошёл в разработку и заморожен.
О проекте
Спроектировал более 300 экранов федеральной системы для управленческих решений: сводные данные по онкологическим пациентам страны и прогноз нагрузки клиник. Пользователей немного, но каждый принимает решения за регион или страну. Отдельная задача: конструкторы пользовательских отчётов, чтобы выборки собирались без разработчиков. В разработку проект не пошёл: закончилось финансирование, началась пандемия, команду сократили.
Задача системы не в ежедневной работе врача, а в управлении: собрать сводную картину по стране и помочь принимать решения на уровне регионов и министерства. Ключевой сценарий — прогноз нагрузки: число больных против коек, мест и загрузки. По нему решали, строить ли новые корпуса, и сравнивали уровень обслуживания между регионами. Три задачи: собрать сводную картину вместо разрозненных выгрузок, дать прогноз заранее, сделать отчётность самостоятельной. Тогда МИС была не в каждой клинике, и это учитывалось в сценариях и интеграциях.
Дизайн
Данные на экранах тестовые.
Сводная картина по стране. Федеральный куратор начинает с карты: заболеваемость по регионам и срез по диагнозу, стадии, полу и возрасту. С карты он сравнивает регионы и проваливается в нужный.
Регион и пациенты. Куратор региона видит пациентов по этапам маршрута, от подозрения на ЗНО до паллиативной помощи, и отклонения на каждом этапе: какое исследование не сделано или сделано не вовремя. Пациента можно взять на контроль.
Конструктор отчётов: отчёт собирает сам пользователь
Задача. Каждый уровень, от главврача до министерства, хотел свои срезы. ТЗ приходило от системного аналитика и уточнялось на созвонах с чиновниками. Если делать отдельный отчёт под каждый запрос, очередь к разработке не кончится.
Решение. Вместо набора отчётов одна таблица и механика, которой пользователь управляет сам: перетаскивает столбцы в группировку, выбирает набор и порядок столбцов, сохраняет удачный срез как представление и возвращается к нему. Первым на этой механике сделали отчёт «Здания»: год постройки, этажность, площадь, аварийность. Это данные о мощностях клиник, на которые опирается прогноз нагрузки.
В Figma у конструктора полный набор состояний: без группировки, с одним, двумя и тремя уровнями, сохранение, смена и удаление представления, поиск. Разработке не нужно было додумывать поведение.
Ролевая модель от главного врача до федерального куратора: свои уровни доступа, срезы данных и задачи. Интеграции с МИС регионов там, где такие системы уже работали.
Презентационные страницы отдельно для медиков и для чиновников: суть одна, язык разный. Людям без медицинского образования показатели объяснены через решения, а не через термины.
Плотные данные: таблицы, фильтры и графики для больших экранов, состояния строк, цветовые статусы, единая типографика. Ошибка в цвете статуса читается как ошибка в данных.
Как шла работа
Ключевые экраны проходили много итераций: в Figma сохранились версии карточки пациента с v.7 по v.14. Для сложных виджетов, вроде истории заболевания, я писал описание механики: какие состояния бывают у этапа, как показываются отклонения, что происходит по клику. По нему работали аналитики и разработчики.
Дизайн-система продукта
Цвета взяты из Ant Design, компоненты перерисованы вручную: очень близко к оригиналу, но не копия. Библиотеку БАРС не использовал сознательно: продукт должен был выглядеть новым, а не продолжением унаследованной системы.
Каждый компонент нарисован во всех состояниях: кнопка в четырёх типах и пяти состояниях, заголовок и строка таблицы с наведением, выбором и сортировкой.
Результаты
Эффекта в цифрах нет: в разработку проект не пошёл и, насколько я знаю, до сих пор заморожен. Системы, которая отслеживает онкобольных по всей стране, нет и сейчас: данные собирают и отдают чиновникам в виде отчётов.
От работы остались конструктор, в котором отчёт собирается без разработчика, ролевая модель от главврача до федерального куратора и UI-kit, по которому можно вести разработку. Концепт защищал перед Минздравом.
Главный вывод. В аналитических системах интерфейс — это язык описания данных. Пока не договорились о полях, уровнях и связях, ни одна форма не работает. Половина правок от чиновников касалась терминов: что считать «загрузкой», «местом», «аварийностью».
Что бы сделал иначе
- —Раньше зафиксировал бы язык данных: словарь терминов сэкономил бы недели правок.
- —Показывал бы прототипы и тем, кто читает отчёты.
- —Не строил бы сразу столько экранов подряд, а довёл бы один раздел на реальных данных.