Digna | Matt Staniszewski

Menopauza to proces rozciągnięty na lata, nie jednorazowa wizyta. Kobiety, które przez to przechodzą, potrzebują stałej opieki opartej na relacji: bezpośredniego kontaktu ze specjalistką, która zna ich historię, zamiast rotacyjnego grafiku lekarzy rodzinnych czy ogólnej platformy telemedycznej. Klinika Digna to warszawska praktyka ginekologiczna specjalizująca się w opiece nad kobietami w okresie menopauzy, która potrzebowała cyfrowego produktu na poziomie jakości opieki, jaką zapewniała już na miejscu.

Digna to aplikacja dla pacjentek, którą dla nich zbudowaliśmy: jedno miejsce do zarządzania całą relacją z ginekolożką. Kompletna ścieżka pacjentki (rezerwacja, konsultacja wideo, dokumenty, wiadomości i wyselekcjonowana baza wiedzy) przeszła od briefu do działającej aplikacji w trzy dni.

Moja rola

Prowadziłem ten projekt od początku do końca dla Kliniki Digna, obejmując cały zakres: zdefiniowanie architektury informacji, przełożenie marki Digna na język wizualny aplikacji, rozbudowanie ich systemu projektowego i zaprojektowanie wszystkich 25 ekranów. Projekt zaczął się warsztatem odkrywczym z właścicielem Kliniki Digna, na którym zmapowaliśmy ścieżkę pacjentki, zidentyfikowaliśmy kluczowe przypadki użycia i uzgodniliśmy priorytety. Z tego warsztatu powstał koncept UX, uporządkowany dokument obejmujący architekturę informacji, flow użytkowniczki i kluczowe decyzje projektowe, który stał się podstawowym briefem przekazanym Claude Code do implementacji. Był to też eksperyment z projektowaniem i rozwojem wspieranym przez AI: przez cały proces budowy Claude Code działał jako partner kreatywny i techniczny.

Zrozumienie użytkowniczki

Pacjentka: Marta to zajęta profesjonalistka pod pięćdziesiątkę, która od dwóch lat leczy się u dr Anny Kowalskiej w Klinice Digna, ginekolożki specjalizującej się w menopauzie. Chce rezerwować wizyty kontrolne bez dzwonienia do recepcji, sprawdzać recepty po wizycie i pisać do lekarki między wizytami, kiedy ma szybkie pytanie. Wszystko robi z telefonu i oczekuje, że będzie to równie dopracowane jak aplikacje, z których już korzysta. Niejasny flow albo chłodny, kliniczny interfejs natychmiast zniszczy jej zaufanie.

Projektowanie dla Marty oznaczało projektowanie poczucia pewności. Każdy ekran musiał być ciepły, jasny i szanować jej czas.

Kontekst

Digna jest pierwszą w Polsce internetową kliniką skoncentrowaną wyłącznie na opiece w okresie menopauzy, uznaną przez Forbes Women za jeden z 25 startupów femtech w Polsce i opisaną w magazynie Charaktery. Ta pozycja ma znaczenie: rynek opieki w okresie menopauzy jest bardzo specyficzny i notorycznie zaniedbany. Większość kobiet przechodzących przez perimenopauzę lub menopauzę trafia na rozdrobniony system: lekarza rodzinnego, który leczy każdy symptom z osobna, skierowania do kilku specjalistów i brak ciągłości między wizytami. Digna została zbudowana, by zastąpić to rozdrobnienie jedną, ciągłą relacją opieki. Interdyscyplinarny zespół kliniki obejmuje ginekologię, psychologię, dietetykę, dermatologię i medycynę wewnętrzną, wszystko dostępne w ramach jednego abonamentu. Symptomy takie jak uderzenia gorąca, nocne poty, zaburzenia snu, wahania nastroju i zmiany hormonalne wymagają skoordynowanego zarządzania, nie pojedynczych wizyt, i cały model produktu to odzwierciedla.

