Jak włączyć UX Designera do SCRUM?

Autor: Bartłomiej Drążkiewicz 25 kwietnia 2022

Scrum nie zawsze jest łatwym wyzwaniem dla UX’owców. Designerzy nie zawsze rozumieją niuanse w procesie scrumowym, a regularne sprinty i bardzo sklaryfikowany model pracy mogą przyprawić ich o migreny. UX często musi udowadniać swoją wartość, żeby efektywniej spełniać swoją rolę, co nie powinno mieć miejsca, dla dobra zespołu i produktu. O czym należy pamiętać przy scumowaniu z designem?

Może Cię zainteresować: Co zrobić, aby ulepszyć UX sklepu internetowego?

Scrum  to proces prowadzenia zespołu w ściśle określonych ramach i założeniach. Zazwyczaj łączy się go ze zwinnymi metodykami działania, zwanymi Agile, choć nie jest to tym samym, co często jest mylone. Scrum to narzędzie mające na podstawie frameworków dążyć do efektywnego przyrostu rozwoju produktu poprzez skalkulowane i wysublimowane  działania oparte na priorytetyzacji celów. Jest to także empatyczne angażowanie członków zespołu oraz dostrzega się w nim rolę empirycznego badania potrzeb zespołu i produktu. Rozwój efektów pracy podzielony jest na co najwyżej miesięczne iteracje, zwane sprintami.

Zazwyczaj trwają one jednak dwa tygodnie. Scrum Master to jak pisze JustJoin.It prorok zmiany, który nie tylko przewodzi zespołem, ale uczy go poznawać nowe ścieżki pracy, określać mocne strony i słabości. Rolą SM jest także poznanie specyfiki pracy każdego z członków i i indywidualna pomóc im w rozwoju. Scrum to przede wszystkim empiryczny analityk, który dyscyplinuje zespół oraz gromadzi dane na jego temat, by móc lepiej planować sprinty i komunikować się z Product Ownerem. 

Problemy z UX w teamie scrumowym

Scrum Mastera i jego zespół powinny cechować: transparentność, sprawdzalność i implementacyjność. Są to również cechy odpowiadające projektantom, a gdy dodamy do tego fakt, że obie grupy bazują na doświadczeniach, dostrzeżemy pewne pokrewieństwo. Jak jednak słusznie zauważa mohi.to, na tym się kończy. Designerzy muszą bowiem zmierzyć się z wąskimi oknami czasowymi, w momencie, gdy większość z nich przyzwyczajona jest do własnego procesu badań, projektowania, testowania i wdrożeń.  Co więcej, praca designerów opiera się na dostarczanie gotowych rozwiązań, a sprinty charakteryzują się wzrostem produktu, a nie zawsze jego końcem, który jest, jak sama nazwa wskazuje, na końcu tego procesu. To spora przeszkoda mentalna i organizacyjna dla UX’owców.  

Projektanci doświadczeń użytkownika, podobnie jak zespół scrumowy, zbierają feedback. Jednakże sprzężenie zwrotne określone w metodyce pracy zawęża działania zespołu, tylko do samego siebie i rozwoju produktu, a UX konfrontuje się z użytkownikami, co może przynieść o wiele bardziej nieprzewidywalne rezultaty niż zarządczo-projektowe ceremoniały.

Okazuje się, że człowiek to nieprzewidywalne stworzenie i nawet doświadczeni UX’owcy mogą mieć problem z wcześniejszym określeniem pełnej specyfikacji produktu. Spora część IT bazuje na przeczuciach Ownerów i Managerów, co odbywa się z różnym skutkiem dla finalnego dzieła. Stąd też należy pomyśleć o badaniach użytkowych (UXR) oraz testowaniu gotowych rozwiązań na bieżąco, co bywa dużą osią sporu w zespołach.

O czym pamiętać wdrażając Design do zespołu Scrum?

Oglądając materiał Drive with IT z Wojciechem Rusnakiem mogliśmy usłyszeć zdanie, w którym to UX Designer musiał udowodnić swoją wartość przed zespołem. Wydaje się być to naturalną konsekwencją wśród ludzi, którzy pracują w danym systemie i nagle oczekuje się od nich współpracy z jednostką, której roli nie do końca potrafią pojąć.

Wszak programiści mają przecież największą wiedzę o swoim produkcie.

Choć do ostatniego zdania nikt nie ma żadnych zastrzeżeń, tak postać UX w zespole jest nieoceniona, jeśli chcemy, aby produkt był użyteczny i schludny. Udowadnianie swojej wartości nie może odbywać się zatem kosztem czasu, produktu czy różnych napięć międzyludzkich, które wpływają na pracowników i przebieg procesu. 

