Lean UX – czy design może być zwinny?

W ramach Monday talka, cyklicznego wydarzenia, podczas którego dzielimy się wiedzą wewnątrz Pragmatic Coders, Katarzyna Smoleń-Drzazga, nasza Senior Product Designer, starała się odpowiedzieć na pytanie, czy proces projektowy może być prowadzony w sposób zwinny. To z kolei zainspirowało mnie do napisania tego artykułu.

Czym jest UX, Strategia UX oraz Product Design?

Zanim przeczytasz o samym Lean UX, dla przypomnienia wyjaśnię Ci kilka najważniejszych pojęć, które warto sobie uspójnić.

User Experience (UX)

User experience (UX) jest to całość doświadczeń, emocji, wrażeń użytkownika, dobrych i złych, podczas interakcji z produktem lub usługą.

Definicja ta wskazuje obszary pracy UX designera, którego rola czasami bywa błędnie kojarzona z twórcą makiet i klikalnych prototypów. Tymczasem w rzeczywistości jego zadanie polega na przewidywaniu różnych sytuacji podczas korzystania z danego produktu oraz proponowaniu rozwiązań, które odpowiadają na potrzeby użytkowników, rozwiązują ich problemy i sprawiają, że interakcja z nimi jest przyjemnością.

Tak rozumiany UX nie ogranicza się jedynie do wytwarzania produktów cyfrowych. Wyobraź sobie sytuację, w której miasto decyduje się wprowadzić do autobusów i tramwajów nowe biletomaty z dotykowym ekranem i dające możliwość płatności wyłącznie kartą. Gdyby przy tym projekcie pracował specjalista od UX, powinien zaalarmować, że np. osoby starsze, które przecież często korzystają z komunikacji miejskiej, mogą mieć problemy z dokonaniem zakupu.

Strategia UX, czyli kompromis pomiędzy potrzebami użytkownika, firmy a technologią

Doświadczeni designerzy wiedzą, że choć w centrum ich zainteresowań są potrzeby użytkownika, to muszą również pogodzić je z potrzebami biznesu oraz dostępną technologią. A więc podczas projektowania pamiętają o tym, że produkt ma zarabiać i realizować pewne cele firmy. Do tego w grę wchodzą możliwości technologiczne. O tym, co może wydarzyć się, jeśli designer nie weźmie ich pod uwagę, przeczytasz w kolejnym akapicie.

Mercedes-Benz BIOME – kiedy design rozmija się z technologią

Kasia podczas swojej prezentacji przytoczyła bardzo ciekawy przykład projektu, który został zaprezentowany podczas targów motoryzacyjnych w Los Angeles w 2010 r. Przedstawiał on samochód koncepcyjny Mercedes-Benz BIOME (na zdjęciu).


W opisie samochodu można znaleźć:
(…) nadwozie jest wykonane z superlekkiego materiału o nazwie BioFibre, który jest lżejszy niż metal i tworzywa sztuczne. (…) BioFibre jest hodowany z DNA będącego zastrzeżoną własnością firmy w specjalnej szkółce Mercedes-Benz, gdzie czerpie energię ze słońca i magazynuje ją w płynnym chemicznym równaniu o nazwie BioNectar4534. W ramach tego procesu pojazd powstaje z dwóch nasion: wnętrze BIOME rośnie wykorzystując DNA umieszczone w emblemacie Mercedesa, czyli słynnej gwieździe, umieszczonej w przedniej części pojazdu, a nadwozie wyrasta z gwiazdy umieszczonej z tyłu”.

Brzmi jak opis pochodzący z książki science-fiction, prawda? Jest to oczywiście projekt koncepcyjny, który w założeniu nie miał być stworzony pod produkt na sprzedaż. Jednak odnosząc tę sytuację do projektowania produktów cyfrowych możemy zauważyć, że wyobraźnia designerów jest nieograniczona. Projektant podczas pracy nad realnym produktem musi pamiętać, że jego pomysł powinien być możliwy do wdrożenia za pomocą dostępnej technologii. Jest to świetny powód, aby usprawniać współpracę designerów z programistami.

