Metro dla niewidomych

W 2015 roku rzuciłem pracę w reklamie.
Chcąc skupić się na tematach związanymi z projektowaniem UX trafiłem do firmy budującej rzecz, o której miałem raczej mgliste pojęcie, wobec czego wydawała mi się doskonałym miejscem na rozpoczęcie tej drogi. I jak do tej pory jest to rzecz, z pracy przy której jestem najbardziej dumny, a — paradoksalnie — nie postawiłem w zasadzie żadnego piksela.


Urząd miasta Warszawy rozpoczął w okolicy roku 2014/2015 tworzenie gry miejskiej w okolicach warszawskiego Centrum Nauki Kopernik i Parku Fontann. Jednym z kluczowych elementów aplikacji miało być wsparcie dla osób niewidzących i niedowidzących. Dodatkowo, ponieważ CNK znajduje się przy stacji metra, projekt zakładał stworzenie możliwości nawigacji po tejże stacji.

Pierwotne założenia projektu nie były mi w całości znane i nie miałem na nie wpływu. I o ile dla przeciętnego użytkownika można poczynić daleko idące założenia dotyczące użytkowania aplikacji na podstawie dotychczasowego doświadczenia (tzw. „dobre praktyki”, badania rynku, testy A/B, analiza wykorzystania, etc.), o tyle w przypadku jakiejkolwiek grupy posługującej się urządzeniami w niekonwencjonalny sposób (upośledzenia fizyczne, umysłowe, niestandardowe rozszerzenia sprzętowe) niezbędny jest bezpośredni kontakt z konkretną grupą, zapoznanie się z potrzebami tejże grupy, jej spojrzeniem na urządzenie, problem i propozycje jego rozwiązania.


Na zaawansowanym etapie prac okazało się, że przyjęte początkowo założenia nie sprawdzają się w kontakcie z rzeczywistością, powodując więcej zamieszania i problemów. Nawigacja oparta o sieć beaconów zastosowana w tym przypadku nie była na tyle dokładna, żeby wesprzeć użytkownika niedowidzącego, czy niewidomego. Osoba widząca jest w stanie zweryfikować błędne wskazania, czy podpowiedzi aplikacji: oczywistym jest, że stojąc przodem do torów pociągu zignoruję instrukcję „Idź do przodu 10 metrów” („wsparcia” dla osób ze skłonnościami samobójczymi nie było przewidywane). Dla osoby niewidzącej taka instrukcja może skończyć się bardzo nieciekawie. Dodatkowy problem stanowiła skomplikowana kalibracja aplikacji w celu określenia kierunku poruszania się użytkownika, która była po prostu uciążliwa i zawodziła w najbardziej kluczowych momentach.
Należało wobec tego spróbować nieprecyzyjne i potencjalnie błędne wskazania pozycji i kierunku poruszania się użytkownika zamienić na bardziej pomocny zestaw podpowiedzi.

Wspólnie z zespołem zaczęliśmy poszukiwać odpowiedniego rozwiązania, które zachowując ideę i istniejące możliwości technologiczne (beacony, system do zarządzania nimi) pozwoli nam uzyskać bardziej optymalny efekt. W ten sposób powróciliśmy — jak się okazało — do jednego z pierwotnych pomysłów, opartych o strefy beaconów, a nie punkty.
Przed rozpoczęciem wdrażania niezbędne były nowe założenia i teorie do przetestowania. Swego rodzaju walidacją idei był projekt, na który trafiliśmy poszukując rozwiązań.

Wayfindr / Platforma Open Standard / wayfindr.net

Zastosowane przez Wayfindr rozwiązanie poniekąd pokrywało się z naszym podejściem do problemu, co tylko pomogło nam w weryfikacji zasadności pomysłu.

Punktem wyjściowym były dwa scenariusze, które wydawały nam się najczęstszymi sytuacjami, z którymi będziemy mieli styczność:

  1. Użytkownik przyjechał pociągiem i wysiadł na peronie.
  2. Użytkownik wchodzi na stację z ulicy.

Dla pierwszej sytuacji w większości przypadków rozwiązaniem jest „Chcę wyjść ze stacji wybranym przez siebie wyjściem” (jeśli jest więcej, niż jedno). Dla drugiej — „Chcę dojść do peronu i wsiąść do pociągu jadącego w odpowiednim kierunku” (testowana stacja obsługuje jedną linię metra, w przypadku stacji z wieloma liniami dodatkowym elementem miał być wybór linii).

