Обсудить проект
UX-схема цифрового пути пациента клиники

До дизайна и разработки

Аналитика и техническое задание для цифрового продукта

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

Не создаём объёмный документ ради документа: каждый артефакт помогает принять решение.

Когда этап особенно полезен

Перед новым продуктом

Нужно определить MVP и не включить в первый релиз всё сразу.

Перед переделкой

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

Перед интеграцией

Несколько систем должны обмениваться данными, а источники истины не определены.

При разных ожиданиях

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

Этапы аналитики и UX-проектирования

Глубина каждого этапа зависит от масштаба задачи и доступных материалов.
01

Контекст и цели

Фиксируем бизнес-задачу, пользователей, ограничения и критерии готовности.
02

Текущий процесс

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

Целевой сценарий

Проектируем структуру, пользовательские потоки, состояния и прототипы ключевых экранов.

Требования и план

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

Что может войти в результат

Карта пути

Точки контакта пациента или клиента и места, где процесс теряет ясность.

Роли и сценарии

Действия пациента, администратора, специалиста, руководителя и других участников.

Модель данных

Основные сущности, связи, источники истины и правила изменения состояния.

UX-прототипы

Ключевые экраны и переходы до дорогой визуальной и технической реализации.

Техническое задание

Проверяемые требования, интеграционные контракты, ошибки и ограничения.

План релизов

MVP, зависимости и последовательность развития без обещаний неподтверждённых сроков.

Какие риски снимает подготовка

Бесконечные изменения

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

Пропущенные зависимости

Интеграции, роли и источники данных видны до того, как блокируют готовый интерфейс.

Разные трактовки

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

Практический результат этапа

Понятные границы

Что входит в проект сейчас, что остаётся следующим этапом и почему.

Основа оценки

Разработчики могут обсуждать сроки и стоимость по конкретному объёму.

Критерии приёмки

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

Общее понимание

Бизнес и техническая команда говорят об одном продукте и одних приоритетах.

Куда перейти дальше

Вопросы об аналитике и ТЗ

Можно заказать только исследование, без разработки?
Да. Границы результата и формат материалов согласуем заранее, чтобы ими могла пользоваться ваша команда или другой подрядчик.
ТЗ описывает каждый экран?
Детализация зависит от задачи. Обычно совмещаем проверяемые требования с прототипами ключевых сценариев и не дублируем одно и то же в нескольких документах.
Вы изучаете работу администраторов?
Да, если их процессы входят в продукт. Важно понять не только клиентский интерфейс, но и действия команды после обращения или записи.
Что потребуется от клиента?
Доступные регламенты и материалы, интервью с ответственными участниками, демонстрация текущих систем и решения по спорным бизнес-правилам.
Как оценить сроки и стоимость этапа?
После вводной встречи: учитываем число ролей, процессов, систем, требуемую глубину прототипов и формат итоговой документации.

Начнём с задачи и границ обследования

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