Загружаю страницу…
supporting · 2023 · поддерживающий
В Clinio нужно было связать несколько сторон продукта: пациента, врача и клинику. Я собирал сценарии записи, консультаций, медкарты и консилиумов в единую логику, чтобы модули не жили отдельно друг от друга.
role
Продуктовый дизайнер: ролевая архитектура, IA, ключевые сценарии пациента и врача, внешние страницы, дизайн-система как правила сценариев
что получилось
Единая логика для пациента и врача
year
2023
tags
MedTech · Multi-sided · Архитектура продукта
§ 01 · Контекст
Clinio — MedTech-сервис, где пациентский и врачебный контуры сходятся вокруг записи, консультаций, чата, медкарты, вопросов врачам, рекомендаций, консилиумов и закрытого клуба.
Сложность была не в одном красивом flow, а в ролевой архитектуре. Пациент, врач и clinic-facing контур смотрят на одну медицинскую историю из разных сценариев, но продукт должен читаться как одна система.
§ 02 · Интерфейс
Визуальный слой кейса теперь опирается на рабочие экраны: запись, медкарту и консилиум. Процессные карты остаются рядом как рабочие материалы, но не заменяют сам продукт.
§ 03 · Проблема
Локальные экраны могли закрывать свои задачи, но сквозная логика между ролями легко расползалась. Запись, анамнез, консультация, рекомендации и медкарта должны передавать один контекст, а не жить как отдельные интерфейсные куски.
Второй риск — рост продукта без системного слоя. Чем больше кабинетов, статусов, форм и повторяющихся действий, тем быстрее каждый новый модуль начинает изобретать собственные правила.
§ 04 · Роль
Моя зона была не в UI-polish отдельных экранов. Я собирал продуктовую архитектуру: ролевые контуры, IA, ключевые сценарии пациента и врача, внешние страницы и связи между модулями.
Параллельно вел системный слой: токены, компоненты, состояния и UI-гайды как правила для повторяющихся сценариев. Работал с продактом, овнером, инженерами и медэкспертами, передавал фичи в разработку и вел команду из двух дизайнеров на системном слое.
§ 05 · Как смотреть артефакты
В этом кейсе артефакты лучше читать сверху вниз: сначала карта ролей и общих сущностей, затем handoff пациента к врачу, затем медкарта и consilium workflow. Так видно продуктовую архитектуру, а не просто набор MedTech-экранов.
§ 06 · Архитектура
Главный сдвиг: продукт стал собираться вокруг ролей, общих сущностей и переходов между сценариями. Пациентский контур — запись, вопросы, медкарта, кошелёк. Врачебный — консультации, консилиумы, настройки, закрытый клуб. Clinic-facing контур в публичной версии показан как product framing, без неподтвержденных admin operations.
Важнее были не отдельные модули, а связи между ними: запись → анамнез → консультация → рекомендации → история в медкарте; вопрос → ответы → выбор врача; консилиум → обсуждение → заключения.
§ 07 · Модуль · запись на приём
Пациент выбирает врача и записывается через короткую форму. Бот собирает анамнез и передаёт его врачу до начала консультации. Дальше врач прикладывает рекомендации и отправляет заключение прямо в чате.
Здесь важно было сделать входной шаг коротким и при этом не потерять медицинский контекст до старта консультации. Это workflow evidence, не claim про conversion или clinical result.
§ 08 · Модуль · медицинская карта
В медкарте пациент отслеживает показатели анализов, историю приёмов, загружает документы и смотрит рекомендации врачей. Это место, где сходятся результаты других модулей.
Медкарта спроектирована не как визуальный архив документов, а как рабочий hub истории пациента. Главное — информационная архитектура: разделы, функциональные блоки, динамика по анализам и связь с рекомендациями.
§ 09 · Модуль · консилиумы
Врачи могут запускать консилиумы — рабочие группы по сложным случаям. Все участники видят анамнез пациента, обсуждают гипотезы в общем чате и выпускают свои индивидуальные заключения.
Тут особенно важна была согласованность сценария: много участников, общий контекст и несколько результатов на выходе. Рабочее пространство устроено так, чтобы общий уровень обсуждения и индивидуальные заключения не конфликтовали. Качество медицинских решений публично не оценивается.
§ 10 · Остальные модули
Помимо записи, медкарты и консилиумов в продукте проработаны: вопросы врачам (discovery + платное продвижение + выбор специалиста), кошелёк (платежи, вывод средств, бонусы для пациента и врача), рабочее место врача (управление приёмами + контекст пациента + заключение в одном workflow), настройки врача (внутренние данные + публичный профиль для пациентов) и закрытый клуб (внутренняя соцсеть для врачей с контентом и монетизацией).
В этой версии кейса они упомянуты обзорно, чтобы не превращать историю в каталог экранов. Основной proof остается в role architecture, appointment handoff, medcard hub, consilium workflow и design-system layer.
§ 11 · Системный слой
Дизайн-система в этом кейсе — не витрина красивых компонентов. Это слой правил для повторяющихся сценариев: формы записи, карточки врача, статусы консультации, блоки медкарты, чат, заключения, настройки и врачебные рабочие пространства.
Токены, компоненты, состояния и UI-гайды помогали масштабировать роли и сценарии без ручного пересоздания логики в каждом модуле. Это proof системного лидерства, а не claim про скорость разработки или бизнес-метрики.
§ 12 · Результат
Public source говорит, что продукт был спроектирован и запущен с нуля, но не уточняет тип запуска: MVP, public release, pilot или design delivery. Поэтому в публичной версии это directional source signal, а не измеримый product outcome.
Сильная часть кейса — то, что пациентский, врачебный и clinic-facing контуры собраны в понятную архитектуру, а дизайн-система стала инфраструктурой для роста сценариев. Clinical outcomes, conversion, retention, revenue и operational metrics не заявляются.