Lean UX: Piękna czy Bestia? Kiedy Lean UX ma sens

Co jeśli stworzymy produkt, który będzie miał idealnie dopieszczony UX, użytkownicy będą przechodzić przez testy użyteczności bez większego problemu, ale okaże się… że ostatecznie nikt z niego nie korzysta? Na te i inne problemy odpowiedzią może być Lean UX. A o tym czym on jest, znajdziecie więcej w poniższym artykule.

Lean UX to metoda iteracyjnego budowania produktów, której autorem jest Jeff Gothelf. Czerpie ona swoje podstawy z takich podejść, jak: Lean Startup, Agile czy Design Thinking oraz skupia się na 3 elementach: budowaniu właściwych produktów w krótszym czasie i bez marnotrawstwa zasobów. 

Brzmi jak podejście idealne, prawda? Przyjrzyjmy się mu zatem bliżej.

Model kaskadowy vs. Lean UX?

Rozpoczynamy projekt, mając podstawową wiedzę o naszym odbiorcy, czasem bazującą na badaniach (coraz częściej, ale nadal nie zawsze!). Projektujemy najlepsze rozwiązanie, a po wielu miesiącach, po wdrożeniu, gdy produkt w końcu styka się ze swoim odbiorcą, okazuje się, że nikt z niego nie korzysta, a my zmarnowaliśmy np. rok albo dwa ciężkiej pracy.

Schemat 1. Model kaskadowy tworzenia produktów (tzw. waterfall). Źródło: własne

Znajome? Powyższy opis brzmi jak typowy scenariusz wielu projektów prowadzonych w tzw. waterfallu.

Czym jest wspomniany “waterfall”? To kaskadowy model tworzenia produktów, gdzie przedsięwzięcie jest realizowane w następujących po sobie etapach, i przypomina nieco… randkę w ciemno. Randkę, gdzie budujemy sobie wyobrażenie drugiej osoby, przygotowujemy się na wspólne wyjście, wkładamy w to dużo siły i energii, a gdy już dochodzi do spotkania okazuje się, że… po prostu nie ma chemii, a my planowaliśmy cały wieczór tylko w oparciu o nasze założenia.

A jak to będzie w Lean UX?

W Lean UX zamiast skupiać się na tym, by przesuwać projekt między kolejnymi etapami, zwracamy uwagę na to, jak weryfikować kolejne hipotezy, które się pojawiają, i dostarczać wartość tu i teraz. Celem jest stałe wdrażanie nowych funkcjonalności, ale tylko tych, które mają biznesowy sens, i z których użytkownicy będą faktycznie korzystać. 

Jednym z głównych wyróżników pracy w modelu Lean UX jest to, że cały zespół pracuje wspólnie od początku projektu. Product managerowie, designerzy, developerzy stanowią jeden team, który wspólnie bierze udział w procesie rozwoju produktu. Ma to ogromne znaczenie i wartość dla całego przedsięwzięcia, bo już od pierwszych etapów jesteśmy w stanie patrzeć na problem z różnych perspektyw. Dzięki temu nie projektujemy rozwiązania, którego wdrożenie nie byłoby możliwe, albo jest niezgodne ze strategią biznesową firmy. Co ważne, zespoły liczą zazwyczaj między 4 a 8 osób – są małe, bo ich celem jest zwinna praca i szybka komunikacja.

Proces Lean UX składa się z 3 etapów, które są inspirowane metodą Lean Startup:

Schemat 2. Model Lean UX. Źródło: własne

• think (learn) – faza, podczas której porządkujemy idee (produktu/funkcjonalności), przekształcając ją w hipotezę do zweryfikowania. Na przykład:  “Wierzymy, że dodanie pop-upu, zachęcającego do pobrania e-booka w zamian za pozostawienie adresu e-mail, zwiększy zapis do newslettera o 10% w skali miesiąca.”. Jesteśmy w stanie łatwo stwierdzić, czy mieliśmy rację, czy nie, prawda?
  
• make (build) – na tym etapie zajmujemy się budowaniem prototypu do testów, tzw. MVP, czyli Minimum Viable Product – produkt o minimalnym zestawie funkcjonalności, gotowy do wprowadzenia na rynek w celu przetestowania kluczowych hipotez.  Mowa tutaj o takiej wersji produktu/funkcjonalności, która pozwoli nam w trakcie testów uzyskać odpowiedź na pytanie, czy nasza hipoteza była prawdziwa, czy fałszywa. MVP wcale nie musi być działającą stroną lub aplikacja. Czasem może być nim wywiad zakończony przedsprzedażą.
• check (measure) – ostatnia faza, czyli zderzenie naszego MVP z realnym odbiorcą i zmierzenie rezultatów, by wrócić do etapu “Think”.

Ten trzyetapowy proces składa się na jeden sprint. Ile on zatem trwa? W Project: People stosujemy najczęściej tygodniowe, w szczególnych przypadkach dwutygodniowe sprinty. Tyle czasu wystarczy, by zweryfikować jedną hipotezę. Nawet, jeśli okaże się, że pomysł nie miał sensu, stracimy tydzień lub dwa, a nie – jak często – miesiące.

