CHILDFREE TRUST

ПРОБЛЕМА

Childfree Trust працює у високочутливій сфері — надаючи фідуціарні послуги та планування спадщини для осіб без дітей чи близьких родичів. Наявна платформа стикалася з критичними викликами:

• Екстрені ситуації вимагають миттєвого доступу до медичних документів, POA (довіреності) та юридичних директив — але система була фрагментованою та повільною
• Три різні ролі користувачів (Call Center, Medical, Welon Trust) потребували різних інтерфейсів і дозволів, але UX був непослідовним і заплутаним
• Відсутня єдина дизайн-система — компоненти були розрізнені, що сповільнювало розробку та робило інтерфейс непослідовним
• Складні робочі процеси медичних інцидентів, доступу до документів та подання доказів не мали чіткого візуального супроводу
• Обробка конфіденційних даних вимагала суворого рольового контролю доступу без втрати юзабіліті

РІШЕННЯ

Це був не просто черговий CRM — це життєво важлива система, де кожна роль має унікальні робочі процеси, але всі повинні мати спільну візуальну мову та патерни взаємодії:

• Call Center обробляє звітування та маршрутизацію екстрених медичних інцидентів (5-кроковий процес)
• Medical Role проводить медичні огляди, відстежує POA / звіти My Care та керує медичними нотатками
• Welon Trust керує екстреним доступом до документів, поданням доказів, відправленнями та статусом дієздатності користувачів

ПРОБЛЕМА

З трьома різними ролями, складними дозволами та ієрархічними даними (Клієнти → Документи → Інциденти → Докази) ризик створення заплутаного, перевантаженого інтерфейсу був високим. Користувачам потрібно було швидко переміщатися між дашбордами, кейсами та документами без втрати орієнтації.

РІШЕННЯ

Я спроєктував чітку, ієрархічну інформаційну архітектуру з:

• Бічною навігацією, організованою за логічними модулями (Dashboard, Users, Documents, Incidents, Evidence, Alerts)
• Розгорнуваними секціями меню для зниження когнітивного навантаження при збереженні швидкого доступу
• Консистентними патернами даних у всіх модулях (фільтри → таблиця → дії)
• Багаторівневим drill-down від огляду дашборду до детальних записів кейсів

ПРОБЛЕМА

Платформа мала базову дизайн-систему, але компоненти були непослідовними, документація — неповною, і система погано масштабувалася на 100+ екранів та 3 різні ролі користувачів.

РІШЕННЯ

Я вдосконалив та консолідував наявну дизайн-систему в єдиний, масштабований фреймворк:

• Кольорова система: витончена фіолетова/індигова основна палітра, що передає довіру, професіоналізм і медичну достовірність; семантичні кольори для статусних індикаторів (зелений = схвалено, червоний = терміново, помаранчевий = в очікуванні)
• Типографіка: чиста, високочитабельна sans-serif система, оптимізована для щільних до даних інтерфейсів та довгих робочих сесій
• Відступи та сітка: 8px сітка, що забезпечує консистентність у всіх компонентах
• Система іконок: кастомні фіолетові лінійні іконки з консистентною товщиною штриха та стилем у всіх модулях
• Бібліотека компонентів: навігація, таблиці даних, статусні бейджі, форм-інпути, кнопки, таби, алерти та сповіщення, картки й модалки
• Масштабованість: багаторазові патерни в усіх модулях, консистентні патерни дій (eye-іконка для перегляду, three-dot меню для додаткових дій) та модульна архітектура, що дозволяє розробникам швидко будувати нові екрани

ПРОБЛЕМА

Три різні ролі користувачів з різними обов'язками потребували адаптованих інтерфейсів, але підтримання консистентності при наданні рольової функціональності було викликом.

РІШЕННЯ

Я спроєктував уніфіковану структуру навігації з рольовими варіаціями меню:

• Спільна навігація: Dashboard, Documents, Help, Log out — доступна для всіх ролей
• Рольові модулі: Call Center Role — Medical Incident (створення та управління 5-кроковими звітами про інциденти); Medical Role — Medical Review (4-крокові огляди, відстеження POA та звітів, управління медичними нотатками); Welon Trust Role — Dashboard, Document Management, Emergency, Submit Evidence, Shipping & Tracking
• Контекстний сайдбар: фіолетовий акцентний колір для активних станів, мітки секцій (MENU / OTHERS)
• Профіль користувача: профіль у правому верхньому куті з ім'ям, email та дзвіночком сповіщень для всіх ролей

ПРОБЛЕМА

В екстрених ситуаціях (недієздатність клієнта, госпіталізація) персоналу Welon Trust потрібен миттєвий доступ до критичних функцій. Традиційні дашборди зі складними графіками та метриками гаять дорогоцінні секунди.

РІШЕННЯ

Я спроєктував оптимізований дашборд «Quick Actions» з 4 великими, чітко підписаними картками:

• Access Documents: іконка з документом + хмарою — миттєвий доступ до юридичних документів, медичної POA та директив
• Upload Documents: іконка зі стрілкою завантаження — швидке додавання нових медичних записів, судових наказів або доказів
• Submit Evidence: іконка зі щитом + галочкою — подання документації для запитів екстреного доступу
• Settings: іконка з шестірнею — конфігурація системи та налаштування
• Панель статусу системи: зелений банер угорі з «System Status: Operational» та міткою часу останньої перевірки для прозорості
• Чітка візуальна ієрархія: великі картки з фіолетовими іконками, мінімальним текстом і правими стрілками для чіткої афордантності

ПРОБЛЕМА

Персоналу потрібно швидко визначати, які клієнти є недієздатними, щоб запускати екстрені протоколи. Без чітких візуальних індикаторів критичні кейси можуть бути пропущені.

РІШЕННЯ

Я спроєктував таблицю управління користувачами з помітними бейджами статусу недієздатності:

• Колонки таблиці: Name, Email, Incapacitation Status, Actions
• Бейджі статусу: «Not Incapacitated» — нейтральний сірий контур; «Incapacitated» — червоний контур для миттєвої візуальної уваги
• Фільтри та пошук: фільтр користувачів, пошуковий рядок ім'я/email + кнопка «Incapacitation Status» для швидкої фільтрації
• Перемикач виду: кнопка «View» для перемикання між списком/сіткою
• Кнопка оновлення: фіолетова кнопка «Refresh» у правому верхньому куті для оновлення даних у реальному часі
• Пагінація: 10 рядків на сторінку з навігацією для управління 5k+ записами

ПРОБЛЕМА

Юридичні документи проходять кілька етапів (Generated → Approved → Created → Declined). Персоналу потрібно відстежувати статус документів, управляти відправленнями та обробляти відхилення з чіткими причинами.

РІШЕННЯ

Я спроєктував комплексний інтерфейс управління документами з відстеженням статусів та кнопками дій:

• Селектор учасника: дропдаун для вибору клієнта + інформаційна картка учасника з ім'ям, email, ID, статусом (Member/Active) та кнопкою Notes
• Таб-навігація: таби Documents / Care Documents для різних типів документів
• Картки документів: кожен документ показує тип (Financial POA, Trust), автора створення (Trust), версію (v1.0), статусний бейдж (Declined / Created / Approved / Generated), причину відхилення (якщо відхилено), трекінг-номер (якщо відправлено), дати створення/останньої зміни
• Кнопки дій: Preview, Download, Mark as Received, Download Signed
• Кольорове кодування статусів: червоний «Declined» з полем причини відхилення, помаранчевий «Created» з трекінг-номером, зелений «Approved», фіолетовий «Generated» з приміткою «Document has been signed»
• Фільтри: дропдаун «All» + дропдаун «All Types» для фільтрації документів

ПРОБЛЕМА

Екстрені кейси вимагають подання доказів (недієздатність, смерть). Персоналу потрібно переглядати докази, відстежувати статус подання та управляти схваленнями в кількох кейсах.