Product Design

Wiedząc już, o jakich trzech obszarach musi pamiętać designer, można przejść już do samego procesu projektowego.


lean-ux2
Powyższy model pokazuje etapy powstawania większości produktów. Pierwszym z nich jest zrozumienie problemu. Jest to moment zbierania danych (np. jak wielu osób ten problem dotyczy, jak bardzo utrudnia życie itd.).

Następnie przychodzi czas, kiedy należy się zastanowić i zdefiniować, co może być rozwiązaniem owego problemu (define). W efekcie powstaje pomysł na produkt i jego wizja. Kiedy ktoś już wie, co chce stworzyć, musi zastanowić się, jak to zrobić w najlepszy sposób. Dlatego w tym momencie konieczny jest research najbardziej optymalnych rozwiązań. Dalej dyskutuje się, szkicuje różne projekty, krytykuje je, aż w końcu dochodzi się do przekonania, jaki produkt będzie najlepszy dla użytkowników. Przekonanie to oczywiście jest czysto hipotetyczne i zostaje zweryfikowane dopiero po stworzeniu projektu i wypuszczeniu go na rynek.

Ktoś mógłby pomyśleć, że teraz rola designera się kończy. Tymczasem, to właśnie w tym momencie użytkownicy wchodzą w pierwsze interakcje z produktem i jest to najlepszy czas na przeprowadzanie testów, zbieranie feedbacku i udoskonalanie produktu, by był on coraz bardziej użyteczny, co pozwoli pozyskiwać coraz to nowszych użytkowników.

Czasem feedback może spowodować nawet, że twórcy muszą się cofnąć i przejść wcześniejsze fazy procesu od początku. Na przykład gdy okazuje się, że produkt jednak nie spełnia oczekiwań użytkowników, nie rozwiązuje ich problemu lub rozwiązuje go tylko częściowo. Aby proces budowania nowych produktów przebiegał w optymalny sposób warto zastanowić się nad tym w jaki sposób designer może w nim uczestniczyć. Porozmawiajmy zatem o Lean UX.

Czym jest Lean UX?

Jeszcze na początku XXI w. tworzenie oprogramowania przypominało np. produkcję mebli i odbywało się w modelu kaskadowym (waterfall). Najpierw projektant po ustaleniach ze zleceniodawcą planował i rozrysowywał projekt, a następnie przekazywał instrukcje do osób, które były odpowiedzialne za jego wykonanie. Dalej gotowy już produkt trafiał do fazy testowania czy kontroli.

Zmiana nadeszła w 2001 r, kiedy opublikowano Manifest Agile i stopniowo coraz więcej firm zaczęło wytwarzać oprogramowanie w sposób zwinny, cechujący się iteracyjnym podejściem i krótkimi pętlami feedbacku, po których dostarczany jest działający fragment oprogramowania.
Choć obecnie większość firm korzysta z podejścia Agile do samego procesu tworzenia oprogramowania, to często dotyczy ono jedynie zespołów programistów, w skład których zazwyczaj nie wchodzi projektant. Rola designera sprowadza się do przekazania szczegółowego, dopracowanego prototypu produktu do zespołu wdrożeniowego, który to dopiero zaczyna pracować zwinnie. Co jednak w sytuacji, gdy projektant pozbawiony wsparcia ze strony deweloperów wypracuje rozwiązanie, które będzie ciężkie, bądź niemożliwe do wdrożenia? Jak temu zaradzić? Odpowiedzią jest Lean UX. W tym miejscu warto spojrzeć na definicję pochodzącą z książki Jeffa Gothelfa i Josha Seidena “Lean UX dla zespołów Agile”:

Lean UX – praktyka zainspirowana podejściem Lean Startup i zwinnym wytwarzaniem oprogramowania, polegająca na szybkim, kolektywnym i interdyscyplinarnym wydobywaniu na światło dzienne produktu o prawdziwym charakterze.

Jeżeli więc zależy Ci na wytwarzaniu oprogramowania w sposób zwinny, jeżeli chcesz wprowadzić mindset Lean UX, musisz upewnić się, że zespół ma rzeczywiście interdyscyplinarne umiejętności i w jego skład od początku wchodzi specjalista zajmujący się User Experience.

Jakie korzyści daje podejście Lean UX?

  • Zacieśnienie współpracy – w skład zespołu wchodzą osoby mające różne kompetencje, tak, by był on multidyscyplinarny i potrafiący rozwiązać dany problem. Pozwala to na lepszą współpracę.
  • Ograniczenie marnotrawstwa (waste) do minimum – cały zespół od początku współpracuje, uczestniczy w spotkaniach, więc wszyscy członkowie rozumieją produkt w jednakowym stopniu. Szybciej dochodzi do dyskusji na temat proponowanych przez designera rozwiązać w kontekście możliwości technologicznych itd.
  • Szybszy feedback – oszczędność czasu i pieniędzy – stosując zasady Lean UX, przyspieszysz feedback zarówno w obrębie zespołu (np. designer zmienia delikatnie jakieś rozwiązanie, bo wie, że zaoszczędzi to wiele wysiłku programistom), jak i od użytkowników. Zespół może przeprowadzać testy na grupie docelowej już po pierwszych tygodniach pracy nad produktem, a więc zespół szybciej dowie się, w którą stronę produkt rozwijać, czego nie robić itd. To łączy się z oszczędnością czasu i pieniędzy klienta.
  • Większe przywiązanie do produktu – w podejściu Lean UX zespół skupia się na tym, by produkt spełniał swoje cele biznesowe oraz rozwiązywał problemy użytkowników w jak najbardziej optymalny sposób. Dlatego członkowie zespołów nie są jedynie zwykłymi wykonawcami, ale kreatorami, mającymi wpływ na ostateczny kształt produktu. To wzmacnia ich przywiązanie do projektu i wzmaga zaangażowanie.

Jak stosować podejście Lean UX?

Po pierwsze należy zdawać sobie sprawę, że nie istnieją gotowe wytyczne, które wystarczy jednorazowo wdrożyć, by powiedzieć, że pracuje się zgodnie z Lean UX. Niemniej postaram się przedstawić kilka zasad, które pomogą Ci osiągnąć właściwy mindset.

Zorientowanie na rozwiązywanie problemów

W duchu Lean UX zespół nie powinien myśleć o zestawie funkcji, jakie ma wdrożyć, ale o problemie, który ma rozwiązać budowany produkt. Zamiast pytać wyłącznie “co” jest do zrobienia, zastanawia się też “po co”. Dzięki temu często rodzą się pomysły na nowe, lepsze rozwiązania, a zespół staje się bardziej związany z produktem.

Interdyscyplinarność

Zespół, który jest zorientowany na dany problem, powinien mieć wszystkie kompetencje do tego, by go rozwiązać. Czyli w obrębie tego zespołu nie wystarczy mieć osoby, które znają się na programowaniu, ponieważ należy jeszcze zaprojektować wygląd produktu, opracować schemat jego działania, a także sprawdzić, jak posługują się nim użytkownicy.

Badanie hipotez

W Lean UX wszystko co nie jest potwierdzone badaniami, to tylko hipotezy. Nic dodać, nic ująć. Zespół może mieć przypuszczenia dzięki swojemu doświadczeniu, jakie rozwiązanie lepiej się sprawdzi, ale dopóki nie zostanie to przetestowane na użytkownikach, jest to tylko hipotezą, którą należy jak najszybciej zweryfikować (i w razie konieczności zmienić dane rozwiązanie/funkcję).

Brak “jednorożca”

W tej enigmatycznie nazwanej zasadzie chodzi po prostu o to, że cały zespół odpowiada za cały produkt. Nie powinno być więc tak, że np. tylko UX designer tworzy cały koncept produktu, a reszta członków go egzekwuje. W zespole każdy powinien mieć wpływ na wizję produktu i go współtworzyć.

Przyzwolenie na niepowodzenia

Podejście Lean UX zakłada, że niepowodzenia się zdarzają i służą do tego, by się z nich czegoś nauczyć. Jak wcześniej wspomniałem, wszystkie założenia, które nie doczekały się jeszcze feedbacku, są hipotezami. Należy więc liczyć się z tym, że feedback, który otrzymasz, będzie negatywny. Wersja produktu opracowana przez zespół może się po prostu nie spodobać użytkownikom. To samo tyczy się procesów podczas budowania oprogramowania, które również powinny doczekać się feedbacku ze strony członków zespołu. Ważne jest to, by umieć wyciągać właściwe wnioski i nieustannie starać się doskonalić to, co już udało się wypracować, a także, gdy jest to konieczne, wykonać zwrot i zmienić koncepcję.

Wyjście poza własne podwórko

Zespoły deweloperskiej zazwyczaj składają się z młodych osób, które doskonale radzą sobie z technologią. Jeżeli tworzą oni np. oprogramowanie dla grupy wiekowej 60+, to zamiast opierać się jedynie na swoich przekonaniach odnośnie użytkowników docelowych, warto przeprowadzić wśród nich badania, zrobić rozeznanie i dopiero na tej podstawie podejmować decyzje. Dotyczy to każdej grupy odbiorców.

Jak wykorzystać kolektywność w Lean UX?

W definicji Lean UX była mowa o kolektywnym wydobywaniu produktu na światło dzienne. Mam więc dla Ciebie dwa szybkie sposoby, jak tą kolektywność w zespole osiągnąć i wykorzystać.
collectivism in lean ux

Kolektywne projektowanie

Na etapie tworzenia koncepcji produktu, np. podczas ustalania jego wersji MVP, warto zastosować kolektywne projektowanie. Polega ono na tym, że każdy członek zespołu rysuje rozwiązania. Nie potrzeba do tego żadnych umiejętności plastycznych czy manualnych. Jeżeli potrafisz narysować kółko, prostokąt i linię prostą, to wystarczy, by przygotować zarys danego rozwiązania czy interfejsu.

Zaletą kolektywnego projektowania jest to, że zespół szybciej zaczyna rozumieć, jak dany produkt ma działać i szybciej zaczyna rozmawiać o rozwiązaniach (np. designer oraz developer dyskutują o możliwościach technicznych). Pozwala też zaoszczędzić czas na tworzeniu obszernych dokumentacji, które dla członków zespołu nie będą konieczne.

Kolektywne badania

Podejście Lean UX zakłada, że cały zespół może, a nawet powinien uczestniczyć w badaniach tego, co przygotował dotychczas. Chodzi tutaj o naprawdę szybkie testy, które mogą być przeprowadzane nawet raz w tygodniu na 2-3 osobach, ale jednak zawsze dostarczają wartościowy feedback. Tym sposobem po kilku tygodniach pracy zespół będzie mieć już informację zwrotną od kilkunastu osób, które testowały tworzony produkt.

TL;DR – MUST do zapamiętania!

Projektant powinien od samego początku wchodzić w skład zespołu developerskiego. Jego uczestnictwo w spotkaniach dotyczących produktu oraz współpraca z programistami szybko przyniosą korzyści.

Projektowanie jest sportem zespołowym. Designer nie powinien być jedyną osobą odpowiedzialną za docelowy design, koncepcję produktu, lecz cały zespół na drodze licznych dyskusji i testów.