User experience w ujęciu zwinnym – jak działamy?

 

Dobry UX ( więcej o user experience), dobry dizajn, dobry produkt zaczyna się od spotkania odpowiednich ludzi, których łączy wspólny cel oraz od koncepcji, wypracowywanej przez projektanta UX, z udziałem interesariuszy, na bardzo wczesnym etapie projektu. W tym miejscu spotykają się różne założenia, wizje, ale przede wszystkim odmienne doświadczenia. Wbrew pozorom, to nie wyłącznie kreatywność ma tutaj kluczowe znaczenie, lecz pewnego rodzaju odwaga do eksperymentowania. Nie chodzi tylko o to, żeby umiejętnie powielać znane nam rozwiązania, wyłącznie w celu pokrycia założeń funkcjonalnych systemu, lecz, żeby spróbować inaczej, w założeniu, że pozwoli nam to osiągnąć bardziej czytelny, dostępny i intuicyjny produkt. To, co dostarczamy, to jakiej jest jakości – wpływa na pracę naszego klienta, naturalne jest więc, że chcemy zrobić to jak najlepiej.

Na początek omawiane są w obrębie zespołu potrzeby biznesowe i zakres, jaki przyjmujemy do realizacji na najbliższe sprinty. Wówczas mają miejsce spotkania warsztatowe służące wymianie wiedzy i wypracowaniu wstępnej koncepcji. Ta podlega weryfikacji ze strony Product Managera, a następnie po korekcie, prezentowana jest i omawiana w ramach spotkania z Klientem oraz weryfikowana w ramach badań z użytkownikiem końcowym. Równolegle z postępem prac, backlog zadań jest pielęgnowany i doprecyzowywany. Projektowanie musi wyprzedzić development na tyle, aby na żadnym etapie projektu go nie wstrzymywać. Stąd – jako projektanci przyjmujemy na sprint zadania, które pokrywają pełen proces biznesowy, a które następnie na etapie planowania implementacji dzielone są na mniejsze Story. Projekty UX/UI przygotowywane są w dwóch wersjach – produktowej, budowanej przy użyciu Comarch Design Systemu, a następnie tej docelowej wdrażanej u Klienta, opartej o wytyczne dostarczane przez stylguide. Praca na Design Systemie pozwala pominąć etap projektowania lo-fidelity – płynnie dostarczane są makiety, które ilustrują docelową architekturę systemu i bliski ostatecznemu wygląd. Takie podejście pozwala na zdecydowanie bardziej jasny i konkretny feedback ze strony interesariuszy, kierowników projektu, product ownerów, analityków, a iteracje na projekcie przebiegają znacznie sprawniej. Pozwala także, już na etapie wstępnego projektu określić jego wykonalność przez development i dokonać wstępnej wyceny realizacji. Oparcie całego produktu o Comarch Design System pozwala na szybkie i bezproblemowe przełożenie wersji produktowej na wersję wdrażaną w brandingu Klienta.

Wracając jednak do eksperymentowania. Niejednokrotnie zaczyna się od oczekiwań jedynie lekkiego Redesignu systemu/aplikacji, zwłaszcza, że często wychodzimy od założenia, że użytkownicy nauczeni systemu, którego używają od lat – mają swoje przyzwyczajenia. Zmiana natomiast generuje obawy ze względu na potencjalny czas na jej opanowanie i poznanie systemu na nowo. W tym miejscu pojawia się jednak ze strony projektanta, propozycja niekiedy dość radykalnych zmian, zupełnie nowego podejścia do architektury systemu i sposobu nawigowania po nim. Nie jest oczywiście tak, że jako projektanci się nie mylimy, i że po dostarczeniu nowej wersji systemu nie okaże się, że użytkownicy jednak wolą mieć znaczenie większe zagęszczenie informacji na ekranie, a ich tabele o układzie horyzontalnym mają scrollować się niemal w nieskończoność. W tym miejscu, żeby te niepewność rozwiać jak najszybciej, projektanci przygotowują prototyp części systemu i przekazują go do Laboratorium badawczego, by zderzyć eksperymentalną wizję z docelowym użytkownikiem, jeszcze zanim prace implementacyjne osiągną zaawansowany poziom. Laboratorium badawcze dostosowuje odpowiednie metody. W przypadku Faktoringu zastosowano testy zadaniowe polegające na realizacji konkretnych zadań w systemie wraz z semi-ustrukturyzowaną rozmową pogłębioną, mającą na celu pozyskanie informacji w zakresie codziennych obowiązków respondenta,  w tym najczęściej realizowanych operacji w systemie faktoringowym i dotychczasowych doświadczeń związanych z korzystaniem z obecnego systemu faktoringowego i innych systemów.

Badanie przebiegły w dwóch iteracjach i mimo iż wykazały pewne błędy, dowiodły także, że obrany kierunek jest właściwy. Wskazane przez respondentów błędy zostały spriorytetyzowane, a następnie korygowane w dalszych pracach projektowych. W trakcie procesu projektowego korzystamy również z innych narzędzi badawczych takich jak wywiady pogłębione, badania fokusowe czy ankiety ilościowe. Niezbędne są one w momencie, gdy musimy sięgnąć po wiedzę z zakresu charakteru pracy użytkownika, jego potrzeb czy bolączek.

Przyjęty w realizacji projektu model pracy wymaga dużej elastyczności i braku oporu na częste iteracje i wynikające z nich korekty, a niekiedy duże zmiany. Mają one szczególnie intensywny charakter na początku projektu, gdy dopiero wypracowujemy koncepcję systemu. Z czasem, gdy cały zespół ma wspólne wyobrażenie tego, co jest wytwarzane, te prace przebiegają znacznie sprawniej i efekty projektowania coraz trafniej odpowiadają wspólnym oczekiwaniom. Mimo iż nie zawsze jest to łatwa metoda dostarczania i angażuje absolutnie wszystkich interesariuszy, daje najlepsze rezultaty, które spotykają się z pozytywnym odbiorem klientów:

Chciałbym napisać na temat nowej funkcjonalności w nowym systemie. Najkrócej jak można napisać to : WOW !!!