Głos i ton. Marka Digna jest ciepła, bezpośrednia i bardzo osobista. Nagłówek na ich stronie brzmi: "Jesteśmy tu, aby zaopiekować się Tobą na każdym etapie menopauzy". Pacjentka jest traktowana na "Ty", nieformalnie, blisko. Nigdy klinicznie, nigdy urzędowo. Treści w całej aplikacji są jednocześnie wspierające i eksperckie, taki ton, przy którym pacjentka czuje się zaopiekowana i w dobrych rękach. Ten głos był punktem odniesienia dla każdej interakcji i każdej etykiety w aplikacji: tekstów onboardingu, potwierdzeń rezerwacji, interfejsu czatu, nawet stanów pustych.

Użytkowniczka końcowa. Z tej aplikacji korzystają kobiety, które zauważają pierwsze sygnały perimenopauzy albo są już w trakcie menopauzy: nieregularne cykle, uderzenia gorąca, problemy ze snem, wahania nastroju, bóle stawów. Wiele z nich trafia tu po wizycie u lekarza rodzinnego, który leczył poszczególne symptomy, nie docierając do hormonalnej przyczyny. Szukają specjalistki, która zna ich pełną historię, bezpośredniego kontaktu, gdy między wizytami pojawi się pytanie, i sposobu na zarządzanie swoją opieką bez kolejek telefonicznych i poczekalni. Oczekują, że aplikacja będzie tak dopracowana jak każdy inny konsumencki produkt, z którego już korzystają.

Brief produktowy dodał do tego kilka sztywnych ograniczeń: mobile-first, język polski w całej aplikacji z poprawną terminologią medyczną, wyłącznie konsultacje wideo i model abonamentowy, w którym konsultacje pochodzą z pakietu. Te warunki trzymały zakres w ryzach i utrzymywały ostrość całego doświadczenia.

Analiza i główny flow aplikacji

Przed zaprojektowaniem pierwszego ekranu przeanalizowałem, jak porównywalne aplikacje rozwiązują te same problemy strukturalne. Przyjrzałem się Doctolib pod kątem modelu rezerwacji wizyt i tego, jak balansuje gęstość informacji z przejrzystością; Flo pod kątem tego, jak produkt z zakresu zdrowia kobiet organizuje bieżące dane zdrowotne i podaje edukację bez przeciążania użytkowniczki; Ada Health pod kątem architektury informacji skoncentrowanej na pacjentce; i Teladoc pod kątem tego, jak produkt telemedyczny obsługuje relację między terminarzem, konsultacją i follow-upem. We wszystkich czterech przypadkach aplikacje zdrowotne, które zdobywają zaufanie, stawiają najważniejszą akcję i najistotniejszy kontekst na pierwszym planie, bez zmuszania użytkownika do szukania.

Ta analiza wpłynęła prosto na ekran główny. Najpilniejsze pytanie Marty za każdym razem, gdy otwiera aplikację, to "co mnie czeka?". Dlatego karta z najbliższą konsultacją zakotwicza górę dashboardu. Pod nią wyselekcjonowane artykuły i polecenia od jej lekarki służą dwóm celom: wydłużają relację między wizytami i pozycjonują Klinikę Digna jako kompetentną przewodniczkę i narzędzie do rezerwacji. Dobre rozwiązanie tego na ekranie głównym oznacza, że Marta ma powód, by otworzyć aplikację, nawet gdy nie ma zaplanowanej wizyty.

Dolna nawigacja, nie hamburger. Menu hamburgerowe z definicji chowa nawigację. Każda funkcja za nim jest funkcją, którą użytkowniczka musi aktywnie odkryć, a nawigacja schowana za menu notuje zwykle dużo mniejsze zaangażowanie niż elementy wystawione na trwałym pasku. Dla aplikacji, w której pięć głównych miejsc (Strona główna, Wizyty, Dokumenty, Czat i Profil) musi być równie dostępnych, dolny pasek zakładek jest właściwym wyborem. Leży w zasięgu kciuka na każdym telefonie, jest zawsze widoczny i całkowicie usuwa obciążenie poznawcze typu "gdzie jest to, czego szukam?". Umieszczenie Dokumentów w głównej nawigacji oznacza, że pacjentka sprawdzająca receptę po wizycie trafia do niej jednym dotknięciem, zawsze. Danie Czatowi równej wagi sygnalizuje, że asynchroniczne wiadomości to kanał pierwszej kategorii, nie coś dorzuconego na końcu.

Ta sama aplikacja na każdym urządzeniu. Digna jest zbudowana jako Progressive Web App, więc działa w przeglądarce na telefonach, tabletach i komputerach bez osobnej bazy kodu. Układ się adaptuje: szerokości kart, odstępy i gęstość treści reagują na dostępny viewport, ale model interakcji nie. Ta sama dolna nawigacja, te same obszary dotyku, ta sama hierarchia informacji, niezależnie od tego, czy Marta jest na telefonie w poczekalni, czy na laptopie w domu. Spójność ma tu znaczenie, bo zaufanie do produktu zdrowotnego częściowo wynika z przewidywalności: aplikacja zachowuje się tak, jak się tego oczekuje, zawsze, na każdym urządzeniu.

Flow rezerwacji

Flow rezerwacji został zaprojektowany, by zminimalizować odległość między decyzją i potwierdzeniem. Z punktu widzenia UX struktura dwustopniowa (wybór terminu, potem przegląd i potwierdzenie) odpowiada bezpośrednio dwóm krokom myślowym, przez które przechodzi użytkowniczka: "kiedy chcę przyjść?", a potem "czy wszystko jest poprawne, zanim to potwierdzę?". Zredukowanie tego do mniejszej liczby kroków ryzykuje, że pacjentka przeoczy istotne szczegóły; dodanie kolejnych kroków wprowadza niepotrzebne tarcie w akcji, która w gruncie rzeczy jest prosta. Wcześniejsza wersja prosiła o wybór między formatem wideo i audio przed dotarciem do kalendarza, trzeci krok z decyzją, która nie miała realnej odpowiedzi, bo wszystkie konsultacje i tak są wideo. Usunięcie go zmniejszyło tarcie bez usuwania czegokolwiek wartościowego.

Widok kalendarza prezentuje dostępność w formacie, który użytkowniczki znają już z każdego innego systemu rezerwacji, z jakiego korzystały, model myślowy, który nie wymaga instrukcji. Niedostępne daty są wizualnie wygaszone, nie usunięte, co daje poczucie pełnego obrazu bez dezorientacji. Dane na każdym kroku są podawane w narastającym porządku szczegółowości: najpierw data i godzina (decyzja główna), potem na ekranie potwierdzenia pełny kontekst: imię i nazwisko lekarki, format, czas trwania i wykorzystywany kredyt z abonamentu. Ta warstwowość odzwierciedla to, jak użytkownicy faktycznie myślą: najpierw wybierz, potem zweryfikuj.

Ekran końcowy celowo oferuje kilka dalszych ścieżek. Po potwierdzeniu rezerwacji intencja użytkowniczki może pójść w kilku kierunkach: wrócić do ekranu głównego, żeby zobaczyć wizytę w kontekście, przejść do listy wizyt, dodać termin do kalendarza albo zacząć rozmowę z lekarką przed wizytą. Pokazanie tylko jednej opcji, jednego przycisku "Gotowe", wymusza dodatkowy krok nawigacji, żeby dotrzeć tam, gdzie pacjentka faktycznie chce iść dalej. Zaproponowanie najbardziej prawdopodobnych kolejnych akcji prosto na ekranie potwierdzenia trzyma się podstawowej zasady UX: zmniejszaj liczbę kroków do następnej znaczącej akcji i pozwól użytkowniczce wybrać własną ścieżkę, zamiast kierować ją do arbitralnie wybranego miejsca. Oba kroki dają też dwa sposoby wyjścia: strzałkę powrotu, która wraca o jeden krok, i przycisk ×, który wraca prosto do Wizyt, bo ktoś, kto otworzył flow rezerwacji przez przypadek, potrzebuje łagodnego wyjścia, nie pułapki.

Projekt wizualny

