Projektowanie pakietu platform badawczych dla R&D farmaceutycznego

TL;DR

• Kontekst: ~5,5 roku jako UX lead w dziale R&D globalnej firmy farmaceutycznej.
• Problem: Plany badań i wyniki żyły w Wordzie i Excelu — nieprzeszukiwalne, nieporównywalne między badaniami, znikające razem z autorem.
• Co zrobiłem: Zaprojektowałem narzędzie do planowania badania + moduł list zadań dla laboratorium, oraz nową platformę analizy i metaanalizy.
• Wynik: Planowanie badania ~2 tygodnie → kilka dni (~70% szybciej); raport badawczy ~3–5 dni → kilka godzin.

Diagnoza

Przez lata wiedza naukowa żyła tu w dokumentach — plany badań w Wordzie, dane w Excelu, wykresy wklejane ręcznie do raportów. Nie dało się jej przeszukiwać, porównywać między badaniami ani przekazać dalej do kolejnej pracy. Obie platformy w tym case study atakują tę samą istotę problemu: zamianę wiedzy badawczej z dokumentów w ustrukturyzowane dane, które organizacja może reużywać.

flowchart LR
    A["Zaplanuj badanie"] --> B["Auto-lista zadań dla labu"]
    B --> C["Przeanalizuj wyniki"]
    C --> D["Metaanaliza między badaniami"]

    classDef neutral fill:#f0f0f1,stroke:none,color:#3f3f46,rx:14,ry:14
    class A,B,C,D neutral
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

Co zrobiłem

• Prowadziłem UX portfela platform badawczych obejmujących całą drogę naukowca: zaplanuj badanie → wygeneruj listę zadań dla labu → przeanalizuj wyniki → zrób metaanalizę między badaniami.
• Zaprojektowałem od zera dwa nowe narzędzia w istniejącej bazie badań: narzędzie do planowania badania i auto-generowaną listę zadań dla laboratorium, która z niego wynika.
• Zaprojektowałem nową platformę analizy i metaanalizy, która zastąpiła ręczny workflow Excel–kalkulator–Word.
• Zarządzałem pulą ~15 kontraktorów UX — rekrutacja i dopasowanie ich do projektów w portfelu.

Wyniki

• Skróciłem czas planowania badania z ~2 tygodni do kilku dni (~70% szybciej).
• Przeniosłem plany badań i wiedzę z analiz z rozproszonych dokumentów do ustrukturyzowanego, przeszukiwalnego systemu (zatrzymanie wiedzy).
• Doprowadziłem narzędzie do planowania do dojrzałości wystarczającej, by przekazać je wewnętrznie zrekrutowanemu następcy (jesień 2019), gdy przechodziłem w bardziej strategiczną rolę portfelową.
• Przy starcie przyjęte przez ~50 naukowców w dwóch obszarach badawczych, zaprojektowane do skalowania na kolejne domeny.
• Skróciłem czas tworzenia raportu badawczego z ~3–5 dni ręcznej pracy do kilku godzin na kilka raportów (rząd wielkości). Wcześniej naukowcy składali raporty ręcznie w dokumentach; stare narzędzie analizy było kalkulatorem bez pamięci — po zamknięciu praca znikała.
• Zamieniłem ten bezpamięciowy kalkulator w playground: naukowiec może odpalić wiele analiz z różnymi parametrami i wszystkie zachować, potem iterować warianty i wybrać najlepszy — sposób pracy, który wcześniej po prostu nie był możliwy.
• Sprawiłem, że znajdowanie i porównywanie przeszłych badań stało się natychmiastowe (wyszukiwanie po ustrukturyzowanych danych) na bazie liczącej setki, a nawet tysiące badań. Wcześniej znalezienie porównywalnego badania było niemal niemożliwe, więc niektóre po prostu powtarzano zamiast je znaleźć.
• Metodologia analizy, którą moi współpracownicy rozwinęli na tych narzędziach, została opublikowana w recenzowanym czasopiśmie onkologicznym (dziesiątki cytowań). (Pełne cytowanie w wariancie prezentacyjnym — pominięte tu dla anonimizacji.)

Problem

Jak wyglądało planowanie badania?

Plany badań były pisane w dokumentach, jako nieustrukturyzowany tekst — a nie jako dane. Oznaczało to, że planu nie dało się przeszukać, porównać z przeszłymi badaniami ani przekuć w nic wykonalnego dalej. Planowanie było wolne i żyło w prozie.

Planowanie działa też na dwóch zegarach naraz, co jest prawdziwym źródłem złożoności:

