О проекте

Histoscan — B2B MedTech SaaS-платформа цифровой патоморфологии для клиник, лабораторий и исследовательских центров.

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

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

Бизнес-задачи

• Разработать интерфейс, UI-kit и дизайн-систему с нуля.
• Оптимизировать ключевые пути пользователя.
• Внедрить режим аннотирования и панель аннотаций.
• Спроектировать функциональности консультаций и real-time коллабораций.

Проблематика

Приложение запускалось как MVP в 2020 году с базовыми функциями — просмотр, комментарии, шэринг. Уже на этапе первых внедрений выявились серьёзные UX-проблемы и отставание от рынка.

В 2022 году, на фоне сокращения поставок зарубежных решений, стало ясно, что локальная MedTech-платформа имеет высокий потенциал. Но отсутствие команды и продуктового дизайна не позволяло проекту развиваться: он не масштабировался, не соответствовал современным UI/UX-стандартам и не привлекал новые клиники.

Для выхода на рынок требовалась полная перезагрузка и новое видение!

В команду входили: стейкхолдеры, бизнес-аналитик, Product Manager, Продуктовый дизайн-лид, Продуктовые дизайнеры, Front-End команда, Back-End команда, Sales-менеджмент.

Процесс создания

1. Discovery фаза
2. Разработка и запуск MVP
3. Продуктовый дизайн и масштабирование

Основные инсайты

Врачи-патологи работают в Sectra (>70%), OneCell (>15%) или Histoscan 1.0 (<5%) для полного цикла исследований: менеджмент сущностей (пациентов, случаи, исследования), просмотр изображений (микропрепараты, макроизображения, диагностика), консультации и составление заключений.

Системы используются по 40–56 часов в неделю, что делает оптимизацию ключевых путей критически важным.

Проблемы пользователей

1. Старшие врачи (40+) — сопротивляются изменениям: привыкли к тому, что есть, ценят стабильность, боятся потерь привычных паттернов.
2. Молодые врачи — часто предпочитают физический анализ цифровому, т.к. цифровые системы сложные — онбординга нет (старшие коллеги не хотят обучать).
3. Общая боль: сложный и неочевидный путь достижения конечной цели — заполнение заключений, сложность в навигации, нет акцента на основной задаче.

Продуктовые гипотезы

• Пользователи не хотят долго обучаться, поэтому новый флоу нужно строить на основе привычных паттернов.
• Для новичков необходимо сделать онбординг, гайды и подсказки.
• Конечная цель работы врача — написать заключение. Строим интерфейс с очевидным акцентом на этой фиче.
• Пользователи могут сравнивать разные изображения и сущности. Поэтому в режиме «просмотра» делаем возможность добавлять вкладки со случаями.
• Во время просмотра микропрепаратов пользователи часто обращаются к информации об исследовании, случае или пациенте. Даём быстрый доступ к этой информации прямо из режима «просмотра».
• Консультации с другими пользователями — востребованная фича, но она не очевидна или отсутствует в других приложениях. Поэтому чаще всего пользователи используют комментарии для консультаций — это нарушает конфеденциальность пациентов. Делаем консультации удобными и очевидными для пользователей.
• Количество аннотаций на одном слайде может достигать 20, в редких случаях — 100. Делаем современный и удобный инструментарий аннотирования, даём пользователям список всех аннотаций.

Требования

Стейкхолдеры, менеджеры и аналитики решили, что целевые устройства приложения — от 1536px и выше. Было решено создавать по модели SaaS, а значит, нужно учитывать ограничения и совместимость браузеров, а также производительность.

В клиниках чаще всего используются 4К 27“, в лекториях — телевизоры от 32“, а 90% устройств, которые используют облачную версию, имеют масштаб от 1536px.

Например, из-за специфики data-intensive информации на экране очень много, предполагалось, что UI будет занимать большую часть экранного места (это показали и первые прототипы), а значит, нужно стараться его экономить, но не жертвовать читаемостью.

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

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

Старт проекта начался с изучения существующих приложений — в особенности Histoscan 1.0 — и знакомства с работой клиник и патологоанатомов. За время проекта мы сделали более 40 прототипов.

User Flow и Wireframe

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

Тестировали разные гипотезы и обсуждали границы со стейкхолдерами.

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

Первые прототипы

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

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

CJM, Acceptance Criteria, User Stories, т.д.

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

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

Viewer

Режим “Просмотр” — это один из 2 базовых режимов приложения.

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

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

Layout и Навигатор

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

Просмотр микропрепаратов — это целевое действие пользователя и все приложение завязано именно на просмотре микропрепаратов.

Просмотр изображений и видео — это вспомогательные действия для большего контекста врача при исследовании.

Поэтому поле под микропрепараты оснащено навигатором, панелью управления (в том числе — Z-стеками) и линейкой для понимания масштаба. В навигаторе также можно включить карту просмотренных областей.

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

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

Лента изображений

Чаще всего целевых изображений >1, а еще часто больше 1 исследования. Мы разработали удобный и крайне понятный инструмент для просмотра вложенностей в случае — ленту изображений. Наши опросы по врачам выявили 100% CSAT и 100% понимание инструмента.

Physician Account

Режим “Списки” — это второй важнейший режим приложения.

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

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

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

1. Добавили системный список “Доступные мне” — это был наш стартовый экран и люди сразу могли начинать работу, не пытаясь разобраться, где они находятся. По своей сути “Доступные мне” — это буквально все сущности в одном списке. А такое название сразу дало понимание пользователю, куда кликать, если он потерялся.
2. Сделали двухуровневую систему вместо многоуровневой — так пользователи теряются очень редко.
3. Вынести пользовательские списки в отдельную группу — свои всегда под рукой.
4. Добавили поиск — практически никто не пользовался поиском, но как бы странно ни звучало поиск просто создавал точку опоры, при которой всегда можно найти все, что нужно, если потерялся.

Панель информации

УТП всего приложение, которое было разработано в процессе полировки интерфейса, — это панель информации.

Панель информации — это панель, которая показывает все данные, которые мы можем внести в сущность или прикрепить к ней. Оба режима дают возможность открыть такую панель, за счет этого у пользователей быстрее стало формироваться привыкание к ней, они быстрее обучались. А за счет того, что и в режиме “Просмотр” эта панель была доступно, пользователю не требовалось прыгать по режимам или держать режим “Списки” открытым в отдельном окне.

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

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

Аннотации

Еще одним нашим УТП стала панель аннотаций

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

Мы значительно переработали и улучшили само аннотирование. Инструменты стали настолько наглядными и удобными, что как стейкхолдеры, так и врачи были в восторге от них. В процессе работы мы провели около 10 воркшоп-сессий по аннотациям и вывели ряд продуктовых важнейших продуктовых гипотез. Каждая аннотация имеет все необходимые состояния для прохождения accessability-теста.

Так как мы дизайнеры, да еще и сидим постоянно в фигме, было бы опрометчиво сделать инструмент рисования слабым, поэтому мы взяли все основы рисования в наших любимых приложениях, наложили на бизнес-задачи и докрутили исходя из того, что нам казалось важным для врачей (например, состояния hover и active, которые отлично отделяют аннотацию от фона и позволяют увидеть все ее границы четко, вне зависимости от выбранного цвета и изображения на фоне).

Заключения

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

На данный момент написание заключения сделано в виде простого text field, но в отделе дизайна мы начали разрабатывать шаблонные заключения, которые позволяли бы создавать целые макеты заключений для заполнения.

Заключения можно писать как в плавающей панели, так и в закрепленной справа под панелью информации/аннотаций или вместо них.

Также можно просматривать другие или предыдущие заключения для большего контекста.

Совместная работа

Киллер фича всего приложения — это возможность совместной работы!

Можно создавать комнаты для локальных пользователей или временные ссылки для внешних пользователей.

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

CRUD сущностей и загрузка изображений

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

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

Мы разработали 2 вида модальных окон — кофирмы и окна создания и редактирования.

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

Окна создания и редактирования гораздо сложнее, но от этого было еще интереснее их делать! Для них мы сделали 9 input field, которые помогают при любой бизнес-задаче создавать все, что требуется без компромиссов.

Консультирование

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

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

Мы сделали систему консультирования внутри приложения, максимум, что приходит снаружи консультанту или консультирующемуся — это уведомления о том, что консультация/ответ/уточнение поступили.

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

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

По началу пользователи вообще не приняли такой инструмент, потому что им было проще пользоваться комментариями или отвечать в личных чатах/на почте. Но требования безопасности вводятся на уровне государства, поэтому мы не могли согласиться с нашими пользователями. Переход был тяжелый, но сейчас пользователи привыкли к нему. Мы проводили юзабилити тесты и они показали отличный task-success rate в 75% уже через неделю начала использования.

Slides

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

Создание и редактирование презентации

На данный момент реализованно упрощенной создание и редактирование презентации, так как проект находится на стадии MVP.

Онбординг и уведомления

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

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

Такие гибкие вьюхи создали простор для любого использования подсказок и онбординга в любой части UI.

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

Настройки

Дизайн-система

Система цветов

В середине проекта, уточнив у бизнеса точки развития проекта, мы поняли, что нужно разработать систему цветов. Проанализировав современные подходы в создании дизайн-токенов, родилась замечательная идея — называть цвета отвлеченными именами. Так белый цвет больше не “белый”, не “светлый” и не “снег”, он назван нейтрально без ассоциации с ним, чтобы при настройке разным тем приложения у нас не возникало конфликтов, когда “светлый” вдруг должен быть черным, а не белым. Поэтому мы взяли то, к чему у Никиты Сошина — нашего старшего дизайнера — лежит душа: планеты из Звёздных войн!

Сет иконок

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

Они подчиняются общим правилам построения, выполнены в едином стиле и отлично вписываются в приложения не забирая внимания.

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

Типографика

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

Например, минимальный текстовый стиль используется с размером в 10px, что может показаться маленьким на первый взгляд, однако увеличив letter spacing на 0.3px получилось повысить его читаемость, что показали тесты среди пользователей и этот текстовый стиль позволил нам найти компромисс.

Компонентная библиотека

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

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

Есть два компонента, которыми мы гордимся, один из них —кнопки! Компонент кнопок настроен настолько гибко, что позволяет использовать один компонент на всех уровнях интерфейса, где нужно какое-то нажатие.

Обычно иконочная кнопка и текстовая имеют разные компоненты, однако в нашем случае получилось использовать ее одну, настраивая изнутри!

Основная команда

Никита Сошин — Senior Продуктовый дизайнер, Team Lead
Александра Дёмина — Senior Продуктовый дизайнер