РІШЕННЯ

Я спроєктував таблицю управління доказами з комплексною фільтрацією та відстеженням статусів:

• Таб-навігація: таби Failed Wellness Checks / Evidence Review
• Колонки таблиці: Member, Submitter, Relationship, Type, Status, Submitted, Actions
• Бейджі типу: «Incapacitation» — помаранчевий контур; «Death» — червоний контур
• Бейджі статусу: «Approved» — зелений заповнений бейдж
• Фільтри: пошук учасників + кнопки Status + Type для розширеної фільтрації
• Перемикач виду: кнопка «View» для налаштування видимості колонок
• Пагінація: 10 рядків на сторінку з навігацією

ПРОБЛЕМА

Учасники надсилають фізичні документи (заповіти, POA) у Childfree Trust для обробки. Персоналу потрібно відстежувати вхідні посилки, перевіряти вміст та управляти процесами обробки документів.

РІШЕННЯ

Я спроєктував інтерфейс відстеження відправлень з картками посилок та функціоналом пошуку:

• Таб-навігація: таби Track Package / Incoming Packages
• Лічильник посилок: «Incoming Packages (583)» з показом загального обсягу
• Фільтри пошуку: «Search by tracking...» + «Search by sender...» + дропдаун сортування «Newest First»
• Картки посилок: кожна посилка показує трекінг-номер (1ZG887AA0323698640), тип документа (Trust), версію (v1.0), інформацію відправника (Teri Test, номер телефону), вартість ($24.78) і дату відправлення (Nov 26, 2025), статусний бейдж «Incoming Package»
• Кнопки дій: Preview, Download
• Консистентний лейаут карток: чистий, сканований дизайн з чіткою інформаційною ієрархією

ПРОБЛЕМА

Оператори кол-центру обробляють кілька медичних інцидентів одночасно. Їм потрібно відстежувати осіб, що звітують, імена клієнтів, статус інциденту та email-сповіщення — водночас гарантуючи, що жоден кейс не випаде з уваги.

РІШЕННЯ

Я спроєктував таблицю відстеження інцидентів з чітким управлінням статусами:

• Колонки таблиці: Reporting Individual, Client Name, Date, Time, Client Status, Incident Status, Actions
• Бейджі статусу інциденту: «Not Sent Email» у червоному контурному бейджі — миттєво показує, які інциденти не мають email-сповіщень
• Статус клієнта: текстове поле «Client status information» з поточним станом
• New Incident: фіолетова CTA-кнопка для створення нових звітів про інциденти
• Дії перегляду: eye-іконка для детального перегляду інциденту
• Пагінація: 10 рядків на сторінку з навігацією для управління 5k+ записами
• Візуальна ієрархія: чітке розділення між особою, що звітує (хто подзвонив), та ім'ям клієнта (кому потрібна допомога)

ПРОБЛЕМА

Медичні інциденти слідують складному 5-кроковому процесу. Без візуального відстеження прогресу оператори втрачають уявлення про те, які кроки завершені та що в очікуванні.

РІШЕННЯ

Я спроєктував покроковий робочий процес з візуальними індикаторами прогресу та динамічними формами:

