Większość zespołów zajmujących się tworzeniem produktów cyfrowych już dawno przestawiła się z modelu kaskadowego (waterfall) na agile lub lean, co ma wiele zalet. Jednak często nie wiedzą, jak włączyć projektantów UX w taki system pracy. W tym artykule wyjaśnimy ci, w jaki sposób UX-owcy mogą odnaleźć się w takiej pracy.

System kaskadowy (tj. waterfall) był wykorzystywany przez wiele lat. System nadal sprawdza się w przypadku, kiedy mamy sztywno określone ramy projektu. Niestety ten model nie jest dosyć plastyczny. Nie przewiduje zbierania feedbacku od użytkowników, dostosowywania w kodu czy dokonania zmian w projekcie zanim nie ukończymy wszystkich etapów pracy.

Z tego względu firmy tworzące produkty cyfrowe odrzuciły pracę w systemie kaskadowym na rzecz podejścia zwinnego (Agile), czy zdecydowały się na prowadzenie projektów, wykorzystując metodę szczupłą (lean). Obie metody prowadzą do wypracowania sprawnego procesu produkcyjnego. Istnieje wiele materiałów opisujących lean i agile, ale jak to wszystko ma się do projektowania UX?

Agile i lean w pracy nad UX?

Metody zwinne i szczupłe sprawdzają się na wielu płaszczyznach produkcji oprogramowania – od ustalania obowiązków po utrzymanie harmonii w zespole. Specjaliści IT próbują zaadaptować je także do pracy nad user experience.

Niektóre z założeń lean i agile świetnie sprawdzają się w usprawnianiu pracy nad UX, a w szczególności te, które mówią o otwartej komunikacji w zespole, iteracyjnym systemie pracy i koncentracji na użytkowniku końcowym.

Agile i projektowanie UX

Podejście zwinne jest praktykowane w zespołach produktowych, które tworzą rozwiązania cyfrowe, ponieważ pozwala na szybkie dostosowanie się do zmiennej rzeczywistości. Szereg takich firm zintegrowało agile z UX-em, przede wszystkim po to, aby zwiększyć przepływ komunikacji w zespole, łącząc zwinne zarządzanie z metodami projektowania UX.

Dzięki temu UX-owcy mogą wiele zyskać. Ze względu na to, że podejście zwinne zakłada iteracyjny system pracy, projektant UX ma szansę na usprawnianie swoich projektów z każdą iteracją projektu. Co więcej, trzymając się agile, programiści mogą pracować nad designem od samego początku. To bez wątpienia wymarzony scenariusz dla projektanta UX.

Podejście zwinne z zasady przyjmuje, że należy słuchać, co o produkcie mają do powierdzenia osoby, które będą z niego korzystać. Pierwsza z 12 zasad agile odnosi się do dbania o satysfakcję użytkownika. Idąc dalej, niektóre z proponowanych technik priorytetyzowania wymagań i funkcjonalności stawiają potrzeby użytkownika w centrum przy planowaniu pracy (np. model systemico).

Czytając to wszystko, może ci się wydawać, że UX zyskuje wtedy automatycznie na wartości. Przecież podejście human-centerd design stawia również stawia użytkownika w centrum. To musi oznaczać, że łatwiej jest nam przekonać innych do wartości UX, jeśli pracujemy w zwinnym środowisku. Czy tak jest naprawdę? Na pewno agile pomaga projektantom UX komunikować się z zespołem i może sprawić, że inni zainteresują się pracą nad UX. Koniec końców agile sprawia, że mamy wspólny cel i nie osiągniemy go bez komunikacji.

Jeden z frameworków opartych na agile – Scrum – przewiduje dzienne standupy, okresowe retrospekcje i wspólne planowanie pracy. To wszystko wspiera współpracę i wymusza zrozumienie, na czym polega projektowanie UX.

Początkowo praca w Scrumie może okazać się stresująca dla zespołu UX i wymaga wypracowania wspólnego flow.

Prawdopodobnie podyktowane jest to tym, że nie brano UX pod uwagę, kiedy opracowano Scruma. Zwinne podejście skupia się na developmencie – nie na pracy przed pisaniem kodu. Okienka projektowe są dosyć ciasne, szczególnie gdy dołączymy do nich testy designu z użytkownikami. Dlatego UX-owcy mogą wzdrygać się na myśl o pracy w Scrumie.

