Wyobraź sobie, że zamiast pisać setki stron dokumentacji, po prostu siadasz z zespołem, rzucasz pomysł, szybko go sprawdzasz i od razu wiesz, czy idziesz w dobrą stronę. Dokładnie tym jest Lean UX. To zwinne podejście do projektowania doświadczeń użytkownika, w którym długie analizy zastępujesz szybkimi hipotezami, eksperymentami i ciągłą nauką na żywym organizmie. Skupiasz się tu na szybkim dawaniu wartości i odrzucaniu wszystkiego, co marnuje Twój czas. Zapomnij o wielostronicowych specyfikacjach. Zamiast nich robisz błyskawiczne testy z prawdziwymi ludźmi. Co najlepsze, jako projektant nie siedzisz w swojej wieży z kości słoniowej – od pierwszego dnia ściśle współpracujesz z programistami. Cały ten pomysł zawdzięczamy dwóm ekspertom – Jeffowi Gothelfowi i Joshowi Seidenowi. Pokazali oni światu, że kiedy cały zespół gra do jednej bramki, produkt trafia na rynek znacznie szybciej. Nie rysujesz makiet do szuflady. Rozwiązujesz realne problemy tu i teraz. Dzięki temu cały proces kosztuje mniej, daje Ci ogromną elastyczność i chroni biznes przed przepalaniem budżetu. Regularnie pytasz użytkowników o zdanie, więc od razu widzisz, co działa, a co nie. Możesz błyskawicznie zmienić kierunek, w którym zmierza Twoja aplikacja lub serwis.
Trzy filary, na których stoi Lean UX
U podstaw tej metody leżą trzy silne fundamenty: design thinking (czyli myślenie projektowe), agile (zwinne programowanie) oraz lean startup (czyli szczupłe podejście do biznesu).
Te trzy idee świetnie się uzupełniają i pomagają sprawnie budować produkty, które ludzie naprawdę chcą kupować. Każda z nich wnosi coś innego, ale razem tworzą zgrany mechanizm ułatwiający codzienną współpracę. Kiedy poznasz te podstawy, znacznie łatwiej wdrożysz nowe nawyki w swoim zespole.
Co wnosi tutaj design thinking?
Design thinking uczy Cię głębokiej empatii i każe skupić się na tym, z czym naprawdę mierzy się Twój użytkownik. Zachęca też do współpracy ludzi o różnych specjalizacjach i ciągłego szukania lepszych rozwiązań.
Odrzucasz gotowe, bezpieczne szablony i naprawdę wchodzisz w buty drugiego człowieka. Prace nad doświadczeniami użytkownika zaczynasz od analizy jego rzeczywistych bólów i codziennych wyzwań. Wspólne burze mózgów pozwalają wypracować nieszablonowe pomysły.
Jak agile napędza cały ten proces?
Agile uczy pracy w krótkich, zazwyczaj dwutygodniowych cyklach, czyli sprintach. Chodzi o to, żeby stale dostarczać użytkownikom działające nowości i bez przerwy rozmawiać w zespole.
Praca w sprintach zapobiega tworzeniu zbędnego kodu i przyspiesza proces wdrożeniowy. Deweloperzy, projektanci i biznes komunikują się ze sobą każdego dnia. Dzięki temu nikt nie działa w odcięciu od reszty, a gotowe fragmenty aplikacji testujesz na bieżąco.
Co daje nam podejście lean startup?
Lean startup wnosi do procesu nawyk stawiania hipotez, sprawnego budowania wersji minimalnej produktu, czyli MVP, oraz szybkiego sprawdzania pomysłów na rynku. Chodzi o to, żeby jak najbardziej ograniczyć ryzyko finansowe.
Każdy pomysł traktujesz na początku jako niepotwierdzone przypuszczenie. Budujesz najprostszą wersję usługi lub funkcji, wypuszczasz ją do ludzi i patrzysz, co robią. W ten sposób tanio weryfikujesz swoje plany i nie pakujesz pieniędzy w funkcje, których nikt nie potrzebuje.
Lean UX a waterfall: jak to wygląda w codziennej pracy?
Zderzenie Lean UX z tradycyjnym waterfallem (czyli modelem kaskadowym) idealnie pokazuje różnicę w myśleniu. Zwinne podejście stawia na ciągłe próby, testowanie założeń i ograniczenie dokumentów do minimum. Waterfall z kolei to sztywne, idące po kolei etapy i tworzenie gigantycznych makiet przed startem prac.
W starym modelu idziesz jak po schodach: jeden etap musi się skończyć, żeby zacząć kolejny. Jeśli na końcu okaże się, że trzeba coś poprawić, zapłacisz za to fortunę. Zespół produkuje tony dokumentów, makiet i specyfikacji, zanim programista w ogóle dotknie klawiatury. W zwinnej metodzie odrzucasz te sterty papieru. Skupiasz się na tym, żeby wszyscy w zespole po prostu tak samo rozumieli wspólny cel.
W modelu Waterfall użytkownicy testują produkt dopiero pod koniec całego procesu wdrożeniowego. Jeśli wtedy wyjdą błędy, poprawki będą kosztować bardzo dużo. Zwinne projektowanie odwraca te zasady: pytasz o zdanie od samego początku i badasz potrzeby ludzi na każdym kroku.
Zebrałem dla Ciebie te najważniejsze różnice, żeby łatwiej było je porównać:
| Styl pracy | Waterfall w UX | Lean UX |
|---|---|---|
| Podejście do procesu | Liniowe, kaskadowe fazy bez łatwego powrotu. | Iteracyjne, elastyczne pętle zwrotne. |
| Rola dokumentacji | Obszerne specyfikacje, raporty i makiety. | Minimalne szkice budujące wspólne zrozumienie. |
| Kontakt z klientem | Testy użyteczności pod sam koniec projektu. | Ciągłe badania i szybki feedback od startu. |
| Model współpracy | Praca silosowa i przekazywanie zadań dalej. | Ścisła kooperacja deweloperów, biznesu i UX. |
| Cel główny | Dostarczenie pełnego zakresu według umowy. | Rozwiązanie problemu i dostarczenie wartości. |
Największym marnotrawstwem w projektowaniu oprogramowania jest budowanie doskonałych funkcji, których nikt nie chce używać.
Jak koło Think-Make-Check napędza całą machinę?
Cykl Think-Make-Check (czyli: myśl – twórz – sprawdzaj) napędza całe to zwinne projektowanie. Kręci się to bardzo szybko: najpierw definiujecie problem i stawiacie hipotezy, potem rysujecie proste makiety lub budujecie prototypy, a na koniec od razu sprawdzacie je z prawdziwymi ludźmi.
Taka pętla pozwala błyskawicznie sprawdzić biznesowe pomysły bez marnowania czasu i pieniędzy. Nie planujesz produktu miesiącami. Przechodzisz przez cały ten proces w zaledwie kilka dni, a każde takie okrążenie daje Ci masę wiedzy o zachowaniach Twoich klientów.
W codziennej pracy przechodzicie przez trzy proste kroki:
- think (myśl): wspólnie z zespołem opisujesz konkretny problem biznesowy, przyglądasz się potrzebom użytkowników i układasz hipotezy. Zakładasz na przykład, że prostsze logowanie przez konta społecznościowe podniesie konwersję o dziesięć procent,
- make (twórz): projektujesz najprostszy możliwy szkic, który pozwoli sprawdzić Waszą teorię. Czasem wystarczą szybkie rysunki na kartce papieru, proste makiety albo wczesna, robocza wersja produktu,
- check (sprawdzaj): pokazujesz gotowy prototyp prawdziwym ludziom, robisz szybkie testy korytarzowe albo analizujesz pierwsze dane liczbowe. Wtedy decydujesz, czy wdrażasz ten pomysł, poprawiasz go, czy całkowicie zmieniasz kierunek.
Co o pracy projektantów w Agile mówi słynny instytut Nielsen Norman Group?
Analizy instytutu Nielsen Norman Group pokazują, że wdrożenie projektantów do zespołów pracujących w Agile przynosi świetne rezultaty. Poziom zadowolenia sięga 3,7 w pięciopunktowej skali, a na koniec pracy rzadziej wyskakują niespodzianki. Jest tylko jeden warunek: projektant musi wyprzedzać programistów o jeden sprint.
Liczby mówią same za siebie. Statystyczny zespół zwinny liczy około dziesięciu osób, z czego zazwyczaj dwie to specjaliści UX. Projektanci stanowią więc jakieś siedemnaście procent całego zespołu deweloperskiego.
Badacze z NN/g sprawdzili, jak ludzie oceniają współpracę w różnych modelach pracy. Agile zdobył tu mocną trójkę (3,1) za integrację i świetne 3,7 za satysfakcję ze współpracy. Dla porównania: stary, kaskadowy waterfall wypadł blado, notując odpowiednio 2,5 i 2,9. Ludzie po prostu czują się o wiele lepiej, kiedy pracują zwinnie.
Sami deweloperzy przyznają, że projektanci robią świetną robotę. Ich wpływ na jakość produktu ocenili na bardzo wysokie 4,3. Wpływ na tempo pracy dostał nieco niższą ocenę: 3,3. Widać więc wyraźnie, że choć jakość idzie w górę, to ciągle można jeszcze poprawić sam proces współpracy.
Jeśli chcesz, żeby ta współpraca układała się gładko, wypróbuj trzy proste zasady:
- zasada jeden sprint przed: badania użytkowników i rysowanie makiet kończcie o jedną iterację wcześniej, zanim programiści zaczną pisać kod,
- partnerstwo strategiczne: jako projektant ściśle współpracuj z product managerem i product ownerem już od momentu planowania kolejnych wydań produktu,
- wspólne planowanie: bierz udział w spotkaniach planistycznych całego zespołu, co pozwoli Ci uniknąć przeładowania pracą i zapobiegnie powstawaniu zatorów.
Cały czas najtrudniejszą sprawą jest zbyt późne zapraszanie badaczy do stołu i rezygnowanie z głębszych testów pod presją czasu. Kiedy trzymasz się kurczowo sztywnych reguł Agile bez grama elastyczności, łatwo możesz zepchnąć sprawy użytkowników na boczny tor.
Outcomes zamiast outputs: dlaczego to takie ważne?
Dlaczego w Lean UX tak dużo mówi się o outcomes zamiast outputs? Ponieważ zamiast liczyć kolejne narysowane ekrany czy strony dokumentacji (czyli outputs), skupiasz się na realnej zmianie i rozwiązaniu problemów swoich użytkowników (czyli outcomes).
Tradycyjne firmy często chwalą zespoły za samo oddanie projektu v terminie. Zwinna kultura pracy całkowicie to odwraca. Liczy się to, czy ułatwiasz ludziom życie i czy dzięki temu biznes rośnie. Cały interdyscyplinarny zespół wspólnie odpowiada za sukces na rynku, a nie za to, ile papierów trafi do szuflady.
Żeby w ogóle ruszyć z taką zmianą, potrzebujesz w firmie atmosfery zaufania. Twój zespół musi czuć się bezpiecznie. Ludzie muszą mieć prawo do błędów i sprawdzania ryzykownych pomysłów bez strachu, że ktoś wyciągnie wobec nich konsekwencje. Josh Seiden świetnie to ujął:
Zamiast pytać zespół o to, co dzisiaj zbudował, zapytaj go, jaki problem użytkownika udało się dzisiaj pomyślnie rozwiązać.
Jak zacząć wdrażać Lean UX we własnym zespole?
Najlepszy start? Zamiast spisywać sztywne wymagania, ułóż kilka pierwszych hipotez biznesowych. Zbierz zróżnicowany zespół i jak najszybciej odpal pierwsze testy z użytkownikami.
Nie potrzebujesz do tego nowej, kosmicznej technologii. Chodzi o zmianę nawyków i to, jak ze sobą rozmawiacie w biurze. Wybierz jeden mały, próbny projekt i sprawdź na nim te zasady. Taki test pozwoli Wam oswoić się z pracą bez grubych tomów specyfikacji i nauczy Was ciągłego eksperymentowania.
Chcesz usprawnić pracę i tworzyć lepsze serwisy? Zrób pierwszy krok już dzisiaj. Porozmawiaj o swoich procesach z kimś, kto zjadł na tym zęby, albo po prostu pobierz darmowy szablon karty hipotez Lean UX. Pomoże Wam on zebrać pierwsze założenia. Zacznij budować prawdziwą wartość na podstawie opinii użytkowników i zapomnij o marnowaniu czasu już w najbliższym sprincie!
FAQ – najczęściej zadawane pytania o Lean UX
Czy w Lean UX całkowicie rezygnuje się z dokumentacji?
Nie, absolutnie nie. Chodzi tylko o to, żeby ograniczyć papiery do minimum. Tworzysz wyłącznie takie szkice, makiety i opisy, które pomogą Wam sprawnie dogadać się w zespole. Odrzucacie po prostu pisanie grubych raportów, które i tak wylądowałyby na dnie szuflady.
O co chodzi z zasadą jeden sprint przed?
To prosta zasada: badania i projektowanie robisz o jeden krok wcześniej niż programiści piszą kod. Dzięki temu deweloperzy siadają do pracy z przetestowanymi makietami w ręku. Unikacie w ten sposób nerwowych poprawek na ostatnią chwilę i niepotrzebnych błędów technologicznych.
Kto powinien znaleźć się w zespole?
Najlepszy zespół to taki, w którym łączysz różne talenty. Powinni znaleźć się w nim: projektant UX, programiści, product manager lub product owner oraz ludzie od biznesu. Dzięki temu każdą decyzję sprawdzacie pod wieloma kątami jednocześnie. Wspólna praca buduje też poczucie, że wszyscy jedziecie na tym samym wózku, i uwalnia Was od ciągłego raportowania postępów.
Poszukujesz agencji SEO w celu wypozycjonowania swojego serwisu? Skontaktujmy się!
Paweł Cengiel
Cechuję się holistycznym podejściem do SEO, tworzę i wdrażam kompleksowe strategie, które odpowiadają na konkretne potrzeby biznesowe. W pracy stawiam na SEO oparte na danych (Data-Driven SEO), jakość i odpowiedzialność. Największą satysfakcję daje mi dobrze wykonane zadanie i widoczny postęp – to jest mój „drive”.
Wykorzystuję narzędzia oparte na sztucznej inteligencji w procesie analizy, planowania i optymalizacji działań SEO. Z każdym dniem AI wspiera mnie w coraz większej liczbie wykonywanych czynności i tym samym zwiększa moją skuteczność.