• Хедер огляду інциденту: показує репортера, зв'язок, клієнта, госпіталь, статус підтвердження з госпіталем, мітку часу початку інциденту (Nov 26, 2025 17:10:34), кнопку «Reset Incident Data» для початку заново
• 5-кроковий візуальний прогрес: STEP 1 Reporting Individual (людина з іконкою документа), STEP 2 Client Confirmation (людина з галочкою), STEP 3 46-Hr Info (госпіталь з info-іконкою), STEP 4 Confirm with Hospital (госпіталь з галочкою), STEP 5 Notification (дзвіночок)
• Активний крок підсвічений фіолетовим контуром; завершені кроки показують зелені галочки у зведенні інциденту
• Крок 1: форма Reporting Individual — ім'я та прізвище контакту, номер телефону з прикладом формату, зв'язок з клієнтом
• Крок 2: форма Client Confirmation — ім'я та прізвище клієнта, дата народження з дейт-пікером, чекбокс «Client does not exist» для не-учасників, кнопка «Clear Client Information», текстовий блок поточного статусу, результати пошуку клієнта з фіолетовим фоном за відсутності збігів
• Крок 5: Notification — надсилання інформації в госпіталь з бейджем «Sent», маршрутизація email (FYI Only) з бейджем «Sent», інформаційний блок сповіщення з помаранчевим фоном, що пояснює: госпіталь отримує повний огляд інциденту, документи POA, медичні директиви та медичні нотатки; support email надсилається, якщо клієнт не існує в системі
• Зведення інциденту (правий сайдбар): статус завершення всіх 5 кроків, статус email (FYI Email, Hospital Email, Support Email для не-існуючого клієнта), картка вибраного клієнта з ім'ям, email, DOB, статусні бейджі: «Pending» (пісочний годинник), «Complete» (зелена галочка), «Confirm» (зелений контур), «Sent» (зелений конверт)

ПРОБЛЕМА

Медичному персоналу потрібно щодня переглядати десятки медичних POA та звітів My Care клієнтів. Без чітких візуальних індикаторів статусу та швидкої фільтрації критичні огляди затримуються.

РІШЕННЯ

Я спроєктував комплексну таблицю медичного огляду з миттєвим відстеженням статусу:

• Колонки таблиці: Client Name, Date, Time, POA Reviewed, My Care Report Reviewed, Notes, Actions
• Візуальні індикатори статусу: зелена галочка = переглянуто/завершено, червоний × = не переглянуто/відхилено
• Миттєве візуальне сканування статусу завершення по 3 критичних колонках
• Швидкі дії: eye-іконка для перегляду детальних записів клієнта
• CTA «New Report»: помітна фіолетова кнопка у правому верхньому куті для створення нових оглядів
• Чіткі інструкції: підзаголовок «Select a client, review Medical POA, and My Care Report, add notes, then Save» направляє робочий процес
• Пагінація: «Rows per page: 10» з посторінковою навігацією для управління 5k+ записами

ПРОБЛЕМА

Медичні огляди включають кілька документів (POA, Care Report) та нотатки. Без структурованого робочого процесу персонал пропускає критичні кроки або втрачає уявлення про те, що було переглянуто.

РІШЕННЯ

Я спроєктував 4-крокову форму медичного огляду з чітким розрізненням обов'язкових/необов'язкових пунктів:

• Хедер зведення медичного звіту: показує ім'я клієнта, Medical POA Reviewed (Yes/No), My Care Report Reviewed (Yes/No), Medical Review Notes (Yes/No), мітку часу дати звіту, кнопку «Reset Report»
• 4-кроковий прогрес-бар: STEP 1 Confirm Client («Required Step» — червоний бейдж), STEP 2 Review Medical POA (Optional — сірий бейдж), STEP 3 Review My Care Report (Optional — сірий бейдж), STEP 4 Add Medical Review Notes (Optional — сірий бейдж)
• Завершені кроки стають фіолетовими; обов'язковий крок позначений червоною зірочкою
• Крок 1: Confirm Childfree Trust Client (обов'язковий) — ім'я та прізвище клієнта, дата народження з дейт-пікером, кнопка «Clear Client Information», червоний бейдж «Required Step»
• Крок 2: Medical POA (лише перегляд, необов'язковий) — картка медичної інформації пацієнта зі статусом донорства органів, чекбокс «Hospital has the Medical POA», порожній стан «No medical data available»
• Крок 3: My Care Medical Report (лише перегляд, необов'язковий) — аналогічна структура, чекбокс «I have reviewed the My Care Report», порожній стан «No medical data provided»
• Крок 4: Medical Review Notes (необов'язковий) — акордеон попередніх медичних нотаток (10) з історичними нотатками: зміст, email автора, дата створення; текстова область «Add note» + кнопка; нотатки мають мітки часу та авторство для журналу аудиту

ПРОБЛЕМА

Медичному персоналу потрібно переглядати облікові записи користувачів зі статусом недієздатності, щоб пріоритезувати догляд та розуміти контекст здоров'я клієнта.

РІШЕННЯ

Я спроєктував таблицю управління користувачами, адаптовану для робочого процесу медичного огляду:

• Сайдбар: Medical Review (основний) + Users, Settings, Help, Log out
• Колонки таблиці: Name, Email, Incapacitation Status, Actions
• Бейджі статусу: «Incapacitated» — червоний контур (потрібна негайна медична увага); «Not Incapacitated» — нейтральний сірий контур
• Фільтри та пошук: фільтр користувачів, ім'я/email + кнопка «Incapacitation Status»
• Перемикач виду та оновлення: консистентно з іншими ролями
• Three-dot меню: для додаткових дій по кожному користувачу

ПРОБЛЕМА

Під час огляду конкретного клієнта медичному персоналу потрібна повна картина: інциденти, звіти, сповіщення та історичні нотатки — все в одному місці.

РІШЕННЯ

Я спроєктував комплексну сторінку медичної інформації індивідуального користувача зі стат-картками та табованим контентом:

• Хедер форми подання доказів: «Please provide the required information and upload the necessary documentation», кнопка «Back to Users» для навігації
• 3 стат-картки: Medical Incidents: 0 (червона іконка тривоги) — «Total incidents reported»; Medical Reports: 1 (зелена іконка плюса) — «Total reviews completed»; Notifications Sent: 0 (фіолетова іконка пошти) — «Incidents with notifications»
• Таб-навігація: Medical Incidents (0) / Medical Reports (1) — активний таб фіолетовий
• Картка медичного звіту (для Bessie Cooper): хедер «Medical Review for Bessie Cooper» з іконкою плюса, статусні бейджі «POA Reviewed: ✓» та «Care Report Reviewed: ✓», дата створення Nov 22, 2025 19:24:00
• Секція Client Information: Name, Email, Date of Birth, Phone
• Секція Review Status: «Medical POA» ✓, «Care Report» ✓ (зелені бейджі)
• Previous Medical Notes (2): розгортувана секція з історичними нотатками: email автора та дата створення

ПРОБЛЕМА

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

РІШЕННЯ

Я спроєктував консистентні, багаті на дані таблиці у всіх модулях:

• Консистентні патерни таблиць: однакова структура колонок, пагінація та іконки дій у всіх модулях
• Сортовані колонки: колонки дати, часу, імені та статусу для швидкої фільтрації (позначені стрілками ↑↓)
• Підсвітка рядків: hover-стани та індикатори вибраного рядка для чіткості
• Кольорове кодування статусів: зелений (завершено/схвалено/переглянуто), червоний (незавершено/відхилено), помаранчевий (в очікуванні) — універсально у всіх модулях
• Контролі пагінації: «Showing 1 to 10 of 5k entries» з налаштовуваною кількістю рядків на сторінку (10/25/50)
• Колонка швидких дій: eye-іконка для перегляду, three-dot меню для додаткових дій — консистентно у всіх таблицях

ПРОБЛЕМА

В екстрених ситуаціях (клієнт без свідомості, госпіталізований) персоналу Welon Trust потрібен миттєвий доступ до юридичних документів, медичних директив та POA — але система також повинна підтримувати сувору безпеку та журнали аудиту.

РІШЕННЯ

Я спроєктував безпечну, швидку систему доступу до документів:

• Дашборд швидких дій: доступ в один клік до «Access Documents» та «Submit Evidence»
• Категорії документів: юридичні документи, медичні записи, судові накази, POA, звіти про догляд
• Функціонал завантаження: drag-and-drop або файловий пікер для додавання нових документів
• Подання доказів: структурована форма для запитів екстреного доступу з обов'язковими полями
• Журнал аудиту: відстеження міток часу для всіх доступів до документів та завантажень
• Бейджі безпеки: чіткі візуальні індикатори конфіденційності документів та дозволів доступу