Systemy klasy HIS w ochronie zdrowia muszą sprostać wyjątkowym wyzwaniom: ogromnej liczbie danych, wysokiemu tempu pracy i potrzebie maksymalnej przejrzystości. Nasz klient, producent oprogramowania medycznego, po latach rozbudowy funkcjonalności stanął przed problemem: interfejs jego systemu szpitalnego nie spełniał już oczekiwań użytkowników.
Zostaliśmy zaproszeni do stworzenia nowoczesnego, intuicyjnego i elastycznego rozwiązania, które odpowiada na realne potrzeby lekarzy i pielęgniarek. Dzięki badaniom, warsztatom i projektowaniu setek ekranów od podstaw, dostarczyliśmy interfejs, który będzie wspierał personel w codziennej pracy i realnie poprawiał jakość opieki nad pacjentami.
Najważniejsze informacje:
- Branża: healthcare
- Typ projektu: UI, UX, research, koncepcja
- Obszar prac: system klasy HIS
- Zlecone działanie: redesign UI
- Główny rezultat: Kompleksowe opracowanie nowego systemu, obejmujące pełny proces projektowania UX i UI, od podstaw.
- Rok realizacji: 2022-2024
- Skład zespołu EDISONDY: Piotr Dziadowicz (Lead UX Designer), Anna Bielak (UX Designer), Rafał Bochniak (Senior UI Designer), Urszula Kozieł (Product Designer), Miłosz Michałowski-Żuk (Lead Product Designer), Magdalena Malinowska (Product Designer), Ewa Golik (Project Manager)
Problemy, wyzwania i wskaźniki wejściowe
Interfejs systemu, który firma Klienta z powodzeniem wdrażała w placówkach medycznych przez wiele lat, przestał spełniać oczekiwania użytkowników. W odpowiedzi na potrzeby użytkowników system był stale rozbudowywany o nowe funkcje. Jednocześnie przez prawie dwie dekady jego interfejs nie był gruntownie przeprojektowywany.
W efekcie, ekrany zyskały dziesiątki linków, umieszczonych w rozwijanych sekcjach. Przy doskonałej znajomości zachowań i potrzeb użytkowników, producent oprogramowania zdecydował się zwrócić do nas po wsparcie, by dostarczyć interfejs zapewniający przejrzystość i wysoką użyteczność, czyli cechy systemu konieczne w zmiennym, obciążonym informacyjnie środowisku, jakim są placówki lecznictwa zamkniętego (szpitale) i otwartego (przychodnie).
Wyjściowa wersja systemu nie spełniała potrzeb użytkowników takich jak, m.in.:
- możliwość szybkiego przełączania między ekranami/pacjentami, z zachowaniem wcześniej wybranego kontekstu,
- zorganizowanie hierarchii danych w sposób intuicyjny i logiczny,
- optymalizacja zarządzania informacjami na poszczególnych ekranach,
- automatyzacja procesów, aby zredukować liczbę nadmiernych kliknięć.
Jakie były efekty współpracy, czyli co świadczy o sukcesie projektu
Wspólną pracę zaczęliśmy od próby redesignu istniejącego interfejsu. Ustaliliśmy, że w tym przypadku, bez gruntownej przebudowy sposobów interakcji użytkowników z systemem, nie będziemy w stanie dostarczyć nowej jakości dla personelu medycznego. Proces projektowy zaczęliśmy od stworzenia szczegółowej roadmapy systemu, aby zaplanować skuteczne działania na kolejne miesiące.
Krok po kroku (i warsztat po warsztacie) zaczęliśmy tworzyć definicje funkcjonalne dla poszczególnych ekranów: od wczesnych szkiców, pozwalających na szybkie zwizualizowanie pomysłów i stworzenie głównych zasad projektowych, przez wywiady z kadrą medyczną, aż po bardzo szczegółowe mapy ekranów (screenflows) uwzględniające najczęstsze, a także te nietypowe, przypadki użycia.
Kończąc projekt mieliśmy:
- około 230 zaprojektowanych ekranów dla urządzeń desktopowych,
- gruntownie przeprojektowane kluczowe procesy (np. zlecanie i wydawanie leków, planowanie zabiegów i operacji, analiza retrospektywna),
- dopasowany do specyfiki projektu design system, korzystający z frontendowego frameworku Bootstrap, który został uzupełniony o:
a) dedykowane komponenty, charakterystyczne dla specyfiki systemu szpitalnego,
b) mnogą liczbę statusów dla informacji.
Jak wyglądała współpraca, czyli etapy, narzędzia i metody
Etap 1: Analiza obecnego stanu systemu, wywiady z użytkownikami (kadra pielęgniarska i lekarska oraz zespół wdrożeniowy).
- Cel: Identyfikacja największych bolączek obecnej wersji systemu oraz poznanie potrzeb użytkowników.
- Działania i metody: indywidualne wywiady pogłębione, mapowanie screenflow AS-IS
- Wnioski/Efekt etapu: Dzięki rozmowom z użytkownikami dowiedzieliśmy się, w jaki sposób personel medyczny pracuje z oprogramowaniem. Istotny wniosek: samo w sobie oprogramowanie nigdy nie jest najważniejsze (bo najważniejszy jest pacjent), niemniej właściwa opieka nad pacjentem wymaga tego, aby wszystkie niezbędne informacje były w systemie dostępne w sposób łatwy, intuicyjny i przejrzysty. Oprogramowanie działa w służbie pacjenta, nigdy odwrotnie.
Etap 2: Projekt koncepcji nowego systemu
- Cel: Wypracowanie głównych zasad projektowych oraz wzorców nawigacyjnych
- Działania i metody: makiety lo-fi, screenflow, prototypy papierowe, model dziedzinowy, szkice, warsztaty, makiety hi-fi
Uważamy ten etap za jeden z najważniejszych w projekcie
- Wnioski/Efekt etapu: Bazując na jednym z najważniejszych ekranów (funkcji) systemu zaprojektowaliśmy główny screenflow, który pomógł nam wypracować główne zasady projektowe – później konsekwentnie używane dla następnych elementów systemu. Na tym etapie stworzyliśmy również koncepcję graficzną (UI) oraz bazowy design system, na podstawie którego rozpoczęliśmy projektowanie docelowych widoków.
Etap 3: Planowanie i projektowanie
- Cel: Zdefiniowanie zakresu projektu oraz zaprojektowanie najważniejszych części systemu
- Działania i metody: planowanie, projektowanie UX i UI, wywiady z użytkownikami, testy partyzanckie.
- Wnioski/Efekt etapu: Wspólnie z zespołem klienta na bieżąco planowaliśmy prace, przeprowadzaliśmy warsztaty i projektowaliśmy kolejne funkcjonalności systemu. Wielokrotnie pokazywaliśmy wstępne pomysły pracownikom medycznym i na bieżąco poprawialiśmy nasze projekty.
Był to najobszerniejszy etap, jeśli chodzi o poświęcony czas, liczbę zaprojektowanych screenflows i gotowych widoków. Uwzględniając podstawowe ekrany i ich warianty mówimy o setkach szczegółowych projektów interakcji i stanów.
Nasze wnioski na podstawie tego projektu
Ze względu na różnorodność pacjentów i ich problemów, ale także pewnych lokalnych sposobów organizacji pracy, typowe customer (a może raczej nurse/doctor) journey nie jest dobrym narzędziem wspomagającym mapowanie zawartości i interakcji w systemie klasy HIS.
Nieprzewidywalność przypadków i różnice w sposobie pracy, występujące nawet między oddziałami tego samego szpitala powodują, że liniowe podejście do projektowania procesów musi zostać zastąpione bardziej złożonymi metodami (np. mapowanie modelu dziedzinowego).
Interfejs powinien być maksymalnie elastyczny, aby jednocześnie wspierać „popularne” przypadki użycia, a także udostępniać użytkownikom kilkanaście uzupełniających funkcji. Z takim poziomem złożoności i nieprzewidywalności nie mamy do czynienia w znakomitej większości aplikacji, z których korzystamy na co dzień.