Z naszego doświadczenia wynika, że można dostosować pracę nad user experience do Scruma – dojrzałe zespoły agile radzą sobie z tym bardzo dobrze. Jeżeli chcesz dowiedzieć się więcej o integracji pracy UX-owców w Scrumie, przeczytaj nasz artykuł: Jak zintegrować UX i UI ze Scrumem?

Lean UX dla zespołów agile

Lean UX promowany jest w książce o tym samym tytule autorstwa Jeffa Goethelfa. Wbrew pozorom ta książka nie jest wyłącznie o projektowaniu user experience, a o tworzeniu produktów cyfrowych od początku do końca. Lean UX polega na połączeniu trzech sfer.

  1. projektowania user experience (razem z systemem design thinking)
  2. zwinnego wytwarzania oprogramowania, które przed chwilą poznaliśmy
  3. podejścia lean przedstawionego w książce Erica Riesa “Lean Startup Management”

To ostatnie w wolnym tłumaczeniu oznacza podejście szczupłe. Dlaczego taka nazwa? Jest to podyktowane tym, że lean nie znosi marnotrawstwa. W tej metodyce chodzi o to, aby wykorzystać najefektywniej swoje zasoby.

Ciągłe doskonalenie

Projektowanie szczupłe składa się z powtarzających pętli: „buduj – zmierz – wnioskuj”. Ta pętla to seria eksperymentów, które pozwolą nam sprawdzić na bieżąco, czy podejmujemy dobre decyzje. Jak się za to zabrać? Wybieramy, jaki problem chcemy rozwiązać i zakładamy jakie funkcjonalności dany produkt powinien mieć, aby spełniać podstawowe potrzeby użytkowników. Budujemy to, a następnie mierzymy, czy działa. Wyciągamy wnioski, udoskonalamy swoje rozwiązanie. I tak w kółko.

Pewnie przypomina ci to koncepcję MVP. Tak, MVP, czyli Minimum Viable Product ma swoje korzenie w lean (dokładnie pochodzi z Lean Startup Management) i służy do walidacji pomysłu na biznes.

Budujemy minimalny, wykonalny produkt, który ma za zadanie sprawdzić, czy nasz pomysł ma wartość rynkową. Zbieramy feedback od użytkowników, który podpowie nam, czy warto inwestować w dalszy rozwój naszego produktu, czy lepiej z niego zrezygnować. Jeśli tak, to budujemy bardziej skomplikowaną wersję naszego rozwiązania i mierzymy efektywność.

Inaczej mówiąc, zaczynamy od działania z minimalnym planem, ponieważ debatowanie nad możliwym rozwojem sytuacji nie da nam satysfakcjonujących odpowiedzi. Potrzebujemy działać. Doprecyzujemy szczegóły funkcjonowania naszego produktu po zbadaniu jego wartości. Dzięki takiemu podejściu zmniejszamy ryzyko, że zmarnujemy czas i pieniądze budując niewłaściwe rozwiązanie. Każdy projekt zaczyna się od założeń. MVP pozwala nam przetestować te założenia bez dużych inwestycji w projekt.

A co z tymi z nas, którzy mają już produkt cyfrowy? Podejście lean UX przyda się także w codziennej pracy nad produktem. Przejdźmy do innych benefitów, które obiecuje nam lean UX.

Mniej dokumentacji na rzecz komunikacji

W przypadku lean UX stawiamy na współpracę. Dokumentacja nie ma wielkiego znaczenia, a wręcz odchodzimy od dokumentacji na rzecz zwiększonej komunikacji w zespole. Może to wydawać się nie do wykonania w dużych zespołach, ale w takim przypadku powinniśmy podzielić nasz zespół na podzespoły.

Twórcy lean UX uważają, że zespoły pracujące nad projektem powinny być dosyć małe (do 10 członków) i nie powinny składać się z samych projektantów (powinny być interdyscyplinarne). To kultywuje wspólne zrozumienie i usprawni komunikacje.

