Zastanawiasz się nad włączeniem do procesu scrumowego i zespołu developerskiego UX designera? Świetnie! Ta rola bardzo się przyda, a sam model pracy dobrze wpisuje się w filozofię agile. Iteratywność, elastyczność, szybkie wytwarzanie, optymalizowanie – to chleb powszedni UX-owców. Aby jednak pomysł się sprawdził w praktyce, musisz pamiętać o kilku zasadach. Poniżej przedstawiamy listę 10 reguł, które stworzyliśmy w Usability LAB i RST Software Masters bazując na własnym doświadczeniu w takich projektach.


1. UX designer musi być faktycznie częścią zespołu scrumowego.

 

Jeżeli zależy Ci na efektywnej współpracy specjalisty od UX i programistów, muszą być oni rzeczywiście członkami jednego zespołu – pracować w podobnych godzinach, spotykać się, brać udział w planowaniu sprintów, refinementach, review z klientem i retrospekcjach. Najlepiej zadbać o jego pełną dostępność, a jeżeli włączenie go do prac zespołu na pełen etat jest niemożliwe, należy precyzyjnie ustalić zasady jego dostępności. Warto też od razu na wstępie określić zasady współpracy, ze szczególnym uwzględnieniem tego co i jak designer będzie dostarczał reszcie zespołu.

2. Zespół musi rozumieć rolę UX designera.

 

Niepewność, podejrzliwość, w najlepszym przypadku zdziwienie. Takie odczucia mogą towarzyszyć zespołowi developerskiemu, do którego po raz pierwszy włączony zostaje UX designer. “Skoro do tej pory dawaliśmy sobie radę bez niego i projekty były zawsze “dowiezione”, po co nagle kolejna osoba na pokładzie. I co on będzie robił? Pouczał nas? Dyrygował nami? Sprawdzał naszą robotę?”. 

 

Nic dziwnego, że UX designer wchodzący do zespołu, w którym nikt wcześniej z takim specjalistą nie pracował, może poczuć się jak piąte koło u wozu. Nic, tylko zanucić “I co ja robię tu? Co ja tutaj robię?”. Dlatego rolą osoby tworzącej zespół scrumowy jest przedstawienie nowego członka zespołu nie tylko jako człowieka, ale jako specjalisty, który ma konkretne zadania do wykonania. Pamiętaj przy tym – nie każdy developer może być tych zadań świadom, dobrze więc opowiedzieć pokrótce, czym kolega od UX-a będzie się zajmował. Jeżeli sam nie do końca to rozumiesz, oddaj głos głównemu zainteresowanemu :).

3. UX designer musi rozumieć scruma.

 

To działa w dwie strony. Chcesz, aby programiści wiedzieli, po co dołączył do nich UX-owiec, ale chcesz też, aby on rozumiał, jak pracuje zespół developerski. Jeżeli nigdy wcześniej nie pracował w scrumie, musisz zaznajomić go z metodyką, wyjaśnić, kim jest PO i scrum master oraz czym jest sprint i jego składowe (np. retro, review, refinement i planowanie), wreszcie czym jest Minimum Viable Product (MVP).

 

Bez tego będziesz miał na pokładzie designera, który będzie starał się dostarczyć to, do czego był do tej pory przyzwyczajony – w pełni funkcjonalną makietę UX, dopieszczoną pod każdym względem, przetestowaną z użytkownikami, pobłogosławioną przez Klienta i gotową do wdrożenia. A Ty potrzebujesz, żeby Twój nowy nabytek zmienił dotychczasowe myślenie i zaczął działać w duchu agile.

4. UX designer powinien mieć bardzo dużą wiedzę o produkcie, wymaganiach i potrzebach biznesowych

 

OK, może nie najlepszą, ale na pewno na równi z PO. Bez niej nie będzie możliwe stworzenie właściwych przepływów i zaprojektowanie makiet, które posłużą developerom. Pamiętaj – klient może przyjść z briefem, ze spisanymi wymaganiami, ale nie może to być jedyne źródło prawdy. Jeżeli masz w projekcie przewidziane miejsce dla UX designera, musisz zaplanować też wstępny etap prac, który poprzedza właściwy start developerki.

 