Czy waterfall jest taki zły, czyli kiedy warto być mniej lub bardziej zwinnym

Czy prostota i popularność metody Lean UX dowodzi, że bardziej klasyczne podejście – model kaskadowy – jest po prostu zły i należy go zastąpić? Zdecydowanie nie.

Lean UX sprawdza się przede wszystkim przy innowacyjnych projektach (albo tzw. disruptive), kiedy jeszcze nie wiemy, jaki będzie ostateczny kształt produktu lub usługi.

Natomiast jeśli projekt jest mniej innowacyjny, a obszar problemowy znany i zbadany (np. mamy stworzyć firmowy landing page), warto skorzystać z bardziej klasycznego, waterfallowego podejścia. Ryzyko zmian w takim projekcie jest niewielkie, z dużą dozą prawdopodobieństwa też jesteśmy w stanie zaplanować cały projekt, a testy mogą ograniczać się do jednej czy dwóch hipotez.

Inną sytuacją z kolei, w której Lean UX będzie lepszym wyborem, jest ta, kiedy do rozwoju produktu podchodzimy długofalowo. Lean UX najlepiej sprawdza się w rozwojowych projektach, czyli tam, gdzie zależy nam na szybkim wyjściu do rynku, by zbierać feedback i finansowanie, a nie, by podać z góry termin zakończenia z listą funkcjonalności, którą wtedy dostarczymy. W metodzie Lean UX nacisk położony jest na dowożenie tylko tych części produktu, które są najbardziej wartościowe i za które odbiorcy są w stanie zapłacić, więc ważne są eksperymenty, a nie realizacja kolejnych historyjek użytkownika (znanych również jako user story).

Czego w Lean UX nie lubią klienci i projektanci

Na początku prac jeszcze nie wiemy, co będzie ich efektem. Nie jesteśmy w stanie zdefiniować od razu produktu końcowego. Nie wiemy, co dokładnie będziemy robić za 4 sprinty, ani ile ich potrzebujemy, by stworzyć finalny produkt. 

Za to przetestujemy wiele różnych pomysłów, by zmniejszyć ryzyko wypuszczenia złego rozwiązania. Wiemy, że cały zespół skupia się na dowiezieniu i rozwinięciu tylko tych funkcjonalności, za które klienci są w stanie zapłacić. A wartość dowozimy z każdym sprintem coraz szybciej, mając jeszcze więcej wiedzy o realnych potrzebach naszych odbiorców. Wciąż nie warto?

Wielu projektantów, poznając proces Lean UX podczas warsztatów czy prelekcji, pyta o fazę badawczą. W procesie Lean UX nie ma dedykowanej fazy procesu przeznaczonej na badania, bo badania prowadzimy cały czas. Bez przerwy mamy styczność z grupą docelową, weryfikując wiedzę o niej. W pierwszych etapach prac nad rozwiązaniem, kiedy hipotez jest najwięcej, zdarza się, że MVP, które nam je weryfikuje, to właśnie wywiad (na dalszych to może być… wywiad zakończony sprzedażą zanim będziemy mieć realnie wdrożony produkt – magia Lean UX). Pojawiają się więc standardowe metody badawcze, choć w nieco zmienionej formule, za to zdecydowanie częściej niż tylko w początkowych fazach pracy.

Brak jasnego procesu projektowego sprawia, że projektanci, zwłaszcza początkowo, czują się niepewnie. Lean UX wymusza na nas dużą elastyczność, wiedzę, znajomość metod i narzędzi, byśmy mogli nimi “żonglować” w zależności od potrzeb. 

Kolejną problematyczną kwestią jest to, że czasem będziemy osiągać porażkę, by zweryfikować jakąś ideę. W przypadku Lean UX jednak… jest to akurat sukces. Sukces, bo zdobyliśmy wiedzę, że jakiś pomysł nie miał sensu, zaoszczędzając przy tym czas i pieniądze.

Często praca w modelu kaskadowym wydaje się bardziej kusząca – daje konkretną przestrzeń na badania, pozwala zaplanować proces, a ta przewidywalność daje większe poczucie bezpieczeństwa. Dlatego waterfall lubią projektanci i klienci, ale biznes i innowacje – już nie. Pozostaje kwestia, na czym nam zależy najbardziej.

Bibliografia & inspiracje:

• https://www.justinmind.com/blog/how-to-apply-the-lean-ux-methodology/
• https://www.hotjar.com/blog/lean-ux
• https://www.linkedin.com/pulse/zanim-zaczniesz-dzia%C5%82a%C4%87-w-lean-ux-naucz-si%C4%99-pope%C5%82nia%C4%87-joanna-ostafin/
• J. Gothelf, Lean UX, [b.m.], 2013.
• L. Klein, UX for Lean Startups: Faster, Smarter User Experience Research and Design, [b.m.], 2013.