Dokumenty opisujące jak będą wyglądały i działały funkcje to rzecz drugorzędna. Ważne jest to, aby wszystkie osoby, które pracują nad projektem, rozumiały użytkownika, problem i kontekst strategiczny tego, co zamierzają stworzyć. Komunikacja jest kluczem do sukcesu.

A co ze zbieraniem informacji przed startem projektu? Przy zwinnych metodykach nie ma potrzeby gromadzenia masy danych przed rozpoczęciem pracy nad produktem. W myśl zasady „learn as you go” nie musimy marnować zasobów na obudowanie się danymi, które ktoś musi zebrać, przeanalizować, przedstawić w formie slajdów – możemy szybko zacząć pracę i opierać się na założeniach.

Zorientowanie na wyniki

Podejście lean UX wymaga od zespołu projektowego wyjścia do użytkownika, zebrania feedbacku na temat rozwiązania i na tej podstawie przeprowadzenia kolejnej iteracji – to idealne środowisko dla designera. To, czy nasz produkt zmienił coś w zachowaniu użytkownika końcowego lub w otoczeniu, ma o wiele większe znaczenie niż to, czy wypuściliśmy nową funkcjonalność. Outcome jest bardziej wartościowy niż output.

Naszym wskaźnikiem sukcesu są wyniki biznesowe, zarówno te jakościowe, jak i ilościowe. Zmiana musi być znacząca i mierzalna i wpływać bezpośrednio na udoskonalenie pomysłu wyjściowego poprzez wpływ na cele końcowe, emocjonalne, doznaniowe lub długoterminowe naszych klientów.

Projektowanie wynika ze współpracy z zespołem

Projektant UX przyjmuje nową rolę. Jest koordynatorem projektu. Projektowanie w rozumieniu lean UX to zadanie kolektywne. Dobrze byłoby, gdyby cały zespół brał aktywny udział, szkicując i omawiając możliwe rozwiązania.

Gdy projekt został przedyskutowany, przeanalizowaliśmy wszystkie pomysły i mamy wspólną wizję tego, co zamierzamy zbudować, projektant jest odpowiedzialny za obróbkę pracy i przygotowanie dokładnego projektu, który zostanie pokazany współpracownikom i interesariuszom.

Tworzenie persony to proces

W przypadku lean UX research nigdy nie jest skończony. Nie potrzebujemy dużej ilości danych, aby zacząć naszą pracę, dlatego wystarczy nam minimalny research, który skonfrontujemy po drodze, poszerzając go o kolejne spostrzeżenia. To samo dotyczy pracy nad personą, czyli sylwetką użytkownika końcowego, mówiącą o jego potrzebach względem naszego rozwiązania.

Lean UX proponuje nam tworzenie proto-person, czyli okrojonej wersji persony, którą będziemy wzbogacać w kolejnych etapach projektu. Proto-persona nie jest oparta o research, czy prawdziwe dane. To tylko wyobrażenia, które trzeba zbadać.

Zaczynamy od wyciągnięcia kartki papieru, wypisania naszych hipotez, co do persony. Potem zbieramy dane i walidujemy nasze założenia. Za każdym razem, kiedy rozmawiamy z użytkownikami, powinniśmy sprawdzać, czy nie musimy niczego dodać, albo zamienić w naszym dokumencie o proto-personie.

Czy Lean UX jest dla mnie?

Lean UX ma wiele zalet. Przede wszystkim pozwala nam na szybkie rozpoczęcie pracy, i uwalnia nas od tworzenia dokumentacji, do której już nikt nie zajrzy. Niestety minusem takiego rozwiązania jest to, że usypia czujność, bo bez aktualizacji tych założeń prawdziwymi danymi zaczynamy projektować w oderwaniu od problemu/branży/userów i tworzymy coś, co nie ma racji bytu.

Lean UX wzmacnia współpracę pomiędzy pracownikami. Działa to przy założeniu, że deweloperzy operują podstawową wiedzą z zakresu UX, a zespół pracuje w jednym miejscu.

Polecielibyśmy lean UX zespołom, które osiągnęły wysoki poziom UX maturity (dojrzałości projektowej) w swojej organizacji.

Jak zintegrować UX z agile?

Nawet jeśli lean UX cię nie przekonuje, nie znaczy to, że nie możesz pracować w agile ze swoim zespołem user experience. Jednak będzie to wymagało wiele pracy od ciebie i reszty – zwłaszcza, gdy twój zespół UX nie ma doświadczenia ze zwinnym podejściem.

