Записатись до лікаря.
У країні, де це інша мова.
Book a doctor.
In a country where that's a different language.
BookMD — вебплатформа для запису до лікаря у США. Я долучилась на стадії ідеї і провела весь дизайн-цикл: від перших інтерв'ю до файлів, які пішли в розробку. BookMD is a web platform for booking doctors in the US. I joined at the idea stage and ran the full design cycle: from first interviews to files that went into development.
Не «намалювати екрани», а зібрати продукт, якого ще не було. Not "draw screens", but build a product that didn't exist yet.
Стартап, ринок США, медицина. Команда розробників сиділа і чекала. Мокапів не було, дизайн-системи не було, навіть карти потоків не існувало. Була ідея: дати людині нормальний спосіб записатися до лікаря онлайн — без телефону, без черги, без сюрпризів зі страховою. Startup, US market, healthcare. The dev team was waiting. No mockups, no design system, no flow map. Just an idea: give people a decent way to book a doctor online — no phone, no queue, no insurance surprises.
Я взяла на себе всі стадії: дослідження, інформаційну архітектуру, вайрфрейми, прототип, UI, дизайн-систему, специфікацію і підтримку під час розробки. Без суміжного дизайнера. Без попереднього досвіду у регульованій галузі іншої країни. I took on every stage: research, information architecture, wireframes, prototype, UI, design system, specifications, and development support. No co-designer. No prior experience in a regulated industry in another country.
Три речі, які треба було розібрати до того, як малювати екрани. Three things to figure out before drawing any screens.
Я не з американської системи охорони здоров'я. Користувачів, які вже записувались через нашу платформу, ще не існувало — ми тільки її будували. А продукт мав із першого дня працювати на двох поверхнях. Це не три окремих ризики, це один великий: кожне дизайн-рішення легко могло бути побудоване на здогадці. I'm not from the American healthcare system. The users who'd eventually book through our platform didn't exist yet — we were building it. And the product had to work on two surfaces from day one. Not three separate risks, one big one: any design decision could easily be built on a guess.
Незнайома екосистема. Терміни типу provider, copay, in-network — це не переклад, це інша модель мислення. Зрозуміти, як страхова мережа впливає на вибір лікаря, треба було до того, як з'явиться перший фільтр. Unfamiliar ecosystem. Terms like provider, copay, in-network aren't translation problems — they're a different mental model. Understanding how an insurance network shapes doctor selection had to come before the first filter.
Широка аудиторія. Від людей з iPhone-навичками до тих, для кого смартфон — вже стрес. Доступність із першого дня означала не «додамо потім», а закладений у систему контраст, розмір тексту, стани фокуса і зрозумілі помилки. Wide audience. From people with iPhone habits to those for whom a smartphone is already stressful. Accessibility from day one meant not "we'll add it later" — it meant contrast, text size, focus states, and clear errors baked into the system.
Дві платформи паралельно. Не два окремі файли, а одна логіка з правилами адаптації. Розробка не могла чекати, поки буде «спершу веб, потім мобайл». Two platforms in parallel. Not two separate files, but one logic with adaptation rules. Development couldn't wait for "web first, then mobile".
Людина не шукає лікаря.
Вона шукає відповідь: можна вже записатись? People aren't looking for a doctor.
They're looking for an answer: can I book now?
Це звучить очевидно, але змінює сторінку лікаря повністю. Якщо людина бачить ціну, відгуки, освіту, страхові і десять кнопок одночасно — вона не вибирає, вона перевантажується. Той, хто записує через додаток, хоче перевірити три речі: доступний час, страхова мережа, рейтинг. Решта інформації потрібна, але не зараз. Obvious in theory, but it changes the doctor page entirely. If someone sees price, reviews, education, insurance, and ten buttons at once — they don't choose, they freeze. Someone booking through the app wants to check three things: available time, insurance network, rating. The rest matters, just not right now.
П'ять етапів, кожен починався тоді, коли попередній відповідав на питання, яке не можна було обминути. Five stages, each starting when the previous one answered a question that couldn't be skipped.
Research & Kickoff
Прямого доступу до користувачів не було. Робили з тим, що мали. No direct access to users. We worked with what we had.
На MVP зазвичай немає бюджету на класичне дослідження з рекрутом пацієнтів у США. Я зібрала дані з трьох інших джерел — щоб питання архітектури не зависало в повітрі. MVP rarely has the budget for classic research with recruited US patients. I pulled data from three other sources — so the architecture question wouldn't hang in the air.
Воркшоп зі стейкхолдерамиStakeholder workshop
- Цілі продукту й пріоритети — узгодили з командою на старті.Product goals and priorities — aligned with the team from the start.
- Список того, що НЕ робимо в MVP, виявився важливішим за список того, що робимо.What NOT to build in MVP turned out more important than what to build.
- Кожен сценарій звучав від першого CEO, не з моєї голови.Every scenario came from the founding CEO, not from my own assumptions.
Конкурентний аналізCompetitive analysis
- Zocdoc, клінічні портали, телемед-платформи.Zocdoc, clinic portals, telehealth platforms.
- Що працює, де людина губиться, які UI-конвенції стали де-факто стандартом.What works, where people get lost, which UI conventions have become de facto standards.
- Не копіювали — зрозуміли межі очікувань користувача.We didn't copy — we figured out where user expectations break.
Проксі-інтерв'юProxy interviews
- Люди, які нещодавно самі шукали або бронювали прийом.People who'd recently searched for or booked an appointment themselves.
- Слухали фрустрації, паттерни поведінки, словник.Listened for frustrations, behavior patterns, vocabulary.
- Не «що б ви хотіли», а «розкажіть, як ви робили цього разу».Not "what would you want" but "tell me how you did it last time".
Що з цього вийшлоWhat came out of it
- Картина помилок: де люди відкривають 4–5 вкладок і здаються.Map of failures: where people open 4–5 tabs and give up.
- Розуміння: фільтри в індустрії побудовані під клініку, а не під людину.Realization: industry filters are built for the clinic, not the person.
- Перший інсайт, який задав напрямок: «можна вже записатись?» — головне питання.First insight that set the direction: "can I book now?" — the core question.
~16 × 9
Як це позначилось на продуктіHow this shaped the product
- Перший екран мав відповідати на «коли можна?», а не «хто такий лікар».The first screen had to answer "when can I?" not "who is this doctor".
- Фільтр будувався від людини: «у мене є страхова X, мені треба Y у радіусі Z».The filter was built from the person: "I have insurance X, I need Y within Z miles".
- Словник UI з'явився не з нашої голови — з реплік на інтерв'ю.UI vocabulary came from interview transcripts, not our own assumptions.
UX Architecture
Карта потоків замість дерева екранів. Flow map instead of a screen tree.
Інформаційна архітектура у медицині — це не «де лежить кнопка». Це питання довіри: чи бачить людина, де її дані, ким керується вибір, що буде далі. Я склала карту потоків раніше, ніж екранів. Information architecture in healthcare isn't "where does the button go". It's a question of trust: whether the user sees where their data is, what drives the choice, what comes next. I mapped the flows before mapping the screens.
Пошук і фільтраціяSearch and filtering
- Страхова мережа, спеціалізація, відстань, мова, доступний час.Insurance network, specialty, distance, language, available time.
- Перший екран не показує всі фільтри одразу — лише ті, які звужують найшвидше.The first screen doesn't show all filters at once — only the ones that narrow fastest.
- Решта живуть у «More filters» і запам'ятовуються між сесіями.The rest live in "More filters" and are remembered between sessions.
Сторінка лікаряDoctor page
- Три сигнали зверху: доступний час, рейтинг, страхова мережа.Three signals at the top: available time, rating, insurance network.
- Біографія, освіта і відгуки — у згорнутому стані.Bio, education, and reviews — collapsed by default.
- Кнопка «Book» завжди в зоні досяжності великого пальця."Book" button always within thumb reach.
БронюванняBooking
- Слот → причина візиту → страхова → підтвердження. Чотири кроки, не більше.Time slot → reason for visit → insurance → confirmation. Four steps, no more.
- На кожному кроці видно, що буде далі.Each step shows what comes next.
- Скасування і перенесення — одне натискання, не лабіринт.Cancel and reschedule — one tap, not a maze.
Профіль і записиProfile and appointments
- Заплановане, минуле, скасоване — три види на одній шкалі часу.Upcoming, past, canceled — three views on one timeline.
- Документи й страхові карти — у профілі, не на бронюванні.Documents and insurance cards — in profile, not on the booking form.
- Сімейні акаунти — в архітектуру одразу, бо потім переробляти дорого.Family accounts built into the architecture from the start, because retrofitting is expensive.
~16 × 9
Принцип, на якому будувалиThe principle we built on
- Будь-яка архітектура — гіпотеза. Перевірили — залишили.Any architecture is a hypothesis. Tested — kept.
- Не перевірили — поставили чіткий запит на дослідження.Untested — turned into a research question.
- Найскладніший потік (фільтрація) переписували чотири рази, поки люди розуміли, де починати.The most complex flow (filtering) was rewritten four times before people understood where to start.
Wireframes & Testing
Два тижні на лоу-фай. Потім — людина перед ноутбуком. Two weeks on lo-fi. Then — a person in front of a laptop.
Коридорне тестування дало більше за місяць здогадок. Я навмисно не довела вайрфрейми до краси — тестували логіку, не стиль. Те, що людина не розуміє в сірих прямокутниках, потім не врятує жоден UI. Corridor testing gave us more than a month of guesses. I deliberately kept the wireframes unpolished — we were testing logic, not style. What someone doesn't understand in gray rectangles, no UI will fix later.
Що тестувалиWhat we tested
- Логіку фільтрації: чи розуміє людина, як звузити список.Filter logic: whether people understand how to narrow the list.
- Сторінку лікаря: на яких трьох сигналах зупиняється погляд.Doctor page: which three signals stop the eye.
- Бронювання: де на четвертому кроці з'являється сумнів.Booking: where doubt appears on step four.
Що показало тестуванняWhat testing showed
- На сторінці лікаря люди отримували параліч від об'єму інформації.On the doctor page, people experienced information overload.
- Коли прибрали половину елементів — рішення про запис прийшло швидше.When we removed half the elements, the booking decision came faster.
- Менше інформації не означає «менше довіри», означає «легше вирішити».Less information doesn't mean "less trust" — it means "easier to decide".
Що змінили післяWhat we changed after
- На сторінці лікаря виставили вперед: час, рейтинг, страхова.Doctor page now leads with: time, rating, insurance.
- Біографію згорнули, відгуки винесли в окрему вкладку.Bio collapsed, reviews moved to a separate tab.
- Прибрали «корисне-але-зайве» з першого екрана пошуку.Removed "useful but extraneous" from the first search screen.
Що залишили на потімWhat we kept for later
- Розширені фільтри з геолокацією за замовчуванням.Advanced filters with default geolocation.
- Збережені пошуки і нагадування.Saved searches and reminders.
- Функцію «знайти схожого лікаря, якщо цей зайнятий».Feature "find a similar doctor if this one is unavailable".
16 × 10
4 × 3
4 × 3
UI & Design System
Не «зробили красиво», а зібрали систему, яку розробка не мала перепридумувати. Not "made it pretty", but built a system development didn't have to reinvent.
Дизайн-система — це не бібліотека на показ. Це угода з розробником про те, як поводиться кожен компонент у кожному стані. Я закладала в Figma не картинки, а правила. A design system isn't a showcase library. It's an agreement with the developer about how each component behaves in each state. What I was building in Figma wasn't pictures — it was rules.
Доступність із першого дняAccessibility from day one
- WCAG-контраст для всього тексту, не тільки великого.WCAG contrast for all text, not just large.
- Розмір тексту ≥ 16 px у бронюванні, фокус-стейти на всіх інтерактивних.Text size ≥ 16px in booking, focus states on all interactive elements.
- Помилки сформульовані як інструкція, не як вирок.Errors worded as instructions, not verdicts.
Токени і компонентиTokens and components
- Кольорові токени з ролями (text-default, text-mute, surface-island), а не «teal-500».Semantic color tokens (text-default, text-mute, surface-island), not "teal-500".
- Компоненти з варіантами і станами в одному місці.Components with variants and states in one place.
- Авто-лейаут на 100% — розробник не править відступи руками.100% auto-layout — developers don't adjust spacing by hand.
Веб і мобайлWeb and mobile
- Один файл, два брейкпоїнти, правила адаптації описані текстом.One file, two breakpoints, adaptation rules written in text.
- Мобайл — не «зменшений десктоп»: інша логіка великого пальця, інша глибина меню.Mobile isn't "a shrunk desktop": different thumb logic, different menu depth.
- Критичні дії дублюються в стіл, кеп або bottom sheet — там, де це доречно.Critical actions mirrored in a sticky bar, cap, or bottom sheet — where it makes sense.
Чого не робилиWhat we didn't do
- Не вигадували нових патернів там, де медичні портали в США мають усталені.Didn't invent new patterns where US medical portals have established ones.
- Не намагались «вразити» — продукт мав виглядати спокійним і надійним.Didn't try to "impress" — the product had to feel calm and trustworthy.
- Не залишали undocumented behavior — кожна анімація, кожен toast описаний.No undocumented behavior — every animation, every toast is described.
16 × 10
4 × 3
9 × 16
Handoff & Support
Здала не файли. Здала систему, яка пояснює сама себе. Didn't hand off files. Handed off a system that explains itself.
Хороший хендоф — це не «передати фігму». Це передати рішення: чому саме так, що з цим робити в edge-кейсі, як буде поводитись стан, який не намальовано окремо. Good handoff isn't "share the Figma". It's handing over decisions: why exactly this, what to do in an edge case, how a state behaves when it hasn't been drawn separately.
Що пішло в розробкуWhat went to development
- Структуровані Figma-файли: компоненти → екрани → флоу.Structured Figma files: components → screens → flows.
- До кожного екрана — нотатка з логікою рішення.Each screen with a note on the decision logic.
- Edge-кейси, що не помістились на основний макет, описані окремо.Edge cases that didn't fit the main layout are documented separately.
ДокументаціяDocumentation
- Поведінка компонента в різних станах і брейкпоїнтах.Component behavior across states and breakpoints.
- Доступність: фокус-порядок, ARIA-ролі, очікувані події.Accessibility: focus order, ARIA roles, expected events.
- Що відбувається при помилці мережі, валідації, тайм-ауті.What happens on network error, validation failure, timeout.
Підтримка під час спринтуSupport during sprints
- Я була на standup-ах, відповідала на питання, дивилась реалізацію.I was on standups, answered questions, reviewed implementations.
- Дрібні правки — день у день, не «через два спринти».Small fixes — same day, not "in two sprints".
- Якщо рішення не вмикалось у термін — пропонувала компроміс, а не вимагала ідеалу.If a solution didn't fit the timeline — I proposed a compromise, didn't demand the ideal.
Що це далоWhat this gave
- Розробка не поверталась із питаннями «а як тут має бути».Development didn't come back with "how should this be".
- Випадкові розбіжності з макетом ловились ще до code review.Unintentional deviations from the layout were caught before code review.
- CEO окремо відмітив якість документації.CEO specifically noted the quality of documentation.
Я не думаю про хендоф як про фінальний крок. Я думаю про нього з першого дня: компонент, який легко передати в розробку, — це компонент, який і дизайнерові легше тримати в голові. Документація не пишеться в кінці, вона лежить поруч із макетом. I don't think of handoff as the final step. I think about it from day one: a component that's easy to hand to development is a component that's also easier to hold in my own head. Documentation isn't written at the end — it lives alongside the mockup.
Платформу запустили. Нею користуються пацієнти і клініки. The platform launched. Patients and clinics are using it.
04
місяці до запуску — від брифу до productionmonths to launch — from brief to production
02
платформи з єдиною дизайн-системою — веб і мобайлplatforms with a single design system — web and mobile
01
дизайнер на повному циклі, без перекидання між людьмиdesigner on the full cycle, no handoffs between people
Без прямого доступу до кінцевих користувачів — і все одно близько до них. No direct access to end users — still got close.
Цей проєкт навчив мене балансувати між потребами людини, обмеженнями бізнесу і технічними реаліями — самостійно, кросфункціонально, у незнайомій і регульованій галузі. Не ідеально. Але чесно. This project taught me to balance human needs, business constraints, and technical realities — independently, cross-functionally, in an unfamiliar regulated industry. Not perfectly. But honestly.
Найважливіше — звичка не вгадувати там, де можна перевірити, навіть якщо перевірка дешевша і коротша, ніж класичне дослідження. Воркшоп, проксі-інтерв'ю, коридорний тест на п'ятьох — це теж дані. А команда, яка чекає файли, — це не привід здавати здогадку за рішення. The most important takeaway: the habit of not guessing where you can verify, even if the verification is cheaper and shorter than proper research. A workshop, proxy interviews, a five-person corridor test — that's also data. And a team waiting for files isn't a reason to hand in a guess as a decision.