User Centered Design – oczekiwania vs rzeczywistość ~ Izabela Spurek

Focus on the user and the rest will follow. Pierwsza z 10 Prawd Potwierdzonych Przez Google zakłada, między innymi, że usługi powinny służyć przede wszystkim użytkownikowi, a nie wewnętrznym celom lub wynikom finansowym przedsiębiorstw. Jest spójna z zapoczątkowaną przez Dona Normana koncepcją User Centered Design, według której projektując, powinniśmy na pierwszym miejscu stawiać użytkownika, jego potrzeby, emocje i zadania, które ma do wykonania. Ta sięgająca lat 80. XX wieku koncepcja zakłada, że celem nadrzędnym produktu ma być odpowiedź na potrzebę użytkownika.

Ponieważ zadawanie pytań i szukanie rozwiązań jest jednym z moich hobby, zaczęłam się zastanawiać, czy kapitalistyczna rzeczywistość pokrywa się z przedstawioną powyżej teorią, czy może jest tak, że nie tylko Instagram pokazuje, że oczekiwania i rzeczywistość bywają często w silnej opozycji. Dodatkową inspiracją do zgłębienia tego tematu był czas, kiedy projektowałam aplikację CITY, łączącą różne formy poruszania się po mieście. Takie 8 w 1 z punktu A do B.

Zafascynowana swoim pomysłem i radością z odkrycia, że na rynku nie ma jeszcze takiego rozwiązania przystąpiłam do badań, prototypowania, a następnie testów z użytkownikami. Zawsze ogarnia mnie lekki sceptycyzm, gdy zauważam, że rynek nie zmaterializował jeszcze pomysłu, który właśnie narodził się w mojej głowie. Niewzruszona, kontynuowałam projekt, będący zaliczeniem kursu UX Design.

Wyobraź sobie sytuację, że jesteś spóźniony na ważne spotkanie w centrum Warszawy, ze względu na godziny szczytu panują ogromne korki, jest awaria metra, a każda minuta jest niezwykle cenna. Prawdopodobnie żeby zoptymalizować trasę i wybrać najkorzystniejszą czasowo i finansowo opcję transportu musiałbyś przełączać się pomiędzy kilkoma aplikacjami, a następie ocenić, czy szybszy będzie Uber, czy tańszy będzie Bolt, czy hulajnogą ominiesz korki, a może jest dostępny rower na najbliższej stacji Veturilo. Czy naprawdę tego procesu nie można uprościć?

Zaczęłam się zastanawiać nad tym, że skoro współcześnie mamy tyle niesamowitych rozwiązań ułatwiających nasze życie, dlaczego wciąż nie mamy rozwiązania komfortowego poruszania się w sytuacjach nagłych, awaryjnych, nieplanowanych? Dlaczego powstały porównywarki typu Ceneo czy Cinkciarz, opcja „sortuj od najtańszej” na Allegro, jednak wciąż żadna aplikacja nie rozwiązuje problemu „awaryjnego”, nagłego i jak najszybszego poruszania się po mieście?

Założeniem aplikacji CITY jest połączenie ośmiu już istniejących aplikacji (Uber, Bolt, Lime, JakDojadę itd.) w jedno proste rozwiązanie. Użytkownik wybiera najszybszego i najtańszego „przewoźnika” i z poziomu aplikacji zamawia u niego usługę.

Jednym z etapów podczas projektowania tej aplikacji były badania a na późniejszym etapie testy z użytkownikami. Celem badania było poznanie nawyków, zwyczajów i potrzeb użytkowników przemieszczających się po Warszawie. Jeśli chodzi o kryterium doboru respondentów, to stworzyłam screener, w którym chciałam pozyskać mieszkańców Warszawy na co dzień korzystających z aplikacji, zwolenników  aut, rowerów miejskich, transportu publicznego, obeznanych z technologią. Wyłoniłam 7 respondentów:

Rodzaje badań, które przeprowadziłam:

Wywiad kontekstowy – czyli miks Indywidualnego Wywiadu Pogłębionego Semi-Ustrukturyzowanego (Individual In Depth Interview semi-structured) – badani odpowiadali na przygotowane wcześniej pytania, np. czym się kierujesz poruszając się po mieście, co byś usprawnił w rozwiązaniach z jakich korzystasz obecnie, jak wyglądałaby Twója wymarzona podróź do pracy? Respondenci prezentowali także na swoich smartfonach jak korzystają z istniejących rozwiązań.

Wywiad grupowy – użykownicy w 6 osobowych grupach odpowiadali na wcześniej przygotowane pytania.

Przy użyciu kart Dixit zapytałam także o funkcjonalności jakie respondenci widzieliby w tej aplikacji.

W przeprowadzonej analizie jednostkowej zauważyłam, że doświadczenia każdego respondenta są bardzo podobne. Potwierdziła to analiza krzyżowa, która nadała jasną i przejrzystą strukturę moich obserwacji:

Rekomendacje:

– czas jest kluczowym czynnikiem przy wyborze formy komunikacji (zatem sortowanie form transportu w aplikacji: od najszybszej)

– forma płatności: dodanie karty (nie: pre paid)

– użytkownik chce znać koszt usługi przed skorzystaniem z niej

– problemy z oddaniem rowerów nie wpłynęły na zaprzestanie korzystania z aplikacji więc problem znikomy

Dlaczego przedstawione powyżej rozwiązanie nie doczekało się jeszcze realizacji i jakie podjęto dotychczas próby rozwiązania tego problemu?

Na początku 2017 roku Google dodał funkcję zamawiania Ubera z poziomu aplikacji. Z punktu widzenia użytkownika było to duże ułatwienie. Po wpisaniu w Google Maps swojej trasy, użytkownicy mogli od razu zamówić przejazd, bez konieczności przełączania się do aplikacji Uber. Z punktu widzenia Ubera ewentualną trudnością była ograniczona możliwość zbierania danych nt. swoich użytkowników, kierowców i tras. Funkcja ta już po paru miesiącach została usunięta z aplikacji Google Maps for iOS, po roku również z Androida. Google nie wydał oficjalnego oświadczenia w tej sprawie.

Pewnym ułatwieniem jest również funkcjonalność Google Maps polegająca na możliwości wyszukania stacji Veturilo wraz z informacją o liczbe rowerów gotowych do wypożyczenia.  Wystarczy wpisać w w Google Maps „Veturilo”. Aplikacja pokaże nam rower, jednak chcąc go wypożyczyć musimy przełączyć się już do aplikacji docelowej.

Kolejną próbą rozwiązania problemu są też aplikacje typu LokoCity lub Wheelme, które pokazują dostępne w okolicy pojazdy, a następnie kierują do odpowiednich aplikacji w celu wypożyczenia.

Niewątpliwie przeszkody technologiczne mogą uniemożliwiać wprowadzenie w życie idealistycznej wizji aplikacji CITY. Prawdopodobne jest też to, że sami zainteresowani nie byliby chętni na współpracę z aplikacją, w której ceny usług byłyby bezpośrednio porównywane z konkurencją. Wracając jednak do głównych założeń UXa oraz googlowskiego focus on the user and the rest will follow, jak żyć, jeśli reszta nie chce follow?

Izabela Spurek- Pracuje jako UX Designer w LeanCode. W wolnym czasie biega, zwiedza świat i zgłębia tajniki psychologii i marketingu. 

Izabela Spurek
Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *