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):

  1. Discover
  2. Define
  3. Design
  4. Develop
  5. 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.

Do poczytania: