В секции «Follow Up Testing» patient-portal пациент должен иметь возможность поставить напоминание чтобы пересдать тесты в указанный AI-pipeline’ом момент. UX-pattern для этого действия не зафиксирован: одна часть стека рендерит pill-кнопку на каждой карточке расписания (Remind me / Cancel / Remind me anyway), другая — одну общую кнопку в шапке секции, которая ставит напоминания на все расписания одним кликом. Решение требуется до выпуска одной из веток на прод.
Status
active — выбор: bulk header button, ради UX-parity с B2C-дашбордом (одна и та же логика в обоих продуктах, shared styling через @repo/ui). Per-card pill-вариант остаётся в репо как живой код на staging-ветке, но направление — слить в одну реализацию.
Контекст
Patient Portal — white-label B2B продукт для пациентов лабораторий. AI-pipeline возвращает список follow-up расписаний в форме (timeframe, набор тестов, медицинский purpose). Пациент решает на какие из расписаний хочет реминдер (email/WhatsApp в день).
Дополнительный фон, влияющий на выбор:
- B2C-дашборд (отдельный консьюмерский продукт RealAI) использует bulk-кнопку. Появилось желание унифицировать UX для maintenance.
- Marios — single-tenant medical reviewer cypriot lab — оценивает UX как оценочный пользователь врач. Ему нужна гранулярность («хочу реминдер на этот тест, а не на все»).
- В существующем i18n заложено четыре варианта подписей кнопки:
remindMe,remindMeAnyway,overdue,cancelReminder. Bulk-вариант использует толькоremind/scheduled.
Позиции
За per-card pills
- Семантическая ясность: каждая карточка — отдельный timeframe, пользователь выбирает что хочет напомнить
- Cancel доступен прямо из этого экрана, без перехода в отдельный «Reminders» список
- Overdue handling: для прошедших дат отдельная подпись «Remind me anyway» с приглушённым стилем — visual cue
- Соответствует структуре медицинских данных: AI выдаёт независимые расписания, не bulk-recommendation
За bulk header button
- Parity с B2C-дашбордом: одна UI-логика для двух customer-facing surfaces
- Меньше UI-шума на карточках расписаний
- Один клик ставит весь набор напоминаний — пациент не должен решать гранулярно
За гибрид (per-card + общая в шапке)
- Покрывает оба use-case: гранулярный выбор и быстрое «всё сразу»
- Сохраняет parity для bulk-кейса, не теряя per-card UX
- Открытый вопрос UX: как реагирует bulk-кнопка если часть расписаний уже scheduled (set остальных? показывать «3 of 5 scheduled»?)
Что нужно для разрешения
- Решение от продукта: parity с B2C важнее чем гранулярность управления реминдерами в B2B-портале? Или гибрид?
- Для двух не-bulk вариантов — закрепить, как UI обрабатывает: расписание с прошедшей датой (overdue label vs disabled), уже-scheduled state, cancel из этого экрана vs отдельный список.
- Для bulk варианта — закрепить визуальную видимость состояния «scheduled» (контрастный, не приглушённый стиль), доступ к cancel.
Следствия
- B2B Patient Portal и B2C-дашборд оба используют bulk-button — UX-логика общая, shared styling переиспользуется. Расхождение между продуктами не появляется.
- Per-card подход остаётся в коде до следующего cleanup’а; новые расписания добавляются в bulk-ветку. См. patient-portal-reminders для технических деталей и data-pipeline багов (которые отдельны от UX-выбора).
Открытые вопросы
- Как UI должен реагировать на расписания где AI-pipeline вернул timeframe но не вернул точное число дней — показывать кнопку (даст ошибку) или скрывать (потеря возможности).
- Time-of-day для расчёта
remindAt: сейчас наследуется от времени теста. Стоит ли нормализовать к утру в часовом поясе пациента — отдельный вопрос актуальный для всех вариантов. - Канал доставки реминдера (email через Mailgun, WhatsApp в WABA-orgs, push) и fallback path — не покрыто wiki. Carry-over: создать отдельную страницу
product/communication-channels(илиtechnical/) — будут переиспользоваться между Patient Portal, B2C, doctor-notifications и т.п., ссылаться отсюда.
Связано
- patient-portal — продукт, в котором живёт фича
- integration-options — Patient Portal как один из трёх integration paths
- patient-portal-reminders — техническая страница: pipeline, data flow, известные дефекты