Analiza lokalizacji biznesowych z wykorzystaniem danych i AI

Przegląd projektu
Kadme to jeden z wiodących dostawców oprogramowania dla przemysłu węglowodorowego. Ich narzędzia wspomagają zarządzanie danymi w wielu dużych firmach. Kadme wykorzystuje najnowocześniejsze technologie, takie jak uczenie maszynowe, cloud computing i sztuczna inteligencja. W ich portfolio dominują aplikacje przeznaczone głównie dla specjalistów ds. danych i analityków.
A co z geologami i ekspertami terenowymi, którzy mają dość błądzenia w labiryncie liczb, tabel i wąskospecjalizowanych interfejsów? Kadme potrzebowało zupełnie nowej aplikacji dedykowanej tej, dotychczas pomijanej, grupie.
Wyzwanie
Potencjał geologów jest ograniczony przez dostępność menedżerów danych i złożoność istniejącego oprogramowania. Ten wąski gardło wpływa zarówno na szybkość, jak i zakres analizy danych. Naszym celem było stworzenie aplikacji, która otworzy nowe możliwości dla branży E&P, uwalniając kreatywność geologów.
Uciążliwe i skomplikowane narzędzie dedykowane wąskiej grupie menedżerów danych.
Nowa, wysoce użyteczna aplikacja skrojona przede wszystkim dla geologów i specjalistów terenowych, z wyraźnie niższym progiem wejścia niż poprzednie rozwiązanie.
Nasze działania
Aby osiągnąć wymierne efekty w wyznaczonym czasie, musieliśmy przyjąć zwinne podejście i skupić się na szybkim dostarczaniu kolejnych przyrostów.
Wspólnie z klientem zbudowaliśmy zespół projektowy odpowiedzialny za pierwszy etap projektu. Przy wsparciu deweloperów mogliśmy szybko weryfikować nasze pomysły i projekty. Jednak żaden projekt nie może ruszyć bez wcześniejszego wykonania:
Na początku: faza odkrywcza
Podczas intensywnej fazy odkrywczej musieliśmy zrozumieć nie tylko perspektywę użytkownika i biznesu, ale też przejść przez skrócony kurs dziedzinowy. Niezbędne jest pełne zrozumienie specyficznego języka, pojęć, definicji i wyspecjalizowanej wiedzy o branży.
Dzięki bardzo zaangażowanym przedstawicielom klienta mieliśmy łatwy dostęp do użytkowników, ale prowadzenie badań z ich udziałem okazało się trudne. Byli poza naszym zasięgiem, musieliśmy więc wykazać się kreatywnością i oprzeć się na wiedzy klienta o nich. W tamtym czasie jedyną akceptowalną metodą były ankiety kwestionariuszowe.

Projektowanie w wielu, wielu iteracjach
Mając świadomość, że wkraczamy na "terra incognita" i ani my, ani klient nie mieliśmy jasnego pomysłu na ogólny układ aplikacji, postanowiliśmy badać możliwości, a decyzje podejmować później. Doprowadziło nas to do koncepcji "maplikacji" — aplikacji, w której moduł mapy odgrywa kluczową rolę.
Spośród trzech zdefiniowanych podejść zdecydowaliśmy się na opcję mapy częściowej. Przyjęliśmy też założenie, że ostateczna decyzja może zapaść dopiero po zaprojektowaniu głównych komponentów GUI.

Zmieniliśmy więc podejście i zaczęliśmy od szczegółowego zgłębiania procesów i sposobów ich realizacji. Nasze pierwsze prace nad interfejsem przypominały bardziej tworzenie cegiełek niż kompletnego projektu. Te izolowane elementy były intensywnie testowane i walidowane wewnętrznie z przedstawicielami klienta, zanim trafiły do pełnego mockupu strony.
Wszystkie komponenty UI zostały "przełożone" na bibliotekę React.js w Storybooku.

Iteracja po iteracji dbaliśmy o wysoką użyteczność zarówno poszczególnych elementów, jak i całego interfejsu systemu, gdy zaczął się składać w całość. Musieliśmy mieć pewność, że nasze rozwiązanie jest intuicyjne i łatwe w obsłudze w wielu różnych scenariuszach użytkowania. Narzędzie mogło być używane nie tylko na nowoczesnym komputerze stacjonarnym w spokojnym biurze, ale też na wytrzymałym tablecie podczas złej pogody na platformie wiertniczej.

Praca z danymi
Naszym celem było zaprojektowanie systemu, który pomaga użytkownikom przeszukiwać ogromne ilości nieustrukturyzowanych danych, plików i encji agregowanych z wielu źródeł. Każdy element mógł zawierać inne informacje, dlatego zdefiniowaliśmy hierarchię i logikę oraz sposób ich wyświetlania bez przeciążania interfejsu. To miało być coś znacznie lepszego niż edytor arkuszy kalkulacyjnych!

Naszym głównym priorytetem było dostarczenie wizualnych ułatwień umożliwiających szybszą orientację (takich jak hierarchia najważniejszych elementów, z wyróżnionymi "źródłami danych" czy "rozszerzeniami") oraz ułatwienie podejmowania decyzji na pierwszy rzut oka. Wiedzieliśmy, że bez dobrej logiki wyszukiwania nie będziemy w stanie pomóc użytkownikom przebrnąć przez miliony wyników.

Postawiliśmy na projektowanie skoncentrowane na wyszukiwaniu, z potężną wyszukiwarką umożliwiającą tworzenie złożonych zapytań (z wykorzystaniem technik boolowskich i quasi-regexowych), wzbogaconą szerokim zestawem filtrów do zawężania wyników.

Doświadczenie z mapą
Kontekst przestrzenny ma ogromną wartość dla procesu eksploracji geologów. Pierwszą zasadą projektowania modułu mapy było traktowanie go jako elementu uzupełniającego resztę interfejsu, a nie głównego obszaru interakcji. Skupiając się wyłącznie na najważniejszych elementach, nie przeciążaliśmy mapy każdą możliwą daną (choć pokusa była duża).
Pracowaliśmy wokół głównych scenariuszy użytkowania i wyświetlaliśmy minimalne, niezbędne informacje w kontekście wyszukiwań użytkownika. Taka responsywność pozwoliła nam uniknąć potencjalnych trudności z nieczytelną mapą i nadmiarem kolorów oraz elementów — mówię o tym dlatego, że nadal musieliśmy uważać na użycie kształtów, linii i ograniczonej palety barw. Znalezienie użytecznych i estetycznych kolorów nie było łatwe, ponieważ projektowany system miał być renderowany w jednym z trzech motywów kolorystycznych.
Ostatecznie nie byłoby przesadą stwierdzenie, że zdobyliśmy nowe kompetencje w dziedzinie projektowania GIS i wizualizacji danych!

Praca z motywami kolorystycznymi
Proste przemalowanie systemu na inną paletę to banalny zabieg. Wyzwanie zaczyna się tam, gdzie paleta ma określone przeznaczenie i specyficzny kontekst użycia — a tak właśnie było w naszym projekcie.
Pomysł polegał na dodaniu ciemnego motywu jako opcji dla oryginalnego projektu. Część specjalistów pracuje w dość mrocznych otoczeniach, a jasny, białawy interfejs szybko męczyłby oczy. Ciemny motyw rozwiązuje ten problem w prosty sposób.

Ponieważ od początku myśleliśmy o różnych zastosowaniach kolorów i motywach (co zaowocowało stworzeniem quasi-wytycznych i zasad), opracowanie nowej palety barw dla danych przestrzennych na mapie okazało się jeszcze prostsze.
Lubimy podejście "przygotuj się dobrze i nie martw się później".
Wyzwanie dostępności dla osób z zaburzeniami widzenia barw
Jednym z największych wyzwań było przygotowanie unikalnego motywu dla użytkowników z zaburzeniami widzenia barw (deuteranopia i protanopia).
Na początku przeprowadziliśmy gruntowne badania. Nie było oczywiste, jak w takich przypadkach prezentować niektóre informacje na mapie. Skończyło się na niezliczonych iteracjach: od szukania jednej, sprawdzonej odpowiedzi w internecie i materiałach różnych organizacji ds. dostępności, po sprawdzanie każdego możliwego scenariusza mapowego i rozwiązań konkurencji. Z pomocą narzędzi symulujących zaburzenia widzenia zmienialiśmy kolory jeden po drugim.
Ostatecznie zastosowaliśmy ciemny motyw dla podstawowej warstwy mapy i jasny motyw dla reszty interfejsu, ponieważ zapewniało to lepszy kontrast.

Wiedzieliśmy, że mieszanie jasnego i ciemnego motywu w jednej wersji byłoby sprzeczne z ideą motywów dostosowanych do różnych warunków oświetlenia — jak wspominaliśmy wcześniej. W naszym MVP nie mogliśmy jednak zadowolić wszystkich jednocześnie. Priorytetem była dla nas bezbłędna czytelność interfejsu.
Wyniki i wnioski
Etap projektowania został ukończony (luty 2022), a development jest w toku. Nie możemy się doczekać fazy testów z użytkownikami, podczas której będą potrzebne kolejne iteracje i zmiany.
2-tygodniowych sprintów projektowych — bez opóźnień i dodatkowych kosztów
komponentów w Storybooku umożliwiających łatwy dalszy development
doskonała opinia zadowolonego klienta
Czego nauczyliśmy się do tej pory:
Definiuj zakres MVP odpowiednio do dostępnego czasu. Czas to najlepsza ochrona przed pokusą rozszerzania zakresu pracy.
W podejściu MVP najlepsza droga wiedzie od mniej do więcej. Łatwiej jest dodać opcję, niż ją usunąć.
Nie bój się rezygnować z perfekcji na rzecz rozwiązań "wystarczająco dobrych".
Projektowanie bez szerokiej perspektywy całego interfejsu może być trudne, ale nie niemożliwe. Takie podejście bywa pomocne, gdy na początku nie masz pewności co do ogólnego układu aplikacji.
Wizualizacja danych jest jeszcze trudniejsza, gdy mamy do czynienia z danymi nieustrukturyzowanymi. Elementy informacji mają ze sobą niewiele wspólnego, dlatego zamiast złożonych wzorców należy stawiać na wszechstronność i elastyczność.
Doświadczeni projektanci i product ownerzy muszą wiedzieć, kiedy przestać dyskutować i szukać najlepszego rozwiązania, i oddać ostateczną decyzję w ręce fazy testów z użytkownikami.

