Lean UX, to metoda projektowania inspirowana podejściem typu agile i lean startup, która zyskuje coraz większą popularność na świecie. Lean UX jest bardzo fajnym konceptem i wcale niekoniecznie musi wiązać się z developerskimi metodykami agile, których twórcy jakoś niespecjalnie myśleli o designie.
Nie każdy projekt jest startup-em, który może (powinien) odpalić cokolwiek jak najwcześniej, więc równoległość prac projektowych i developerskich jest tam naturalną koniecznością. Duże projekty dla dużych korporacji wyglądają inaczej: nie można uruchomić wersji beta systemu transakcyjnego dla banku, w której działa tylko 1/10 funkcji. Trzeba zaprojektować od razu całość, a potem wdrożyć - nie da się iść na żywioł i eksperymentować.
Tradycyjny model pracy nad projektami zakłada 5 kolejnych faz (5D):
- Discover
- Define
- Design
- Develop
- Deliver
Taki model typu waterfall wcale nie wyklucza jednak Lean UX: to podejście do projektowania, a nie do całego procesu wytwarzania oprogramowania. Development może odbywać się w dowolnej metodyce (waterfall, agile), ale faza projektowania, jakby nie kombinować, musi jakoś go poprzedzać. Samo projektowanie może jednak wyglądać różnie.
Dokumenty przygotowywane przez UX Designera to najczęściej:
- Specyfikacja wymagań
- Założenia/koncepcja projektu
- Struktura serwisu/aplikacji
- Makiety/prototyp interfejsu
- Raporty z badań z użytkownikami
- Dokumentacja funkcjonalna
W tradycyjnym modelu pracy UX kiedy wszystkie makiety/prototypy są skończone oraz przetestowane z użytkownikami i razem z dokumentacją zostaną zaakceptowane przez klienta, zostają przekazane do projektanta graficznego. Ten na ich podstawie przygotowuje projekty w Photoshopie. Wszystkie grafiki po zaakceptowaniu trafiają do "cięcia" do webdevelopera, a potem cała paczka wcześniej przygotowanych deliverables (prototyp, HTML-e, dokumentacja funkcjonalna) trafia do programistów aplikacji.
Taki proces przypomina linię montażową w fabryce i ma poważne wady:
- Więcej czasu trzeba poświęcić na dokumentowanie projektu, niż na samo projektowanie, np. pisanie dokumentacji funkcjonalnej zajmuje więcej czasu, niż wymyślenie interfejsu, pisanie raportu z badań pochłania więcej czasu, niż wprowadzenie zmian w projekcie.
- Pojawia się nieuchronny rozjazd między makietami i projektami graficznymi, których powstawanie jest mocno rozdzielone w czasie.
- Dokumentacja funkcjonalna staje się najczęściej nieaktualna w momencie jej oddania. A developerzy i tak jej nie przeczytają 😉
- Graficy i developerzy nie czują się współautorami projektu, a jedynie jego wykonawcami.
- Proces projektowy i badawczy zajmuje tak dużo czasu (głównie z powodu sporządzania drobiazgowej dokumentacji i jej akceptacji z klientem), że najczęściej zaczyna brakować go na development…
Jak pracować bardziej efektywnie?
Podejście Lean UX minimalizuje ilość produkowanej dokumentacji, dzięki zwiększeniu komunikacji w zespole projektowym. Więcej czasu spędza się na wymyśleniu rozwiązania i jego optymalizacji w kolejnych iteracjach, niż na opisywaniu projektu.
- Pierwszym etapem projektowania jest stworzenia koncepcji całego rozwiązania. Koncepcja nie musi i nie jest w stanie uwzględniać wszystkich szczegółów - to np. surowy klikalny prototyp, który pokazuje "big picture": podejście do interfejsu, nawigację. Trzeba przyjąć, że koncepcja będzie się zmieniać i rozwijać w ramach postępu prac nad projektem, ale stanowi punkt wyjścia. W pracach nad koncepcją powinien uczestniczyć cały zespół: UX Designer, grafik, IT, klient.
- Po zaakceptowaniu koncepcji całości przez klienta projekt dzielony jest na mniejsze moduły, które będą opracowywane po kolei. UX Designer i grafik mogą pracować praktycznie równolegle dostarczając od razu finalny produkt (kolejne ekrany makiet w prototypie i projekt graficzny), który może też od razu trafiać do cięcia do webdevelopera. Unikamy w ten sposób rozjazdu między makietami UX i projektami graficznymi, potrzeba mniej projektów, żeby pokazać jak działa rozwiązanie: zamiast pełnych layoutów powstaje biblioteka stylów i powtarzalnych elementów. Od razu można pokazać klientowi jak np. zachowuje się projekt responsive web design, bez potrzeby symulowania tego na kilku statycznych makietach.
- Klient powinien uczestniczyć w projekcie na bieżąco akceptując każdy kolejny etap np. na cotygodniowych spotkaniach.
- Można w szybki sposób testować wewnętrznie kolejne powstające elementy projektu. Badania z użytkownikami można też przeprowadzić na prototypie, który faktycznie przypomina finalny projekt, a nie jest tylko makietą lo-fi. Jeśli klient jest cały czas w projekcie i jest obecny na badaniach z użytkownikami nie jest też potrzebny kilkusetstronicowy raport: wystarczy krótkie podsumowanie z rekomendacjami zmian.
- Programiści od początku mają wiedzę dotyczącą projektu i mogą dostawać kolejne skończone elementy dużo wcześniej. Nie otrzymują grubej dokumentacji do przeczytania na samym końcu. Szczegółowa dokumentacja interfejsu nie jest potrzebna, jeśli wszyscy uczestnicy projektu wiedzą o co chodzi - wystarczy interaktywny prototyp i grafiki albo HTML-e.
Gdzie jest problem?
Największym problem przed wdrożeniem takiego modelu pracy jest postawa niektórych klientów:
- Narzucanie kuriozalnej etapowości prac przez zamawianie tylko części procesu, np. kupujemy prace UX, ale prace graficzne zlecimy później po zakończeniu części UX, a o pracach IT pomyślimy jeszcze później. To przepis na katastrofę… (Szczególnie jeśli koncept AI i jego wdrożenie graficzne zlecane są osobnym firmom - agencja, która zgodzi się na robienie projektu graficznego na podstawie makiet innej firmy musi być bardzo zdesperowana).
- Wymaganie i drobiazgowe akceptowanie rozbudowanej dokumentacji, chociaż nie jest ona w rzeczywistości interesująca dla klienta, a jedynie dla developerów. (Którzy mogliby się bez niej obejść, gdyby od początku uczestniczyli w projekcie.)
- Nadmierne rozbudowywanie etapu badań z użytkownikami. Badania mają służyć potrzebom projektantów - to oni powinni więc decydować o tym, czego potrzebują się dowiedzieć i jaki zakres badań jest wystarczający. Jednak w briefach od klientów często można znaleźć wymagania: "minimum 4 sesje badań po 8 użytkowników" bez wyjaśnienia powodów. Wiele firm podchodzi do projektów badawczych jakby zupełnie nic nie wiedziały o swoich klientach i robiły badania z użytkownikami po raz pierwszy. Tymczasem raporty z wielu wcześniejszych badań kurzą się na półkach i zupełnie nic z nich nie wyniknęło. Ta wiedza powinna być udostępniona projektantom. Może się okazać, że wielkie badania wcale nie są niezbędne.
Takie zwinne podejście do prac UX, to nie tylko oszczędność czasu i pieniędzy, ale też lepsze projekty.
@EG
Ja się nie zgadzam za bardzo z tą szkołą 😉 I o ile w małych projektach da się jeszcze pracować sekwencyjnie, to w dużych już zupełnie nie.
Jak widzę to już dość stary wątek, ale dopiero przeczytałam. Nie jestem bardzo doświadczoną projektantką. Widzę jednak już wyraźnie, że praca dzielona na ściśle określone etapy jest bez sensu. Jeśli robię prototyp w axure i taki prototyp pokarzę klientowi bez jakiejkolwiek grafiki to ciężko ocenić taki projekt. Kiedy jednak pojawią się kolory, jakaś grafika, ikonografika itp. to jest już zupełnie inaczej., Nawet czasem sam projektant po pojawieniu się jakiejś stałych grafik widzi wyraźnie elementy do poprawy w swoim dotychczasowym projekcie, bo sam kolor sprawi, że np. widać, że odstępy powinny się zmienić itp.
Znam szkołę, że najpierw czyste makiety do prezentacji, aby nie odciągać elementami graficznymi od setna koncepcji i funkcjonalności, a dopiero potem jak makiety ok to wchodzi etap z grafikami. Jakoś nie mogę sobie tego do końca wyobrazić, bo chociażby klienci nie rozumieją czystych makiet. Wydaję mi się, że przy dobrym projekcie projektant powinien ściśle i nawet równolegle współpracować z grafikiem. Jestem ciekawa jak to wygląda przy dużych projektach.
@Hania
Ale właśnie w sytuacjach, gdy trzeba się cofnąć i coś poprawić, lean czy podobne metody pokazują swój pazur.
Oczywiście, ponoszony jest pewien koszt i nakład pracy, ale to nic w porównaniu z metodami kaskadowymi. Tam propozycja powrotu do projektowania nawet w przypadku krytycznych błędów jest często odbierana jako celowy sabotaż 😉
Jasne, zmiana to ponoć najpewniejsza rzecz w projekcie:) Nie twierdzę, że się nic nie zmieni. Są jednak różne rodzaje projektów – takie, w których koncepcja będzie się zmieniać 5 razy całkowicie, bo mamy wytworzyć coś bardzo kreatywnego i mamy coraz to lepsze pomysły, i takie, w których pewne założenia są już ustalone i te się nie zmienią – np. musi wystawiać faktury, faktury mają określoną strukturę, itp. W tych projektach się zmienia mniej.
Ogólnie chodziło mi o podział pracy na części – czasem się może okazać, że jedna i druga część jest powiązana, ale przyglądając się części drugiej później, możemy przeoczyć coś, co trzeba było uwzględnić w pierwszej części, która została już zrobiona. W niektórych projektach to mniej ważne, w innych takie powiązania występują częściej i warto wziąć to pod uwagę.
@Hania
“Jeśli jednak system jest skomplikowany, a wymagania w miarę stabilne (to nie produkt, który może być doskonalony, ale system, co do którego mamy określone z góry oczekiwania, np. do fakturowania), to mogłyby wystąpić problemy podczas podziału projektowania na części.”
Oczekiwania zawsze się zmieniają i nie wierzę, że jakiś system nie może być doskonalony 😉 Im większy projekt, tym większa potrzeba podzielenia go na części właśnie. Oczywiście musi powstać na początku jakaś wizja całości.
“Co to znaczy „dokumentacja”? Opis makiet? Opis działania elementów interfejsu? Specyfikacja funkcjonalna?”
Ja też się zastanawiam 😉 Specyfikacja funkcjonalna, to jak rozumiem taka “bez obrazków” 😉 I jak już powstają makiety okazuje się zwykle, że to co tam zapisano przestało być aktualne.
Jeżeli mowa o dokumencie opisującym cele i wymagania, to zupełnie co innego – i to zawsze jest potrzebne (czy nazwiemy to briefem, czy “specyfikacją wymagań”, czy inaczej).
Zwiększenie nacisku na komunikację może być świetnym pomysłem. I klient widzi, co się dzieje, i zespół jest bardziej poinformowany, a produkty pracy bardziej spójne.
Projekty bywają bardzo różne. Od niezłożonych, gdzie liczy się wygląd i UX, gdzie tworzy się produkt, po skomplikowane systemy, w których najważniejsze jest stabilne działanie (wspierają działanie organizacji). Mamy różnych klientów – pana Jacka albo ogromną korporację z 50 departamentami – w różnym stopniu są oni dla nas dyspozycyjni. Klient może nie mieć sposobności zbierać co tydzień wszystkie zainteresowane osoby (a może powinniśmy go tylko bardziej przycisnąć?;) Ale nadal – “klient – nasz pan”. Często wolimy się dostosować do niego niż go stracić. Chociaż z nas dwóch to my się znamy lepiej na tym jak projekt prowadzić…
Wydaje mi się, że jednym z największych problemów w naszych projektach jest to, że szukamy jednego najlepszego rozwiązania. Mamy waterwall i widzimy, że czasem nie działa, więc przeciwstawiamy mu lepszy sposób. Z kolei ten sposób również może gdzieś się nie sprawdzać. Dobrze byłoby podejść indywidualnie do każdego projektu i zastanowić się, jakie jest ryzyko – że będzie za mało komunikacji czy za mało planu? Lean UX pewnie jest lepszym sposobem na projekty, z którymi spotykasz się najczęściej. I super, że szukasz usprawnienia:) O to chodzi.
Jeśli jednak system jest skomplikowany, a wymagania w miarę stabilne (to nie produkt, który może być doskonalony, ale system, co do którego mamy określone z góry oczekiwania, np. do fakturowania), to mogłyby wystąpić problemy podczas podziału projektowania na części. Projektujemy cz. 1, a potem cz. 2. Później się okazuje, że w cz. 2 wysyła się maila, ale w cz. 1 powinniśmy tego maila pobrać od kogoś. Takich zależności może być wiele. I możemy je odkrywać dopiero wtedy, kiedy dojdziemy do pewnego poziomu szczegółowości.
“Wymaganie i drobiazgowe akceptowanie rozbudowanej dokumentacji, chociaż nie jest ona w rzeczywistości interesująca dla klienta, a jedynie dla developerów. (Którzy mogliby się bez niej obejść, gdyby od początku uczestniczyli w projekcie.)”
Tutaj trochę podyskutuję:) Co to znaczy “dokumentacja”? Opis makiet? Opis działania elementów interfejsu? Specyfikacja funkcjonalna? Specyfikacja funkcjonalna (“co może robić system/aplikacja”) jest jak najbardziej interesująca dla klienta. Z niej właśnie on wie, co dostanie za swoją kasę. Co do opisów makiet to spotykam się od niedawna i ciągle zastanawiam się jeszcze nad ich rolą. Czy mają uzupełniać to, co widać na makiecie? Gdyby dodawać na niej komentarze, to można by się tego opisu w formie dokumentu pozbyć?
“Nie interesuje klienta” – zależy, co się w tym dokumencie znajduje. W niektórych projektach powstają uzgodnienia na temat tego, jaki jest cel klienta, w jaki sposób działa jego biznes i co z tych elementów przenieść do systemu. To jest stricte dla klienta. To on musi potwierdzić, że go dobrze rozumiemy, a on rozumie, co od nas dostanie, zanim przejdziemy do tworzenia systemu.
“Nie interesuje developerów”. Dokumentacja dla klienta i dla developerów trudno żeby była tym samym dokumentem, skoro to zupełnie inne perspektywy patrzenia na projekt. Na bazie ustaleń z klientem powinien powstać jakiś projekt, który będzie już bardzo interesujący dla developerów. Nie w języku biznesu, ale w języku technicznym. Skoro nie czytają dokumentacji, to może dlatego, że widzą wszystko, co tam opisane, i tak na makiecie? Może myślą, że tak jest i nie znajdą w dokumencie nic ponadto.
Cofnięcie do początku po zaprojektowaniu całości jest bardziej bolesne niż wykonanie części projektu i części systemu? Czy projektowanie trwa dłużej/jest bardziej kosztowne od wytworzenia tego, co zaprojektowano?
Podsumowując – Cieszę się, że myślimy o naszym sposobie pracy w projektach i kreatywnie szukamy lepszych sposobów:)
@Tomek
“Idealne do wdrożenia w małych teamach pracujących tylko nad jednym projektem – etatowy, agencyjny grafik czy webdeveloper (nie mówiąc już o programiście w d… ma jaka jest cała koncepcja projektu i jak to ma działać.”
No to powodzenia życzyć takiej agencji 🙂
Idealne do wdrożenia w małych teamach pracujących tylko nad jednym projektem – etatowy, agencyjny grafik czy webdeveloper (nie mówiąc już o programiście 😉 w d… ma jaka jest cała koncepcja projektu i jak to ma działać. W praktyce wygląda to tak (przykład z Allegro), że przez 3 tygodnie chodzisz na spotkania razem z tabunem innych “zaangażowanych” w projekt, a potem przez 3 dni zajmujesz się tym czym powinieneś :).
[…] bez szczegółowego raportowania). O tym samym problemie Maciek wspomina w swoim artykule Lean UX na uxdesign oraz Forum One w artykule A Better Approach to Usability […]
Moim zdaniem doskonałe rozwiązanie, które wymaga dwóch niezbędnych elementów:
– pełnego zaufania klienta (oddanie projektu “w ręce profesjonalistów”)
– zbudowania zespołu, który może się spotykać twarzą w twarz przynajmniej raz w tygodniu
Sprawa doskonała dla większych agencji interaktywnych, które posiadają działy ux, graficzny, developerski, strategii, etc.
Jak sam wspominałeś, problemem jest rozparcelowywanie projektu na poszczególne podmioty. I chociaż mogliby być to najlepsi specjaliści w branży, to zawsze na którymś etapie pojawi się problem związany z brakiem lub zakłóceniami komunikacji.
Generalnie myśl, która przychodzi mi do głowy po przeczytaniu tej metodyki czy raczej podejścia to synergia.
Dobry artykuł. Z mojego doświadczenia wynika, że firmy coraz częściej widzą potrzebę i realne korzyści jakie stoją za projektowaniem interakcji, ale wciąż jest to jednak tylko etap w procesie. Software house’y produkują zwykle soft w metodyce kaskadowej i tam UX pojawia się jako czasami jako etap, można powiedzieć, że lepsze to niż w ogóle pominięcie UX, minusy opisano wyżej. Lean UX w praktyce pewnie wdraża kilka dużych firm w Polsce jeśli już, cała reszta agencji tworzy serwisy kaskadowo, bardzo duży nacisk kładziony jest na dokumentację tak jak Maciek pisze, a programiści rzadko kiedy ją czytają bo ta też rzadko kiedy zawiera use casy i podział na aktorów w systemie. Dominującym czynnikiem wyboru firmy do opracowania systemu wciąż jest cena, zbyt duże koszty UX zwykle są wycinane, ponieważ sam klient postrzega je jako zbędne, ewentualnie jako jakieś rozszerzenie prac graficznych. Z kolei nt. przetargów publicznych można by chyba książkę napisać. To jest bardzo ciekawy temat w szerszym aspekcie – jak w ogóle tworzy się dziś w Polsce soft, bo na pewno inaczej niż 10 lat temu, kiedy to UX był mniejszą, lub większą fanaberią, dziś to się zmienia, ale wciąż tkwimy w kaskadowym modelu pracy, firmy rzeczywiście pracujące w metodykach zwinnych (nie tylko je deklarujące) można policzyć na palcach dwóch rąk.
No, na przykład Pekao24 robiliśmy mocno w taki sposób.
Cofnięcie do początku może się też wydarzyć po zrobieniu całego designu, a wtedy jest dużo bardziej bolesne 😉
Przy odrobinie determinacji 😉 …. również w dużej korporacji można realizować (duże) projekty w iteracyjny sposób
Fajnie napisane 🙂
Do problemów przy leanie dodałbym jeszcze:
Klient dopiero jak widzi całość, rozumie jak całość będzie działać.
Robienie etapami może się w pewnym momencie skończyć cofnięciem do początku (a my już mamy w połowie wydevelopowany produkt – nie tylko połowę makiet).
Mimo to lean wydaje się mieć więcej zalet niż wad 😉