Mariaż Agile i UX – dlaczego to takie trudne?

Projektanci UX nie są wpisani w manifest agile, a jednak ich praca w zwinnych zespołach jest niezwykle ważna. Chodzi nie tylko o to, by tworzyć produkty zwinnie, ale żeby robić je dobrze. Rozwiewamy więc cztery mity na temat udziału UX designerów w agile. Przekonacie się, że jest nieoceniony.

Metodologie zwinne pierwotnie nie obejmowały projektowania doświadczeń użytkownika ani nie uwzględniały roli UX designera. Zamiast tego zespoły zwinne, ulepszając produkty, polegały na opiniach klientów i interesariuszy i iteracjach. Jednym z powodów, dla których UX design jest nieobecny w podejściu Agile, jest to, że zostało ono opracowane przez developerów dla developerów. Miało ulepszyć istniejący w tamtym czasie model waterfall, czyli model kaskadowy, w jakim pracowały zespoły programistów nad dużymi projektami. Pomijanie roli projektanta w zespołach zwinnych może więc wynikać z założenia, że metodologie zwinne dotyczą wyłącznie części procesu obejmującej faktyczne tworzenie kodu. A nie jest to przecież jedyny ważny etap! Decydowanie o tym, co zbudować i jak powinno to działać dla użytkowników, jest tak samo ważne, jak zrobienie tego dobrze. Nie ma sensu tworzyć niewłaściwej bądź niepotrzebnej rzeczy w szybki i efektywny sposób.

Manifest Agile ukazał się w roku 2001, a już narosło wokół niego sporo mitów i nieporozumień. Większość z nich jest przyczyną pewnych antywzorców i trudności, na jakie napotykają projektanci UX, kiedy wcielają w życie ideę User-centered design w zespołach agile’owych. Przyjrzyjmy się zatem tym błędnym przekonaniom w odniesieniu do podejścia Agile.

Faktem jest, że metodologie zwinne niejednokrotnie pomagają zespołom budować produkty cyfrowe szybciej, niż mogłyby to zrobić w procesie kaskadowym. Problem w tym, że „szybciej” nie jest głównym celem zwinnego podejścia, a czasem może być wręcz szkodliwe. Jeśli biegniemy w złym kierunku, bieganie szybciej tylko oddali nas od miejsca, w którym chcieliśmy się znaleźć. Agile mówi o szybkim oddawaniu oprogramowania lub jego części w ręce użytkowników. A stąd bardzo łatwo o nadinterpretację w postaci: „OK, oddajmy to użytkownikom tak szybko, jak się da, i przejdźmy do kolejnej rzeczy”. A przecież celem podejścia zwinnego jest szybkie przedstawienie użytkownikom efektów pracy po to, abyśmy mogli uzyskać feedback na ich temat i stale je ulepszać.

W takich zespołach badacze i projektanci UX często pracują coraz szybciej, by stale dostarczać nowych elementów do developmentu. Programiści i management skupiają się niemal wyłącznie na szybkości i wykresach burndown, a głównym kryterium sukcesu jest liczba dostarczonych funkcji. Takie zespoły często przekształcają się w tak zwane feature factory, które po prostu opracowują funkcjonalności jedna po drugiej, bez iteracji lub choćby mierzenia efektywności.

Takie podejście może skutkować ogromną ilością długu technicznego i długu UX, ponieważ cały wysiłek idzie w tworzenie nowych rzeczy tak szybko, jak to możliwe, a nie zastanowieniu się, jak wszystko to do siebie pasuje. Można czasem spotkać się z sytuacją, gdy projektanci narzekają, że nie mają czasu na przemyślenie projektu lub przeprowadzenie testów z użytkownikami. Warto w tej sytuacji pytać zespół, skąd będzie wiedział, czy budowana funkcjonalność okaże się sukcesem? Jakie będą jego oznaki? Jak to zmierzymy? Warto też zwracać uwagę na wcześniej zbudowane funkcje. Jeśli zespół spieszył się w ostatnich sprintach z dostarczeniem nowych funkcjonalności, należy dowiedzieć się, jak radzą sobie one w zetknięciu z użytkownikami. Jeśli nie mamy takich informacji, może warto przeprowadzić badania lub analizy, aby dowiedzieć się, czy w ogóle warto było je tworzyć. Zrozumienie pożądanego rezultatu danego feature’a pomoże w przeorientowaniu zespołu na myślenie nie tylko o tym, co sprawia, że coś jest zrobione, ale także o tym, co sprawia, że coś jest użyteczne dla końcowego użytkownika. W ten sposób, jeśli funkcjonalność nie osiąga pożądanego rezultatu, istnieje dobry powód, aby kontynuować pracę nad nią, aż faktycznie osiągnie ona cel, a nie tylko zostanie wdrożona.

To przekonanie jest najtrudniejsze do zrozumienia, bo przecież idea, że powinniśmy otrzymywać stałą informację zwrotną od użytkowników, jest zawarta w Agile Manifesto. Niestety, choć niektóre zwinne zespoły dobrze radzą sobie z uzyskaniem informacji zwrotnych na temat już zreleasowanych produktów, w ich procesach często nie ma miejsca na badania nastawione na odkrywanie potrzeb i innowacje w produkcie.

Najczęstszym sposobem, w jaki objawia się to w zespołach, są słowa: „Nie mamy czasu na badania” i przydzielanie projektantom UX zadania „tworzenia makiet” w ciągu kilku dni, bez absolutnie żadnego czasu na testy z użytkownikami. Dzieje się tak kiedy badania postrzegane są jako praca dla odrębnego zespołu lub jakiegoś osobnego stanowiska. Nawet jeśli istnieje zespół interdyscyplinarny, składający się z projektantów, programistów i specjalistów od produktu, badania często są „umieszczone” gdzieś poza zasobami zespołu i wykorzystywane tylko w określonych celach. Niestety skutkuje to tym, że zespół przyzwyczaja się do myślenia o badaniach jako o czymś wykonywanym przez kogoś innego.

Drugim powodem może być przekonanie, że badania muszą być czasochłonne, co za tym idzie, traktuje się je jak duże „wydarzenie” w życiu projektu. Czasami zespoły rekompensują sobie ten problem, zaczynając od sprintu zero, co jest po prostu pojedynczym sprintem, poświęconym badaniom i projektowaniu, zanim zespół techniczny zacznie development. A przecież nie wszystkie badania i projekty mieszczą się w jednym sprincie.

Aby to naprawić, musimy uwzględnić interdyscyplinarny i wielofunkcyjny charakter zwinnych zespołów, a to oznacza większe zaangażowanie wszystkich w badania. Zamiast postrzegać je jako coś realizowanego przez kogoś z zewnątrz lub przez jedną wyznaczoną osobę, cały zespół powinien być ich właścicielem i wspólnie przeprowadzać eksperymenty i badania, aby zebrać informacje i dane. Może to działać na wiele sposobów i nie musi wcale oznaczać, że prace techniczne zostaną wstrzymane, kiedy każdy developer uda się na wywiad z użytkownikiem. Potrzebne jest raczej poszukiwanie sposobów na zautomatyzowanie zbierania feedbacku od userów w takim zakresie, jaki jest możliwy, oraz nadanie pewnego rytmu, jeśli chodzi o interakcję z użytkownikami w postaci testów użyteczności czy wywiadów pogłębionych. Może być to na przykład metoda „Four on Friday”, czyli umawianie wywiadów z użytkownikami na jeden dzień sprintu (na przykład piątek), zapraszanie osób w różnych rolach do obserwowania tych sesji i dbanie w ten sposób o stały przyrost wiedzy o użytkownikach w całym zespole. Należy pamiętać, że badania są niezbędne jeśli chcemy tworzyć produkty, które rozwiązują rzeczywiste problemy, a zrozumienie użytkowników nie jest czymś, co zespół może zlecić komuś innemu.

