Clinio

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

Поэтому основной единицей проектирования стала не страница, а передача информации между ролями.

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

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

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

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

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

Я строил архитектуру вокруг истории: что появилось после консультации, где доступна рекомендация, как увидеть динамику и как этот контекст используется дальше.

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

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

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

Я координировал двух дизайнеров на этом слое. Это описание зоны ответственности, а не утверждение об ускорении команды.

Была спроектирована архитектура MedTech-сервиса: роли связаны через цепочку записи, анамнеза, медкарты, врачебной работы и консилиума. Артефакты показывают design model и source-backed workflow, а не клинический outcome.

Публичный источник говорит о проектировании и запуске с нуля, но не уточняет формат запуска. Поэтому это source gap, а не самостоятельный результат кейса.

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

Multi-role продукт нельзя собирать как сумму кабинетов. Его целостность определяется тем, какой контекст создаёт одна роль, что получает следующая и где эта информация остаётся доступной дальше.