MedTech-платформа / 2023
Clinio: сервис для пациентов, врачей и клиники
Clinio объединял пациента, врача и клинику в одном продукте. Моя задача была не просто нарисовать экраны, а собрать архитектуру, сценарии и дизайн-систему так, чтобы разные роли не ломали друг другу опыт.
Моя роль
Работал над информационной архитектурой, ключевыми сценариями и дизайн-системой: раскладывал модули, проектировал пользовательские пути и приводил интерфейсы к общим правилам.
Задача
В одном продукте жили разные роли и разные глубины сценариев
Пациенту нужен быстрый доступ к записи, вопросам врачу и медкарте. Врачу — рабочий контекст, консультации и консилиумы. Клинике — более системный слой. Если не собрать роли и общие сущности заранее, продукт быстро распадается на разрозненные кабинеты.
Моя роль
Что именно я делал
Работал над информационной архитектурой, ключевыми сценариями и дизайн-системой: раскладывал модули, проектировал пользовательские пути и приводил интерфейсы к общим правилам.
Что изменил
Конкретные изменения в интерфейсе
Каждый блок показывает не абстрактный вывод, а рабочий экран или состояние, с которым сталкивается пользователь.
01
Платформа получила общую карту ролей и модулей
Сначала важно было увидеть продукт целиком: пациент, врач, клиника, консультации, медкарта, записи и документы связаны между собой, а не живут отдельными островами.
02
Запись и консультации стали понятным пользовательским путем
Сценарий должен быстро объяснять, что будет дальше, какие данные нужны и где пользователь находится в процессе.
03
Медкарта стала частью сервиса, а не отдельным архивом
Документы, рекомендации и история обращений должны помогать врачу и пациенту в текущем сценарии, а не просто храниться в отдельном разделе.
04
Консилиумы собрали совместную работу врачей
Врачам нужен общий контекст: обсуждение, материалы, статус и следующий шаг должны читаться на одном рабочем экране.
Рабочие материалы
Слой под интерфейсами: карты, матрицы и решения
Эти материалы показывают ход мысли: где были роли, развилки, спорные места и правила для повторяемых сценариев. Интерфейс остается главным результатом, а материалы объясняют, почему он устроен именно так.
Module map
Как связаны разделы, сущности и повторяемые паттерны.
JTBD matrix
Какая работа стоит за ролью, а не за отдельным экраном.
User flow
Шаги, развилки и состояния внутри одного сценария.
Before/after IA
Что подняли в первый слой, а что оставили вторичным.
Карта платформы
Так я держал перед глазами роли, модули и связи между ключевыми сущностями продукта.
Зачем это было нужно
Карта помогала проверять, не превращается ли продукт в набор отдельных кабинетов для разных ролей.
JTBD-матрица
Матрица помогала не спорить об экранах в отрыве от задач: сначала роль и работа, потом интерфейс.
Зачем это было нужно
Так решения по экрану привязывались к реальной работе пациента, врача или клиники.
Путь записи и консультации
Карта сценария показывала, какие шаги проходит пациент, где появляются данные и что нужно объяснить до следующего действия.
Зачем это было нужно
Материал помог удержать сценарий коротким и не смешивать запись, оплату, вопросы и медицинский контекст в один экран.
Структура медкарты
Отдельный слой для медицинских данных: что должно быть рядом с текущим приемом, а что может оставаться в истории.
Зачем это было нужно
Так медкарта стала рабочим контекстом для сервиса, а не просто архивом документов.
Сценарий консилиума
Отдельная карта для сложного медицинского сценария: кто участвует, что обсуждается и какие материалы нужны рядом.
Зачем это было нужно
Материал помог собрать совместную работу врачей вокруг общего контекста, а не вокруг переписки без структуры.
Результат
Продукт стал собираться вокруг ролей и общих сущностей
В публичном кейсе показываю архитектуру, интерфейсы и рабочие материалы. Точные бизнес-метрики не раскрываю, поэтому результат формулирую честно: продукт получил более цельную структуру для нескольких ролей и основу для дальнейшего масштабирования.
Предыдущий кейс
Авиационная операционная система
Следующий кейс
ERP для проектной компании