Strona Digna wyznacza jasny brief wizualny: ciepła terakota jako kolor marki, kremowo-białe tła zamiast klinicznej bieli, okrągłe kadry na portretach lekarek i fotografie pacjentek pokazujące aktywne, pewne siebie kobiety w naturalnych sytuacjach, a nie sterylne zdjęcia stockowe. Całość czyta się jak produkt konsumencki premium, nie portal medyczny. Aplikacja została zbudowana tak, by przenieść tę identyfikację bezpośrednio w kontekst cyfrowy. Pełny materiał referencyjny Digna został przekazany modelowi AI na początku budowy, więc decyzje kolorystyczne, podejście do fotografii i sposób układania treści przeniosły się ze strony do produktu bez strat.

Typografia i język komponentów. Całą aplikację nosi dwa kroje: wyrafinowany szeryf w nagłówkach, który sygnalizuje ekspertyzę, i Inter we wszystkich tekstach interfejsu i treściach. Karty mają szeroki border radius, który wpisuje się w miękkość konsumenckich aplikacji; elementy interaktywne sygnalizują swój stan przez subtelne zmiany: wyciszoną zmianę koloru, odznakę statusu, którą rozpoznasz na pierwszy rzut oka. Te decyzje zrealizowała biblioteka komponentów, którą model AI zmontował i zaadaptował z istniejącego systemu projektowego Digna, rozszerzając go, by objąć wszystkie 25 ekranów, a nie generując komponenty od zera.

Projektowanie z AI

Ten projekt został zbudowany z Claude Code jako AI pair programmerem, w modelu pracy, w którym definiowałem intencję, przeglądałem wynik i kierowałem iteracją z poziomu produktu i designu, nie pisząc ręcznie każdej linii kodu.

Zadziałało dlatego, że język projektowy był w pełni domknięty, zanim powstał pierwszy ekran. Każdy kolor, radius, wartość odstępu i decyzja typograficzna były zapisane jako design token, zanim zaczęła się implementacja. To dało AI wspólne słownictwo do pracy i sprawiło, że decyzje projektowe przechodziły bez strat z koncepcji do komponentu.

Proces miał cztery naturalne fazy: ustalenie fundamentów i głównych komponentów; zbudowanie wszystkich 25 ekranów w kolejności flow; systematyczne dopracowywanie, gdy aplikacja już działała w przeglądarce; i finalny przebieg polerowania skoncentrowany na postrzeganej jakości, dopracowaniu odstępów i dociągnięciu małych detali.

Praca z agentem AI jest szybka właśnie dlatego, że pierwszy przebieg z definicji ma być niedoskonały. Liczy się cykl iteracji, a to, że wszystko było udokumentowane, oznaczało, że każdy cykl był produktywny, nie eksploracyjny.

Rezultat

25 ekranów obejmujących całą ścieżkę pacjentki: logowanie, onboarding, rezerwację, sprawdzenie przed połączeniem, konsultację wideo, feedback po wizycie, skrytkę dokumentów, czat, bazę wiedzy i zarządzanie profilem. Zaprojektowane, zbudowane i wdrożone jako działająca aplikacja w trzy dni.

Czego się nauczyłem. Domknięcie systemu projektowego przed dotknięciem pierwszego ekranu było najważniejszą decyzją, jaką podjąłem. Kiedy język wizualny jest ustalony wcześniej, każda kolejna decyzja jest szybsza, bardziej spójna i łatwiejsza do przekazania, czy to developerowi, AI, czy tobie samemu za sześć miesięcy.

Co dalej. Integracja z backendem, realne wideo przez dostawcę WebRTC, powiadomienia push na przypomnienia o wizytach i nowe wiadomości oraz recepty do pobrania w PDF. Fundamenty są już gotowe.

Cała aplikacja jest już dostępna online. Zarezerwuj konsultację, przejrzyj skrytkę dokumentów, wyślij wiadomość, przejdź przez flow połączenia wideo. Logowanie nie jest potrzebne, by to zbadać.

To prawdziwa aplikacja. Śmiało, sprawdź ją.