Iteracyjny i inkrementalny charakter pracy w zwinnych zespołach może powodować kolejne nieporozumienie: że Agile uniemożliwia całościową wizję i design produktu. W zespołach agile’owych historyjki użytkownika często są dzielone na małe fragmenty lub zadania. Może to oznaczać, że projektant otrzyma jedno z tych zadań i zostanie poproszony o przygotowanie makiety. Wówczas próba stworzenia pojedynczego ekranu dla konkretnej funkcji przy braku jakichkolwiek badań z użytkownikami lub ogólnego kontekstu może skutkować raczej kiepskim efektem. Aby stworzyć naprawdę użyteczny interfejs, projektant potrzebuje dobrego zrozumienia i wglądu w to, jak wszystko będzie działać w pozostałej części produktu. Samo zbudowanie pojedynczego ekranu, w izolacji od całości, prowadzi do konieczności późniejszych przeróbek.

Można do tego podejść na kilka różnych sposobów. Wiele zwinnych zespołów najpierw buduje najprostszą możliwą rzecz, która będzie działać. Następnie, gdy potrzebujemy czegoś bardziej złożonego, chcemy przerobić funkcjonalność (interfejs i / lub kod), włącza się nowe elementy. Zaletą takiego podejścia jest to, że nigdy nie wykonujemy więcej pracy, niż jest to absolutnie konieczne. Dla użytkowników prosta wersja może okazać się w zupełności wystarczająca albo w przyszłości mogą oni przejść na zupełnie inny sposób korzystania z funkcjonalności, co w obecnych czasach jest dość częste. Szybki rozwój technologii wpływa na zmianę wielu naszych nawyków. Wówczas dotychczasowy sposób korzystania z danej funkcji, może stać się przestarzały. Konieczne okaże się więc zbudowanie jej od nowa.

Czasami jednak takie rozwiązanie może być kosztowne. Zmiana wszystkiego za każdym razem, gdy chcemy dokonać niewielkiej poprawki w interfejsie, zajmie znacznie więcej czasu niż zrobienie czegoś dobrze za pierwszym razem. W wielu przypadkach właściwym rozwiązaniem jest poświęcenie większej ilości czasu przez projektanta na wykonanie tylu makiet i propozycji rozwiązań, ile to konieczne, aby zrozumieć, który mały element funkcjonalności możemy zbudować w następnej kolejności. Czasami konieczne jest wykonanie całościowego projektu, by zrozumieć, dokąd zmierzamy. Nie musimy projektować idealnie wszystkiego od razu. Nie chodzi o wykonanie dopracowanych makiet już na samym początku. Powinniśmy jednak wiedzieć, czy w efekcie nie będziemy musieli budować tej samej funkcji pięć razy, i jeśli możemy, starać się tego uniknąć. Tu ścisła współpraca i dobra komunikacja pomiędzy projektantem a developerami już od samego początku pracy nad danym projektem jest nieoceniona.

Kiedy projektanci, ze względu na przykład na tempo pracy nad zadaniami na bieżąco realizowanymi przez zespół, nie mają czasu na prawdziwe badania lub szerzej zakrojoną pracę projektową, mogą znaleźć się w sytuacji, w której czują, że nie mają czasu na tworzenie artefaktów typowych dla pracy UX Designera. Czasami nie jest to takie złe rozwiązanie - nie każdy projekt i nie na każdym etapie wymaga mockupów pixel-perfect, zestawu kilku person i mapy Customer Journey. Wskazana jest kreatywność i elastyczność w tym, jak definiujemy i jak dobieramy artefakty przez nas dostarczane.

Ponownie mit o braku deliverables, czy też artefaktów, bierze się z przekonania o niewystarczającej ilości czasu lub faktycznego jego braku. Jako projektanci, w czasie studiów lub w pracy agencyjnej poświęcamy mnóstwo czasu na samodzielne tworzenie artefaktów, które są dopieszczone pod względem wizualnym i dopracowane koncepcyjnie. Dzieje się tak dlatego, że jesteśmy tam oceniani za oba te aspekty. W zespołach zwinnych artefakty dostarczane przez UX designera w większości przypadków są wyłącznie środkiem komunikacji a nie celem samym w sobie. A ponieważ dobre zespoły agile’owe są z natury interdyscyplinarne i ludzie ściśle ze sobą współpracują, może to w naturalny sposób skutkować zmniejszeniem zapotrzebowania na bardzo szczegółowe oraz dopracowane artefakty.

Inne czynniki, takie jak: posiadanie solidnego design systemu oraz upewnienie się, że wszyscy w zespole rozumieją cele użytkownika i cele biznesowe dotyczące danej funkcjonalności, powodują, że design może być przekazany nawet w formie pisemnej lub w formie rozmowy między projektantem a developerem.

Należy też inaczej spojrzeć na sposób przekazywania wyników badań UX. Zamiast pełnego raportu z badań obszernego na 100 slajdów, którego stworzenie zajmuje miesiąc, ich wyniki mogą pochodzić bezpośrednio z sesji analizy i syntezy wyników z udziałem całego zespołu. Może to być dwu, trzystronicowe podsumowanie najważniejszych wniosków i rekomendacji, które łatwiej będzie wdrożyć i z którym cały zespół będzie w stanie się zapoznać.

Żadna z tych rzeczy nie oznacza jednak braku artefaktów. Zadaniem projektanta lub badacza UX nadal jest przekazywanie informacji innym członkom zespołu i dbanie o przyrost wiedzy o użytkownikach, a to często wymaga środka komunikacji. Najważniejszą rzeczą, o której należy pamiętać, jest elastyczność podejścia. Nie każda zmiana funkcji wymaga w pełni interaktywnego prototypu lub doskonałej makiety. Nie każde badanie należy opisać w dużym raporcie. Zamiast domyślnie tworzyć maksymalną ilość dokumentacji, warto zadać pytanie: Jaka jest minimalna rzecz, którą muszę zrobić, aby przekazać wszystko, co powinienem przekazać? Być może jest to rozmowa z deweloperem i arkusz w Excelu z tekstami, który będzie używany do komunikatów o błędach. Może to być dobrze napisana historyjka użytkownika i kilka wireframe’ów. Być może będzie to bezpośrednia współpraca z programistą w celu rozwiązania problemu podczas pisania kodu. Ale może jest to dopracowana co do piksela makieta i w pełni interaktywny prototyp – one również mają zastosowanie.

Musimy traktować dostarczane przez nas – projektantów – artefakty tak, jak traktujemy każdy produkt. Zrozumieć więc, czego potrzebują użytkownicy, w tym przypadku koledzy i koleżanki z zespołu, i znaleźć najskuteczniejszy sposób, aby im to zapewnić.

I ostatnia ważna kwestia. Czasami podejmowane przez nas decyzje muszą być udokumentowane. Dzięki temu będziemy pamiętali, dlaczego je podjęliśmy i jakie dokładnie były. Wszystko po to, abyśmy mogli porozumieć się z przyszłymi wersjami samych siebie lub w sytuacji, kiedy skład zespołu się zmieni.

Chociaż nie ma dwóch takich samych zespołów, możemy znaleźć pewne wspólne wzorce. Dobre zespoły agile’owe są interdyscyplinarne i autonomiczne, pracują w sposób iteracyjny i inkrementalny, umożliwiają płynną komunikację oraz pracują nad udoskonalaniem produktu, a także pracy zespołu. Być może najtrudniejszą częścią nauki pracy w zwinnym zespole dla projektanta jest właśnie fakt, że nie ma dwóch identycznych zespołów, nawet w ramach tej samej organizacji. Nie ma też idealnego stylu projektowania. Pozostaje tylko powtarzanie, uczenie się i dostosowywanie. Ważne, abyśmy zrozumieli, że nie każda technika czy metodyka pracy będą działać idealnie w każdym zespole, w każdym momencie. W zależności od tego, jakie wzorce lub antywzorce prezentuje dany zespół, potrzebne może być wypróbowanie różnych metod dobrego projektowania i badań oraz gotowość na to, aby w te poszukiwania włożyć nieco czasu i wysiłku.