Tutaj właśnie Masterzy powinni wyjaśnić dokładną rolę i znaczenie działu UX w zespole, ale by tak się wydarzyło sam UX musi czuć się pewnie. Wielu projektantów tak się nie czuje, gdyż mogą nie wiedzieć dokładnie czym jest scrum, a nawet jeśli to mogą obawiać się, że nie będą mieli wystarczająco dużo czasu na badania i testy, co znacznie utrudni im pracę. Aby uniknąć takiej sytuacji musimy każdego członka zespołu zaznajomić z terminologią, jakiej używamy oraz czasem pracy i zadaniami, które będą w nim wykonywane. Research i testy UX powinny mieć osobne miejsce w backlogu, co równoznaczne powinno być także z przewidzeniem czasu na te czynności.

Specjaliści systemów Scrum zalecają, aby projektowanie było ukończone przed developmentem, a szkice przed skończonym researchem. Nieraz może zdarzyć się tak, że projekt może być kończony, w momencie początków pisania kodu. No i tutaj powstaje też zadanie, aby zintegrować programistów z ideą projektowania doświadczeń, by mieli oni świadomość czym jest ux i dlaczego go potrzebują.

Wielu speców podkreśla też fakt ograniczenia dokumentacji na rzecz upłynnienia komunikacji w zespole. – Prototypy, grafiki, opisy powinny być tworzone tylko wtedy, kiedy tworzą fundament do dalszej pracy, tj. user flow, customer journey maps, wszystko to, co pozwala nam zbliżyć się do celu Sprintu – czytamy w mohi.to. Witryna rst.software przypomina też o znamiennym punkcie dokształcenia zespołu UX na temat wiedzy, co projektują. Winni oni mieć świadomość, nie tylko samego scrum oraz zespołu, ale też produktu, jego celów biznesowych oraz wymaganiach, jakie przed sobą stawia.

Jak zespolić UX ze scrum?

Projektanci odpowiadają za szereg czynności projektowych, badawczych, wdrożeniowych i komunikacyjnych. Cały proces skoncentrowany na użytkowniku wymaga odpowiedniej metodyki i podejścia do problemu. Seria testów ma sprawdzić czy badania i makiety nie poszły na marne i czy jest coś co w trakcie takiej ewaluacji można udoskonalić. Jeśli firma nie jest dojrzała pod kątem działań user experience to może mieć poważne problemy z adaptacją. Zanim nastąpi rekrutacja UX do projektu, scrum powinien określić jaki jest cel takiej implementacji.

Aby UX mogli funkcjonować w pełni swojej okazałości, powinni mieć czas i miejsce na badania i analizy. Wiele podmiotów jest ściśle przekonanych, że mają najlepszą wiedzę o tym jak produkt ma wyglądać i czego oczekuje od niego rynek, często brnąc w dostarczanie niepotrzebnego lub źle zaprojektowanego rozwiązania, co później wymaga o wiele więcej środków, by taki proces naprawić. W Agile badania powinny być poprzednikiem działań deweloperów i na ich podstawie dopiero można szacować z czym możemy się zmierzyć po drodze. Odpowiednio spreparowany research należy wpisać do backlogu, by każdy miał dostęp do wniosków.

Dla przejrzystości działań scrumowych badania można podzielić na mniejsze user stories. Istotne jest też to, że badania nie muszą być skończone, by móc szkicować pierwsze makiety. Zazwyczaj i tak są podstawowe, a ich rozwój następuje w momencie dalszych doświadczeń. W ten sposób programiści mogą już przygotowywać się do pisania kodu. Projektowanie powinno wspierać to job story, które przewiduje się w obecnym sprincie. Warto zapoznać się z design systemami, aby przyspieszyć pracę UX, UI i deweloperów. Szczególnie istotne w tworzeniu aplikacji jest sprawdzenie, czy spełnia ona swoją rolę i jak odbierana jest przez użytkowników, co mało kiedy przewidują zespoły na etapie tworzenia. Bardzo często może okazać się, że produkt jest do poprawy, a projekt jest zakończony. 

Tutaj potrzeba zaplanowania działań badań satysfakcji, aby zespół UX miał wiedzę na temat finalnego produktu i mógł podzielić się nią z zespołem, aby w przyszłości tworzyli lepsze produkty. Jest wiele technicznych sposobów na wdrożenie ux w scrum. W sieci istnieją już gotowe recepty na zespolenie tych dziedzin, zatem do dzieła!