• Czas badania (study time) — nauka jest zdefiniowana w dniach badania: kiedy ważyć osobniki, podawać lek, pobierać krew.
• Czas kalendarzowy/labowy (calendar time) — laboratorium działa w realnych datach: sprzęt, ludzie, sloty w placówce. Na dodatek badanie ma kohorty (grupy osobników startujące w różnym czasie) i cykliczność (pomiary, które się powtarzają). Godzenie punktów czasowych badania z realną dostępnością kalendarzową — między kohortami i cyklami — było wolne i podatne na błędy, dopóki żyło w dokumencie Word.

A analiza wyników?

Raporty były budowane ręcznie w Wordzie. Naukowcy zbierali dane ręcznie do Excela, potem używali narzędzia online, które działało jak kalkulator bez pamięci — przeanalizowane dane nie były nigdzie zapisywane, więc wykresy i analizy trzeba było pobierać i ręcznie wklejać do dokumentów.

Największy ból biznesowy to znajdowanie i porównywanie przeszłych badań: każde badanie niosło tylko ograniczone metadane, więc znalezienie pracy o podobnych parametrach było niemal niemożliwe. Nowy system musiał zbierać ustrukturyzowane dane i umożliwić ich przeszukiwanie.

Moja rola / zakres

• UX lead portfela. Narzędzie do planowania było w całości moje — nadawałem kierunek od pierwszego dnia. Platformę analizy projektowałem jako lead.
• Kierowałem ~2–3 kontraktorami pracującymi nad istniejącym systemem, w ramach puli ~15 kontraktorów zarządzanej przeze mnie w portfelu.
• Współpracowałem głównie z naukowcami (ludźmi prowadzącymi i analizującymi badania) i dev teamem, w którym siedzieli biostatystycy — ludzie znający statystykę pracowali z ludźmi budującymi oprogramowanie, nie w osobnym silosie. Platforma analizy działała na R Shiny z autorskim frontem Bootstrap (plus Angular dla interaktywnego gridu wykresów).

Proces

• Ciągłe pętle badawcze: wywiady z naukowcami → prototypowanie → testowanie → zbieranie feedbacku — powtarzane w trakcie. Głównie zdalnie, ale też on-site z zespołem badawczym w USA.
• Platforma analizy: badania UX codziennej pracy naukowców ujawniły dwa główne problemy (ręczne raporty; wyszukiwanie/porównywanie). Następnie pracowałem z developerami nad nową architekturą — stary „kalkulator” musiał zniknąć, żeby dane mogły żyć w systemie.

Kluczowe decyzje i trade-offy

• Uniwersalność między domenami naukowymi. Narzędzie służyło obszarom o bardzo różnych wymaganiach — badania nad rakiem, neurologia i inne — więc musiało być na tyle elastyczne, by dopasować się do każdej domeny, zamiast być zaszyte pod workflow jednego obszaru. (Ta sama zasada napędzała uniwersalny moduł analizy — elastyczność jest wspólną nicią obu platform.)
• Badanie jako główna encja. Jedno badanie = jedna instancja w systemie, ale może trzymać wiele dokumentów analizy, bo kilku naukowców korzysta z wyników tego samego badania i każdy analizuje inne parametry. (Mocna decyzja IA.)
• Trzymaj surowe dane, oznaczaj wykluczenia. Zasada czyszczenia danych: zawsze zachowuj oryginalny zbiór i wyraźnie oznaczaj, co jest wykluczone i dlaczego (stary system dołączał i surowe, i opracowane dane bez jasnego zapisu wykluczeń). Ekran wykluczeń pozwala ułożyć dane po osobach/dniach/grupach, wykluczyć pojedyncze punkty lub masowo, i generuje podsumowanie, by inni mogli przejrzeć, co usunięto i dlaczego.
• Uniwersalny moduł analizy. Analizy musiały służyć wielu działom. Flow: wybierz wskaźnik (np. waga osoby badanej, wyniki krwi) → wybierz badanie → ustaw parametry; wiele analiz z różnymi parametrami można ułożyć na gridzie.
• Nieregularny grid wykresów (małe wielokrotniki o nierównych osiach). Ułóż analizy w grid — wiersze = leki, kolumny = dawki — a każdy lek ma inny zestaw dawek. Grid nie może być regularny; układ musi przyjąć tę nierównomierność. Rozwiązanie tego było największą wygraną czytelności po stronie analizy.

• Builder raportu w stylu Notion — swobodny układ tekstu z elementami analizy wstawianymi w treść.
• Metaanaliza od zera — „warstwy porównań”. Ten moduł wcześniej nie istniał; badania porównywano ręcznie. Trudna część to mapowanie grup badawczych między badaniami, bo każde badanie numeruje grupy inaczej. Rozwiązanie: naukowiec najpierw definiuje warstwy porównań (najczęściej lek + dawka), potem dla każdej warstwy wybiera z dropdowna, która grupa w każdym badaniu do niej należy (w bad.1 to grupa 2, w bad.2 grupa 6, w bad.3 grupa 3). Proste, skuteczne, jasne. Reszta flowu (czyszczenie danych → playground analiz → raport) reużywa główną platformę.

flowchart LR
    A["Badanie 1<br/>grupa 2"] --> W["Warstwa porównań<br/>lek + dawka"]
    B["Badanie 2<br/>grupa 6"] --> W
    C["Badanie 3<br/>grupa 3"] --> W

    classDef info    fill:#e9eff8,stroke:none,color:#1e3a5f,rx:14,ry:14
    classDef accent  fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
    class A,B,C info
    class W accent
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

• Model dual-time (narzędzie planowania) — a najtrudniejsza część to nie same dwa zegary, ale pogodzenie kalendarza badania z kalendarzem codziennego życia. Laboratorium obsługują normalni ludzie — święta i braki kadrowe w niektóre dni — więc zdarzenie zdefiniowane w czasie badania (np. „pobranie krwi w dniu 50”) mogło wypaść w dzień, kiedy lab po prostu nie pracuje. Zamiast auto-rozwiązywać te kolizje wobec przepustowości laboratorium (zbyt splątane, zbyt ludzkie), daliśmy laborantom widok kalendarzowy zdarzeń, żeby widzieli, co ląduje na święcie lub dniu z brakiem, i mogli to obsłużyć. Transparentność zamiast automatyzacji.

flowchart TD
    S1["Czas badania<br/>dzień 50: pobranie krwi"] --> X{"Kolizja z kalendarzem laba?"}
    C1["Czas kalendarzowy<br/>realna data to święto"] --> X
    X -->|"tak"| V["Widok kalendarzowy dla laborantów<br/>transparentność, nie auto-rozwiązywanie"]
    X -->|"nie"| Y["Zdarzenie zaplanowane normalnie"]

    classDef info    fill:#e9eff8,stroke:none,color:#1e3a5f,rx:14,ry:14
    classDef good    fill:#e6f2ea,stroke:none,color:#1f4d33,rx:14,ry:14
    classDef accent  fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
    class S1,C1 info
    class X info
    class Y good
    class V accent
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

• Hand-off. Jesień 2019 — przeszedłem w bardziej strategiczną rolę portfelową i przekazałem narzędzie planowania wewnętrznie zrekrutowanemu następcy; proces był wtedy na tyle określony, że zostało dla niego niewiele pracy koncepcyjnej.

Jak to się skończyło

• Strona analizy przeniosła budowanie raportu z ~3–5 dni ręcznej pracy do kilku godzin na kilka raportów i zamieniła bezpamięciowy kalkulator w playground, gdzie naukowcy iterują warianty zamiast liczyć jednokrotnie.
• Najsilniejszy sygnał popytu: po zobaczeniu platformy analizy zespół neurologii poprosił o adopcję jako następny — narzędzie sprzedało się samo w organizacji.
• Po stronie planowania: ~70% szybsze planowanie badania; wiedza planistyczna wyszła z dokumentów do systemu.

Co z tego wyniosłem

• Projektuj pod nierównomierną złożoność. Realne dane naukowe nie leżą w równych macierzach — jeden lek ma trzy dawki, następny trzy inne. Design musi przyjąć tę nierównomierność, a nie wymuszać jednorodność.
• „Szybciej” nie było prawdziwą wygraną — nowy sposób pracy tak. Największa zmiana to nie skrócenie czasu raportu; to zamiana jednokrotnego kalkulatora w trwały playground, gdzie naukowcy mogli iterować warianty wcześniej niemożliwe.
• Wbuduj ekspertów domenowych w budowanie. Biostatystycy siedzieli w dev teamie. Gdy ludzie znający matematykę siedzą z ludźmi piszącymi kod, analiza jest po prostu poprawna.
• Uniwersalność jako ograniczenie, nie feature. Obsługa badań nad rakiem i neurologii naraz wymusiła system parametryczny zamiast zaszytego workflow — co zrobiło narzędzie reużywalne w domenach, do których nie było pierwotnie budowane.