Mając tak silne podstawy przygotowaliśmy pomysł, który zakładał śledzenie pozycji użytkownika nie punktowo, a strefowo. Wiedząc, że z punktu widzenia systemu użytkownik pojawił się w strefie na peronie (nie ma historii wizyt którejkolwiek z dostępnych stref) przyjęliśmy, że użytkownik wysiadł z pociągu, znajduje się na peronie i chce wyjść ze stacji (scenariusz 1). Analogicznie, dla scenariusza 2 — jeśli użytkownik pojawił się w strefie wejścia/wyjścia (bez historii z poprzedniej strefy) założeniem było, że chce wejść na stację, dojść do peronu i wsiąść do pociągu.
Kolejnym krokiem było rozrysowanie na planach stacji stref zawierające kluczowe elementy otoczenia, dające się opisać jak najprostszym językiem.

Dalszym etapem było stworzenie scenariuszy możliwych tras z peronu do wyjść i od wejść na stację do peronu, wraz z wariantami (wejścia do toalet, użycie windy, etc.). Nie pobierając kierunku poruszania się bezpośrednio z urządzenia musieliśmy stworzyć możliwość określenia tegoż kierunku, choćby w przybliżeniu, w inny sposób. 
Posiadając historię stref — z której strefy użytkownik wyszedł, a do której wszedł — byliśmy w stanie z dużym prawdopodobieństwem określić kierunek poruszania się i wywnioskować cel, a w efekcie podawać użytkownikowi informacje najbardziej przydatne dla niego w danej chwili.

Gotowe scenariusze musiały zostać poddane próbie ognia. Spotkaliśmy się z grupą osób z Polskiego Związku Niewidomych, chętnych nam pomóc i posługujących się na codzień smartphone’m. Przeszliśmy się kilkukrotnie po naszych trasach osobno z każdym z grupy testerów, występując w roli aplikacji i czytając komunikaty, które przygotowaliśmy. Na podstawie reakcji naszej grupy testowej zebraliśmy zestaw uwag i spostrzeżeń, które następnie wprowadziliśmy do naszych scenariuszy: co się sprawdza, co wymaga poprawy z punktu czysto językowego, co nie działa jako opis, albo nie ma sensu, co jest zbędne, co można wyrzucić nie umniejszając jakości informacji, a skracając komunikat do minimum. Jednym z podstawowych błędów okazała się chęć powiedzenia za dużo i zbyt szczegółowo, wobec czego komunikaty trwały bardzo długo i użytkownik tracił czas, wysłuchując ich do końca — bezobrazowy ekwiwalent za długiej animacji blokującej działania użytkownika do czasu jej zakończenia.
Następny etap pracy polegał na naniesieniu zmian i poprawek po pierwszych testach, wprowadzenie stref do systemu, przygotowanie całej nowej mechaniki na potrzeby aplikacji i kolejna seria testów, tym razem już z pomocą urządzenia.

Ostatnią fazą projektu była finalizacja komunikatów i testowanie bez jakiegokolwiek wsparcia z naszej strony: tylko użytkownik i telefon.


Po zakończeniu prac podsumowaniem projektu mogą być dwie obserwacje.

Po pierwsze zaskoczenie, jak sprawnie osoby niewidome i niedowidzące posługują się urządzeniami z ekranami dotykowymi i jak bardzo frustrują je źle dostosowane do ich potrzeb aplikacje. Po raz kolejny potwierdziło się, że nosimy ze sobą wiele nieuzasadnionych uprzedzeń i niczym niepotwierdzonych „prawd” o ludziach i świecie i jak bardzo nie można na takich „prawdach” polegać.

Po drugie:

jeśli aplikacja miałaby robić tylko jedną rzecz (dla osób niewidomych), byłaby to informacja dla pasażera zjeżdżającego ruchomymi schodami na peron, z której strony peronu odjeżdża który pociąg.

I tym sposobem przedefniowaliśmy MVP dla tego produktu — coś, co było drobnym elementem systemu okazało się najwartościowszą jego cechą.

The Human Factor / Mayors Challenge 2015 Learning
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.