Zakres pracy projektanta UX jest dosyć obszerny i obejmuje zdefiniowanie problemu, research potrzeb i analizę zachowań użytkownika oraz stworzenie ścieżki użytkownika i przejrzystej architektury informacji. Cały proces uwzględnia serię testów, aby upewnić się, że rzeczywiście adresujemy problem użytkownika.

Przeprowadzenie całego procesu wymaga czasu, w szczególności gdy nasz zespół jest niewielki lub twoja firma nie może pochwalić się znaczącym poziomem dojrzałości UX. Z tego względu, zanim zintegrujesz UX z systemem zwinnym, zdefiniuj, jakie jest miejsce projektanta w zespole produktowym i odpowiedz sobie, co chcesz tym osiągnąć, dlaczego ci na tym zależy – inaczej, jaki jest twój cel integracji UX z agile.

Tutaj pokażę ci, na co powinieneś zwrócić uwagę w trakcie samego procesu projektowego.

Agile UX na poziomie researchu

Czy twój zespół przeprowadza research za każdym razem, kiedy chcesz wprowadzić nową funkcjonalność lub usprawnić twój produkt? To świadczy o dojrzałości UX w twojej organizacji.

Niestety, kiedy odchodzimy od kaskadowego systemu pracy na rzecz zwinnych metodyk, research często jest pomijany. Nie widzimy w nim wartości. Nie wiemy jak zmierzyć jego efektywność. Boimy się, że spowolni naszą pracę. Ciężko go zaplanować i zmierzyć.

Decydujemy się go wyeliminować, albo przeprowadzamy research, ale po macoszemu, niedbale, nie przykładając wagi do jego rezultatu. A po co? Przecież ważniejsze jest to, aby wypuścić działające oprogramowanie. Wiemy już tyle o naszym rozwiązaniu, że nie potrzebujemy badać rozwiązań konkurencyjnych ani przysłuchiwać się oczekiwaniom użytkowników.

Nie bez powodu przeprowadzamy research przed projektowaniem interfejsu i pisaniem kodu. Research umożliwia nam trzeźwą ocenę sytuacji rynkowej i uniknięcie marnowania czasu na budowę niewłaściwego rozwiązania. Dzięki niemu wiemy, co możemy zbudować, jakie trudności mogą pojawić się na drodzę i jakich efektów możemy się spodziewać.

Nie wystarczy, że będziemy zwinnie podejmować decyzje – musimy iść w dobrym kierunku, aby być produktywnymi. Research pozwala nam wyznaczyć kierunek.

Jak wpisać research do backlogu?

Skoro wiemy, że research ma wartość biznesową, to jak go zaplanować, aby łatwo było go przeprowadzić w wybranej metodyce zwinnej? Zastanów się nad trzema kwestiami:

  1. Co chcesz osiągnąć researchem?
  2. Jaka metoda researchu jest odpowiednia?
  3. Kiedy wiesz, że osiągnąłeś to, co chciałeś? (Definition of Done)

Kiedy jesteś pewien, że masz odpowiedzi na te pytania, możesz dodać research do backlogu. Jeżeli działasz w Scrumie, dodaj UX research jako epic i podziel go na mniejsze user stories. Pokażemy ci, jak się za to zabrać w innym artykule.

W jaki sposób przeprowadzić research?

Twórcy artykułu na UX Matters sugerują, aby projektanci UX rozpoczęli pracę nad wstępnymi szkicami, jeszcze kiedy research nie jest całkowicie skończony. Mogą posiłkować się wiedzą, którą zgromadzili do tej pory, nie zważając, jak bardzo podstawowa to jest wiedza. Nasz design staje się coraz bardziej szczegółowy w miarę, gdy wzbogaca się nasza wiedza.

Koniec końców podejście zwinne opiera się na współpracy, dlatego wszyscy członkowie zespołu muszą ze sobą współpracować – niezależnie od stanowiska. Wymaga to dobrej komunikacji i wysokiej świadomości, na czym polega praca reszty zespołu.

Ważne jest to, abyś odszedł od nadmiernej dokumentacji. To nie jest efektywne. Wystarczy podsumowanie researchu na 1-2 stronach A4, które przekażesz reszcie.

