Case study · Dimark
Redesign aplikacji serwisowej, którą technicy sami wybrali
DiMS to system utrzymania ruchu firmy Dimark przeznaczony do lotniskowych linii obsługi bagażu. Zaprojektowałam na nowo sposób, w jaki inżynierowie serwisu zgłaszają usterki, planują pracę i przeprowadzają serwis linii, a także stworzyłam stojący za tym design system. Gdy wersja zespołu i mój prototyp zostały przetestowane, inżynierowie serwisu wybrali mój projekt, który następnie trafił do wdrożenia.
8–10 h
Przed zmianą
Jeden serwis linii bagażowej zajmował cały dzień pracy.
~40%
Mniej czasu
Zgodnie z szacunkami inżynierów serwisowych, którzy realizowali usługę.
3
Inżynierowie serwisu
Zaangażowani od pierwszego wywiadu po ostatni test.
Firma
Dimark
Branża
Przemysłowe B2B, lotniskowe systemy bagażowe
Czas trwania
maj 2022 – sty 2024
Moja rola
UI/UX designer, jedyna projektantka w zespole
Zespół
Team leader, developerzy front-end i back-end, tester
Platforma
Tablet i desktop (zaprojektowany też mobile)
01 · Kontekst
Lotnisko nie może czekać na naprawę
Dimark projektuje, instaluje i serwisuje systemy obsługi bagażu dla lotnisk. Kiedy linia staje, bagaże się zatrzymują, a loty mogą być opóźnione, dlatego prace konserwacyjne odbywają się pod presją czasu.
DiMS to aplikacja, której inżynierowie serwisu używają do tej pracy: zgłaszania usterek, planowania zadań i przeprowadzania zaplanowanych przeglądów na linii. Przez prawie dwa lata pracy w Dimark pracowałam nad DiMS oraz nad innymi aplikacjami z tej samej rodziny produktów, w tym nad systemem monitorowania SCADA.
02 · Problem
Dwie potrzeby, jedno narzędzie
Potrzeba biznesu
Jeden spójny zestaw aplikacji, szybsze wdrażanie nowych funkcji i dostępność na poziomie spełniającym wymogi rynków o bardziej rygorystycznych standardach (WCAG).
Potrzeba użytkownika
Inżynierowie serwisu nie wiedzieli, jak korzystać z niektórych funkcji, nie mogli łatwo cofnąć się o krok, a także mieli trudności z małymi przyciskami i niskim kontrastem na tablecie.
Trudniejszy problem: zespół i ja inaczej rozumieliśmy proces świadczenia usługi. Zanim zaczęliśmy projektować ekrany, musieliśmy uzgodnić, jak w rzeczywistości wygląda obsługa linii.
03 · Moja rola
Jedyna projektantka w zespole
Pracowałam z team leaderem, developerami front-end i back-end oraz testerem.
Co robiłam
Audyt UX/UI, wywiady i testy z inżynierami serwisu, mapowanie procesów, design system, UI aplikacji firmy i handoff w Figmie.
Co rozpoczęłam
Audyt jako punkt wyjścia, dostępność (WCAG) jako standard zespołu oraz system projektowania zbudowany od podstaw – wszystko to ramię w ramię z zespołem.
04 · Kierunek
Najpierw zadbaj o solidne fundamenty za pomocą jednego systemu projektowania (Design System). Następnie zaprojektuj proces serwisowy w oparciu o to, jak inżynierowie serwisu rzeczywiście pracują na linii.
05 · Wpływ
Co się zmieniło
Dla inżynierów serwisu
Proste kroki zamiast zgadywania. Usługa, która wcześniej zajmowała 8–10 godzin, według ich własnych szacunków skróciła się o około 40%.
Dla developerów
Udokumentowany system projektowania (design system), dzięki któremu nowe ekrany były tworzone z gotowych elementów, a nie projektowane za każdym razem od zera.
Dla biznesu
Jedna spójna rodzina produktów i baza przygotowana na wymogi dotyczące dostępności.
Cała historia
Jak tam dotarliśmy
06 · Badania
Rozmowa z osobami na linii
Współpracowałam z trzema inżynierami serwisu i przez cały czas trwania projektu pozostawałam z nimi w stałym kontakcie. Rozmawialiśmy przy działającej aplikacji, w miejscu, gdzie testowanie było najbardziej praktyczne. Przekształcałam ich uwagi w prototypy w Figmie i testowałam z nimi klikalne wersje.
Mapowanie procesu
Przed zaprojektowaniem ekranów zmapowałam pełny cykl życia usterki w czterech procesach: zgłoszenie usterki, zdefiniowanie jej jako zadania, odbiór wykonanej pracy oraz raport serwisowy. Każdy proces rozpoczynał się od user story i celu, a także zawierał listę wszystkich punktów decyzyjnych, wymaganych pól i statusów.
Zgłoszenie
Inżynier serwisu wybiera urządzenie, skanując kod QR, wybierając je z listy lub wpisując jego nazwę, a następnie dodaje objawy, priorytet, lokalizację (przyloty, odloty, bagaż ponadwymiarowy) oraz opis.
Definicja
Kierownik zamienia zgłoszenie w zadanie. Instrukcje, części i narzędzia dla danego urządzenia są dołączane automatycznie, a zadanie trafia do planera.
Odbiór
Menedżer akceptuje poprawkę lub odsyła ją z powrotem. Odrzucona poprawka wraca na początek listy.
Statusy
Sześć statusów, każdy w swoim kolorze: Niezdefiniowane, Niezaplanowane, Zaplanowane, W toku, Zrobione, Nierozwiązane.
Tylko fragmenty. Ze względu na NDA nie mogę pokazać całego procesu.
Wniosek → Działanie
→ Stały przycisk „wstecz” na każdym kroku
→ Pola dotyku min. 48 px, główne akcje na dole ekranu
→ Paleta sprawdzona pod WCAG AA
→ Jeden design system dla wszystkich
07 · Decyzja
Dwie wersje procesu usługi
To była najtrudniejsza część projektu. Zaprojektowałam cały proces obsługi liniowej, a zespół i interesariusze go odrzucili. Mieli inne wyobrażenie o tym, jak ta usługa powinna działać.
Nie oponowałam. Zbudowałam ich wersję zgodnie z prośbą, a swoją rozwijałam równolegle jako klikalny prototyp w Figmie, nie blokując zespołu.
Wersja zespołu
Stworzone w pierwszej kolejności, dokładnie tak, jak oczekiwał zespół i interesariusze.
Mój prototyp
Klikalny prototyp w Figmie. Inżynierowie serwisu porównali oba rozwiązania, wybrali to jedno i trafiło ono do produkcji.
Gdy w zespole pojawia się brak zgody, pozwól osobom wykonującym pracę porównać rzeczywiste opcje.
Ograniczenia i to, co zostawiliśmy na później
Zdjęcia
Na niektórych lotniskach nie wolno robić zdjęć, więc zdjęcia urządzenia i miejsca są opcjonalne, a opis tekstowy zawsze wymagany.
Później
Edycja i anulowanie zgłoszonej usterki oraz wyświetlanie historii naprawy usterki, gdy zostanie ona ponownie zdefiniowana. Obie te rzeczy zapisaliśmy jako przyszłe funkcje, aby móc wydać pierwszą wersję.
08 · Rozwiązanie
Przed i po
Trzy ekrany, z których inżynier serwisu korzysta każdego dnia. Kliknij ekran, aby go powiększyć.
Przed: zwykły formularz na tle gradientu. Po: spersonalizowany ekran startowy DiMS z przełącznikiem języka u góry.
Przed
Po
Wcześniej: długi formularz z listami rozwijanymi. Teraz: kafelki do szybkiego klikania. Zeskanuj kod QR, wybierz objaw oraz priorytet i dodaj zdjęcie.
Przed
Po
Wcześniej: kolorowe kafelki z kodami takimi jak MAL czy OC01 i brak jakiegokolwiek kontekstu. Teraz: oś czasu zespołu ze statusem zadań, terminami i listą rzeczy do zrobienia tuż obok.
Przed
Po
Imiona i loginy na ekranach są rozmyte.
09 · Rezultaty
Od rezultatów do realnego wpływu
→ Usterki są zgłaszane wraz z urządzeniem, objawem, priorytetem i zdjęciem w jednym miejscu
→ Inżynierowie serwisu i kierownicy widzą ten sam plan i status zadań
→ Programiści tworzą nowe ekrany z udokumentowanych elementów
Inżynierowie serwisu wybrali nowy proces
→ Trafił na produkcję
10 · Wnioski
Co będę robić dalej
01
Zacznij od audytu. Daje on zespołowi wspólną listę problemów zamiast subiektywnych opinii.
02
Gdy nie zgadzasz się z zespołem, zbuduj obie opcje i daj użytkownikom je porównać.
03
Dostępność trzeba wyjaśniać, a nie tylko stosować.
04
Testuj tam, gdzie dzieje się praca, z ludźmi, którzy ją wykonują.
11 · Więcej z Dimarku
Inne aplikacje z rodziny
Poza DiMS projektowałam inne aplikacje z rodziny produktów Dimarku. Jeśli chcesz wiedzieć więcej, chętnie opowiem o nich na rozmowie.
Monitoring wideo
Aplikacja mobilna BRS
DiSCADA
BRS na skanerach ręcznych