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. Nie dało się ich przeszukać ani porównać, a wiedza odchodziła razem z autorem.
• Co zrobiłem: Zaprojektowałem narzędzie do planowania badania, moduł list zadań dla laboratorium i nową platformę do analizy i porównywania wyników.
• Wynik: Planowanie badania trwa kilka dni zamiast ~2 tygodni (~70% szybciej). Raport badawczy powstaje w kilka godzin zamiast ~3–5 dni.

Diagnoza

Przez lata wiedza naukowa żyła w tej organizacji w dokumentach. Plany badań były w Wordzie, dane w Excelu, a wykresy trafiały do raportów przez kopiuj-wklej. Nie dało się tego przeszukać, porównać z wcześniejszymi badaniami ani wykorzystać w kolejnej pracy. Obie platformy z tego case study rozwiązują więc ten sam problem: zamieniają dokumenty w dane, z których organizacja może korzystać wiele razy.

flowchart LR
    A["Zaplanuj badanie"] --> B["Auto-lista zadań dla labu"]
    B --> C["Przeanalizuj wyniki"]
    C --> D["Porównaj wiele badań"]

    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 platform badawczych, które obejmują całą drogę naukowca: od zaplanowania badania, przez listę zadań dla laboratorium i analizę wyników, aż do porównania wielu badań.
• Od zera zaprojektowałem dwa nowe narzędzia w istniejącej bazie badań: narzędzie do planowania badania i listę zadań dla laboratorium, która generuje się z planu.
• Zaprojektowałem nową platformę do analizy wyników i porównywania badań. Zastąpiła ręczną pracę w Excelu, kalkulatorze online i Wordzie.
• Miałem pod opieką pulę kontraktorów UX, która urosła z 1–2 do ~15 osób. Rekrutowałem ich i dobierałem do projektów.

Wyniki

• Planowanie badania: ~2 tygodnie → kilka dni (~70% szybciej).
• Raport badawczy: ~3–5 dni ręcznej pracy → kilka godzin na kilka raportów.
• Plany badań i wyniki analiz trafiły do systemu, w którym można je przeszukać. Wiedza przestała znikać razem z autorem.
• Na starcie z narzędzia korzystało ~50 naukowców z dwóch obszarów badawczych. Projektowałem je tak, żeby dało się dodać kolejne.
• Znalezienie podobnego badania w bazie setek, a nawet tysięcy badań zajmuje chwilę. Wcześniej było to prawie niemożliwe, więc niektóre badania po prostu powtarzano.
• Metodę analizy, którą współpracownicy rozwinęli na tych narzędziach, opublikowano w recenzowanym czasopiśmie onkologicznym (dziesiątki cytowań). (Pełne cytowanie jest w wersji prezentacyjnej, tu je pomijam ze względu na anonimizację.)

Problem

Jak wyglądało planowanie badania?

Naukowcy pisali plany badań w Wordzie, zwykłym tekstem. Takiego planu nie dało się przeszukać, porównać z wcześniejszymi badaniami ani zamienić w listę zadań dla laboratorium. Przez to całe planowanie było wolne.

Najtrudniejsze było to, że plan działa na dwóch zegarach naraz:

• Czas badania. Nauka liczy w dniach badania: w którym dniu zważyć zwierzęta, podać lek, pobrać krew.
• Czas kalendarzowy. Laboratorium pracuje w prawdziwych datach, z ludźmi, sprzętem i wolnymi dniami.

Do tego badanie ma kohorty (grupy, które startują w różnym czasie) i pomiary, które się powtarzają. Dopasowanie dni badania do prawdziwego kalendarza w Wordzie było wolne i łatwo było się pomylić.

A jak wyglądała analiza wyników?

Naukowcy zbierali dane ręcznie do Excela. Potem wklejali je do narzędzia online, które działało jak kalkulator bez pamięci. Nic się w nim nie zapisywało, więc wykresy trzeba było pobrać i ręcznie wkleić do raportu w Wordzie.

Najbardziej bolało biznes szukanie wcześniejszych badań. Każde badanie miało tylko kilka metadanych, więc znalezienie pracy o podobnych parametrach graniczyło z cudem. Nowy system musiał zbierać dane w uporządkowanej formie i pozwalać je przeszukiwać.

Moja rola / zakres

• Byłem UX leadem całego obszaru. Narzędzie do planowania było w całości moje, nadawałem mu kierunek od pierwszego dnia. Platformę analizy projektowałem jako lead, a po jakimś czasie dołączył do mnie jeden kontraktor.
• Przy istniejącej bazie badań prowadziłem 2–3 kontraktorów.
• Pracowałem głównie z naukowcami i z zespołem developerskim, w którym siedzieli biostatystycy. Platforma analizy działała na R Shiny z własnym frontem w Bootstrapie, a interaktywną siatkę wykresów zbudowaliśmy w Angularze.

Proces

• Badania z naukowcami w pętli. Rozmawiałem z naukowcami, prototypowałem, testowałem i zbierałem feedback. Tak w kółko, przez cały projekt. Głównie zdalnie, ale też na miejscu z zespołem badawczym w USA.
• Analiza wyników. Obserwacja codziennej pracy naukowców pokazała dwa główne problemy: ręczne raporty i szukanie wcześniejszych badań. Potem razem z developerami zaprojektowaliśmy nową architekturę. Stary kalkulator musiał zniknąć, żeby dane mogły zostać w systemie.

Kluczowe decyzje i trade-offy

• Jedno narzędzie dla różnych dziedzin. Z narzędzia korzystały zespoły od badań nad rakiem, od neurologii i inne. Każdy obszar miał swoje wymagania, więc zamiast szyć narzędzie pod jeden zespół, zbudowaliśmy je na parametrach. Ta sama zasada obowiązywała potem w module analizy.
• Badanie jako główny obiekt w systemie. Jedno badanie to jeden wpis, ale może mieć wiele analiz. Kilku naukowców korzysta z wyników tego samego badania i każdy patrzy na inne parametry.
• Surowe dane zostają, wykluczenia są opisane. Stary system trzymał surowe i przetworzone dane bez informacji, co i dlaczego wyrzucono. W nowym oryginalny zbiór zawsze zostaje. Na ekranie wykluczeń naukowiec układa dane po osobnikach, dniach albo grupach, wyklucza pojedyncze punkty albo całe serie i zostawia podsumowanie dla innych.
• Jeden moduł analizy dla wielu działów. Naukowiec wybiera wskaźnik (np. wagę albo wyniki krwi), potem badanie, a na końcu parametry. Wiele analiz z różnymi parametrami może układać w siatkę.
• Siatka wykresów, która nie jest równa. W wierszach są leki, w kolumnach dawki, ale każdy lek ma inne dawki. Część komórek musi zostać pusta. Muszę przyznać, że dopasowanie układu do tej nierówności dało najwięcej, jeśli chodzi o czytelność analiz.

Siatka analiz nie może być równa. Każdy lek ma inne dawki, więc puste komórki są tu normalne.

• Raport składany jak w Notion. Naukowiec pisze tekst i wstawia w niego wykresy i tabele z analiz.
• Porównywanie wielu badań od zera. Wcześniej ten moduł nie istniał i badania porównywano ręcznie. Najtrudniejsze było dopasowanie grup, bo każde badanie numeruje je po swojemu. Naukowiec najpierw definiuje warstwę porównania (najczęściej lek + dawka). Potem dla każdego badania wybiera z listy, która grupa do niej pasuje: w pierwszym to grupa 2, w drugim grupa 6, w trzecim grupa 3. Rozwiązanie jest proste i według mnie właśnie dlatego zadziałało. Dalej naukowiec korzysta z tych samych kroków co w głównej platformie: czyszczenie danych, analizy, raport.

flowchart LR
    A["Badanie 1<br/>grupa 2"] --> W["Warstwa porównania<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

• Kalendarz pokazuje kolizje, a nie rozwiązuje ich sam. Laboratoria prowadzą zwykli ludzie. Są święta, są dni, kiedy brakuje kogoś w zespole. Pobranie krwi zaplanowane na 50. dzień badania mogło wypaść w dzień, kiedy laboratorium nie pracuje. Automatyczne przesuwanie takich zdarzeń byłoby zbyt skomplikowane i zależne od ludzi, więc daliśmy laborantom widok kalendarza. Widzą w nim, co wypada w święto albo w dzień z brakami, i sami decydują, co z tym zrobić.

Harmonogram działa na dwóch zegarach naraz, dniach badania i kalendarzu laboratorium. Narzędzie pokazuje kolizję zamiast ją ukrywać.

• Przekazanie narzędzia. Jesienią 2019 przeszedłem do bardziej strategicznej pracy w całym obszarze. Narzędzie do planowania przejęła osoba zrekrutowana na etat. Proces był już wtedy na tyle ustalony, że zostało jej niewiele pracy koncepcyjnej.

Jak to się skończyło

Planowanie badania skróciło się do kilku dni, a plany przestały żyć w Wordzie. Po stronie analizy raport, który zajmował kilka dni, powstaje w kilka godzin. Naukowcy mogą też sprawdzać różne warianty analizy, bo system pamięta każdą z nich. Według mnie najlepszym sygnałem było to, że po zobaczeniu platformy analizy zespół neurologii sam poprosił, żeby wdrożyć ją u nich jako następnych.

Co z tego wyniosłem

• Prawdziwe dane naukowe nie układają się w równe tabele. Jeden lek ma trzy dawki, kolejny trzy inne. Projekt musi to przyjąć, bo wymuszanie równego układu psuje czytelność.
• Czas był mniej ważny od nowego sposobu pracy. Krótszy raport cieszy, ale według mnie więcej dało to, że naukowcy mogą zapisywać i porównywać wiele wariantów analizy. Wcześniej w ogóle nie mieli takiej możliwości.
• Warto posadzić ekspertów przy developerach. Biostatystycy siedzieli w zespole developerskim i dzięki temu obliczenia były poprawne od początku.
• Wymóg „dla wszystkich dziedzin” okazał się zaletą. Musieliśmy obsłużyć naraz badania nad rakiem i neurologię, więc zbudowaliśmy system na parametrach. Dzięki temu dało się go potem używać w obszarach, dla których nie był pierwotnie projektowany.