Zanim UX-owiec odpali program typu Axure czy UX Pin, a nawet zanim sięgnie po ołówek i kartkę papieru, by naszkicować pierwsze makiety, czekają go fazy “Discovery” i “Define”. W pierwszej z nich stara się zrozumieć istniejący produkt bądź też założenia nowopowstającego, przeprowadza research konkurencji, a jeżeli to możliwe, spotyka się również z użytkownikami, poznając ich obecne doświadczenia z produktem lub oczekiwania wobec niego. W fazie drugiej określa – najlepiej przy współudziale klienta, np. podczas jednego lub kilku warsztatów – wymagania, jakie produkt musi spełniać. Tworzy persony, scenariusze użycia, pożądaną “podróż klienta” (customer journey). Innymi słowy, wraz z klientem współtworzy to, co będzie podstawą MVP i backlogu.

5. Projektowanie UX powinno wyprzedzać development.

 

Fazy “Discovery” i “Define” oczywiście trwają. Ile – zależy od projektu i od tego, czy wprowadzamy na rynek nowy produkt (wtedy odpadają np. testy obecnego rozwiązania z użytkownikami, a w przypadku innowacyjnego pomysłu również przegląd konkurencji), czy też działamy z już istniejącym. Jakby nie było, w tym czasie developerzy nie będą mieli jeszcze zbyt wiele do roboty i dobrze o tym pamiętać. 

 

Jeżeli jest taka możliwość, warto ich również włączyć w część tych prac przygotowawczych, np. w warsztaty z klientem. Dzięki temu lepiej zrozumieją produkt, potrzeby użytkowników, wymagania biznesowe. Jeżeli takiej możliwości nie ma, pamiętaj, że koniecznie trzeba przedstawić im efekty tego etapu prac UX-a. I nie chodzi o zwykłe przesłanie materiałów czy linka do nich, nie łudź się, że oni to przeczytają. Zorganizuj spotkanie, na którym specjalista opowie o tym, co się udało wytworzyć, i jaki ma to wpływ na dalsze prace.

 

No dobra, a co potem? Startujemy faktyczny proces scrumowy, czyli zakładamy backlog i organizujemy pracę w sprintach. Teraz UX designer i developerzy mogą – i powinni – pracować ramię w ramię, przy czym pamiętajmy – nic nie powstaje w 5 minut. UX-owiec potrzebuje czasu na wymyślenie i zaproponowanie rozwiązania, developerzy potrzebują czasu na wdrożenie. A jednocześnie nie chcemy mieć przestojów i sytuacji, w których jedni czekają na drugich. 

 

Planując pierwsze sprinty miejmy na uwadze to, że UX-owiec musi wytworzyć podstawę do pracy developerskiej. Im szybciej powstanie ten zaczyn, tym szybciej programiści będą mogli przystać do działania – dlatego ważne jest, żeby dzielić prace UX-a (tak samo jak developerów) na pojedyncze, nie za obszerne historie. Czas oczekiwania na pierwsze makiety można spożytkować na przygotowanie środowiska developerskiego. Gdy UX designer będzie miał pierwsze widoki, warto omówić je wspólnie, by wdrożenie odbywało się w oparciu o materiał przez wszystkich zaakceptowany.

 

W necie mówi się często o podejściu „sprint ahead”. Znaleźć można chyba tyle samo głosów za, jak i przeciw, a prawda, jak to zwykle bywa, leży zapewne gdzieś pośrodku. Z mojego dotychczasowego doświadczenia mogę powiedzieć, że najlepiej sprawdzał się model następujący: na początku sprintu do jego planowania wykorzystywana była aktualna makieta, zawierająca funkcjonalności niezbędne, by mógł zostać osiągnięty cel sprintu. Wstępnie ustalaliśmy też, co z backlogu weźmiemy na kolejny etap. W trakcie sprintu UX designer poświęcał czas na konsultowanie bieżących prac przy realizacji celu oraz pracował nad dalszymi widokami. W połowie sprintu odbywał się refinement, podczas którego doprecyzowywane były historie na nadchodzący sprint, a także prezentowana makieta UX wspierająca te historie. Jeśli okazywało się, że coś wymaga poprawy lub zmiany albo że będzie potrzebny jeszcze jakiś widok, był czas do końca sprintu, aby to wykonać i na planowanie dostarczyć kompletną (na dany etap oczywiście) makietę.

 

Udostępnij
Czy ten artykuł był pomocny?
Tak0
Nie0