Agile UX na poziomie projektowania

Podobnie ma się z projektowaniem. Tak jak opisaliśmy to wcześniej, projektowanie UX powinno iść ramię w ramię z researchem, ale nie tylko z nim. Developerzy powinni mieć dostęp i wiedzę o przebiegu prac nad projektowaniem, dzieki czemu mogą zacząć się przygotowywać do pisania kodu (lub pisać kod równocześnie, jeśli to możliwe).

Podczas prac nad projektowaniem, skup się na tej części pracy, która wspiera aktualne user story czy job story tego sprintu. Pamiętaj – agile stawia „reagowanie na zmiany ponad podążanie za planem”. Otwartość na zmiany i iteracyjny proces tworzenia oprogramowania to odpowiedź na sprawne włączenie pracy nad UX do zespołu agile’owego. Zrezygnuj z nadmiernej dokumentacji. Tak jak w przypadku researchu rozmawiaj częściej z osobami odpowiedzialnymi za UI design i development.

Skoro mowa o projektowaniu interfejsu, jest jedna rzecz, która zdecydowanie może ułatwić projektowanie UI w zwinnym środowisku. To design system. Zawiera wskazówki projektowania twojego produktu dla każdego, kto jest zaangażowany w pracę nad projektem – projektantów i developerów. Design system znacznie przyspiesza czas potrzebny na stworzenie nowych widoków.

Agile UX na poziomie optymalizacji

Po skończeniu pracy, wprowadzeniu nowej funkcjonalności, redesignie interfejsu lub przychodzi czas na obserwacje i optymalizację doświadczeń użytkowników docelowych. W tym celu analizujemy dane z Google Analytics, Fullstory lub Hotjara, aby sprawdzić, czy użytkownicy napotykają problemy w użytkowaniu sytuacji.

Jest to element pracy projektantów UX, z którego podejście zwinne nas nie zwalniają. Może się okazać, że sposób działania aplikacji wymaga od nas zmian. W takiej sytuacji wpisujemy to do backlogu i nadać im odpowiedni priorytet.

Wielu projektantów UX nie czuje się pewnie w podejściu zwinnym, ponieważ reszta zespołu nie widzi potrzeby powrotu do ukończonego projektu, dlatego optymalizacja UX nigdy nie opuszcza backlogu. Jako fani agile’a wiemy, że nie wystarczy iść do przodu. Musimy poruszać się we właściwym kierunku. Optymalizacja UX wspiera właściwy kierunek.

Ocena doświadczeń użytkowników to nie tylko obserwacja. Czasem musimy wyjść użytkownikowi naprzeciw i przeprowadzić badania satysfakcji. To też część optymalizacji, którą warto zaplanować jakiś czas po wprowadzeniu zmiany.

UX ma wartość biznesową i wspiera ważne dla naszej firmy metryki, a często inwestycja w UX zwraca się z nawiązką (przeczytaj nasz artykuł o ROI z pracy nad UX). Nie rezygnujmy z optymalizacji, ponieważ w ten sposób jesteśmy w stanie na nie wpłynąć.

Czy wprowadzisz Agile UX?

Integracja UX z podejściem zwinnym lub szczupłym nie jest łatwe. Developerzy zazwyczaj spotykają się z agilem, ponieważ jest to gorący temat w ich kręgach. Natomiast projektowanci UX mają własny proces zwany User Centered Design Process. To również proces iteracyjny, jednak ma własne tempo i opiera się o dokładny research, który daje nam szczegółowy obraz sytuacji, którą musimy rozwiązać podczas projektowania. Jednak jeżeli pożądnie zaplanujesz pracę w swoim zespole projektowym, to jesteś w stanie odnieść sukces przy integracji UX z zespołem pracującym w metodyce zwinnej.

Naszym zdaniem problemy we wdrozeniu ux z agile wynikaja na poziomie planowania – źle zaplanowane i wpisane do backlogu taski sprawiaja, że projektanci mają problem z terminowością. Możemy tego uniknąć, jezeli odpowiednio ułożymy user stories (lub job stories). Kiedy mamy dojrzały zespół UX z dużym stażem pracy, problemów nie powinno być.