Привет! В этой статье мы – Никита Сошин, Senior продуктовый дизайнер и Team Lead проекта, и Александра Дёмина, Senior продуктовый дизайнер – во всех подробностях расскажем о том, как evilUnion сделал перезапуск платформы цифровой патоморфологии и почему этот проект нельзя назвать обычным редизайном.

Немного о проекте

Histoscan – это B2B MedTech SaaS платформа для клиник, лабораторий и исследовательских центров. Она упрощает работу с большими объёмами медицинских данных, просмотр изображений, аннотирование и диагностику, сокращает путь до составления заключения, обеспечивает сценарии для совместной работы и при всём этом соответствует высоким требованиям безопасности. 

Какие цели перед нами стояли

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

Почему старый продукт требовал перезапуска

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

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

Команда и процесс: как мы организовали работу

Над проектом работала большая команда, состоящая из стейкхолдеров, бизнес-аналитика, продакта, продуктового дизайн лида, продуктовых дизайнеров, Front-End команды, Back-End команды и менеджмента по продажам. Такой набор специалистов позволял закрывать и технические, и продуктовые задачи без существенных тормозов. Процесс создания проекта мы разделили на итерации. Первый этап – discovery фаза, далее шла разработка и запуск MVP, а затем продуктовый дизайн и масштабирование проекта.

Что мы узнали о реальной работе врачей

Когда мы углубились в продукт, мы обнаружили важные факты про реальные сценарии пользователей. Врачи-патологи чаще всего работают в системах Sectra (>70%) и OneCell (>15%), а Histoscan 1.0 использовали единицы (<5%). При этом для полного цикла исследований врачи работают с сущностями вроде пациентов, случаев и исследований, просматривают микропрепараты и макроизображения, проводят диагностику, организуют консультации и пишут заключения. Это не разовое взаимодействие, системы используются по 40–56 часов в неделю. Для нас это означало, что оптимизация ключевых путей не может быть косметической, она должна быть глубокой и системной.

Какие проблемы пользователей мы обнаружили

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

Какие гипотезы мы сформулировали

Из анализа работы пользователей выросли продуктовые гипотезы. 

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

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

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

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

Ограничения, рамки и требования

Стейкхолдеры, менеджеры и аналитики определили технические характеристики целевых устройств приложения. Большинство клиник работает на 4К мониторах 27 дюймов, а в лекториях часто применяют телевизоры 32 дюйма и выше, при этом 90% устройств, пользующихся облачной версией, имеют масштаб не менее 1536px. 

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

Учитывая вышеперечисленные ограничения, было принято решение использовать модель SaaS. Она давала преимущество в том, что гипотезы можно проверять быстро и исправлять ошибки на лету, но при этом важно было помнить про браузерные ограничения.

Первые шаги: User Flow и прототипы

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

Первые прототипы были разными, где-то мы докручивали интерфейс, где-то кардинально меняли логику. Большая часть работы проходила через регулярную коммуникацию с командой разработки, продакт-менеджерами, стейкхолдерами, экспертами и, конечно, с врачами. Параллельно мы оформляли требования в виде CJM, Acceptance Criteria и User Stories. Медицинские приложения содержат большое количество ГОСТов, требований к безопасности и конфиденциальности, поэтому каждое действие в макете нужно было согласовать с различными инстанциями. Каждую функцию описывали много раз, пока не находили компромисс, который бы одновременно устраивал и пользователя, и системы безопасности.

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

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

Viewer – сердце системы

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

Как мы проектировали layout, навигатор и ленту изображений

Разработка layout и навигатора тоже шла долго. Самой важной частью всего UI оказались поля лэйаута, то есть поля просмотровщика. Эти поля разделились на три типа: для микропрепаратов, изображений и видео.

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

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

Чаще всего врачи работают сразу с несколькими изображениями или даже с нескольким количеством разных исследований. Для таких ситуация мы разработали удобный инструмент взаимодействия с сущностями и контентом – ленту изображений. По результатам опросов врачей этот инструмент показал 100% CSAT и 100% понимание инструмента.

Как мы переосмыслили менеджмент сущностей

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

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

• Мы добавили системный список с названием “Доступные мне”, который стал нашим стартовым экраном. 

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

• Мы вынесли пользовательские списки в отдельную группу и сделали их всегда доступными. 

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

Панель информации: неожиданное преимущество продукта

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

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

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

Аннотации – ключевой инструмент врачей

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

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

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

Заключения и безопасность

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

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

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

Настоящая киллер-фича

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

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

CRUD, хаб загрузок и модальные окна

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

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

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

Как мы сделали консультации удобными и безопасными

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

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

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

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

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

Онбординг, уведомления и снижение когнитивной нагрузки

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

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

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

Дизайн-система: цвета, типографика, иконки, компоненты

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

Также мы разработали набор из 200+ иконок, адаптированных под узкие потребности продукта. Сет был необходим, поскольку существующие наборы не покрывали все потребности. Мы выделили время на дизайн и тестирование иконок, так как непонятная или недостоверная иконка может стать помехой в работе врача. Иконки выполнены в едином стиле и отлично вписались в интерфейс, не отвлекая внимание от главного. Мы провели несколько итераций и тестов понимания иконок среди врачей. После обучения узнаваемость иконок достигала 90%. Новые пользователи могли практически сразу идентифицировать назначение значка без дополнительных инструкций.

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

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

Что получилось, и что мы вынесли из проекта

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

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

А мы в evilUnion продолжим создавать сложные и интересные проекты с эстетичным UI.