Czy design może być agile? O zaangażowaniu projektanta w proces tworzenia i wdrażania nowych produktów.
W trakcie pracy nad nowym produktem musimy liczyć się z prawdopodobieństwem, że nasze pierwsze koncepcje i pomysły mogą nie przynieść oczekiwanych rezultatów. Jeśli pracujesz jako designer, zapewne dotarło do Ciebie powiedzenie, że 9 na 10 startupów upada. Walidacja pomysłu na biznes na wczesnym etapie jego tworzenia, zderzenie naszych idei z realnymi odbiorcami sprawia, że bardzo szybko możemy pozyskać wiedzę i odpowiedź na pytanie, czy kontynuować pracę przy produkcie, czy wykonać zwrot.
Jednak warto zastanowić się nad kwestią, gdzie w procesie budowania nowych rozwiązań jest design. Koncepcja zwinnego tworzenia oprogramowania stała się faktem wraz z opublikowaniem w 2001 roku Manifestu Agile (ang. Manifesto for Agile Software Development). Jednak to podejście skupia się tylko na wytwarzaniu oprogramowania, a projektanci UX i UI w dużej mierze nadal sami projektują nowe rozwiązania we współpracy ze zleceniodawcą. Spróbujmy zatem odpowiedzieć na pytanie, kiedy kończy się czas pracy projektantów, a zaczyna poważne wdrażanie? Na jakie problemy możemy natrafić, gdy zespół designerów przekaże swoje rewolucyjne idee zespołowi wdrożeniowemu i okaże się, że cały pomysł ma braki z punktu widzenia technologii? Na jakim etapie projektant powinien być zaangażowany w proces tworzenia oprogramowania? I czy w ogóle możemy mówić o etapach?
O patologiach w zwinności
Wyobraź sobie, że wraz z zespołem projektowym pochylasz się nad problemem wprowadzenia innowacji w twojej firmie. Wspólnie przeprowadzacie badania potencjału branży, rozmawiacie z klientami, poszukujecie inspiracji w alternatywnych rozwiązaniach. Pełni ekscytacji szkicujecie kolejne koncepcje, sprawdzacie ich potencjał, testujecie, by dopracować swoje pomysły. Na koniec możecie zaprezentować rezultaty za pomocą ładnej i estetycznej prezentacji, a zleceniodawca będzie entuzjastycznie kiwać głową. Na tym wasza rola w zasadzie się kończy. Teraz do pracy zostanie zaangażowany dział technologiczny i rozpocznie się wytwarzanie i wprowadzanie w życie waszych pomysłów. Tylko co, jeśli okaże się, że rozwiązania oparte na testach z użytkownikami są niemożliwe do wdrożenia bądź koszt ich wytworzenia przekracza estymowane zyski?
W trakcie pracy jako Lead UX Designer, gdy miałam okazję kierować zespołem projektantów, stanęliśmy przed niemałym wyzwaniem. Gdy rozpoczynał się nowy projekt, powoływano zespół deweloperski, który miał przy nim pracować. Teoretycznie każdy z zespołów działał w duchu zwinnego wytwarzania oprogramowania. Ale zaraz, zaraz. Praca w Scrumie rozpoczynała się dopiero, gdy projektant po konsultacjach z klientem dostarczył zespołowi zaawansowany finalny prototyp (ang. high fidelity prototypes) produktu. Co powodowało takie podejście? Nawet doświadczeni designerzy, gdy rozpoczynali swoją pracę sprint (lub kilka) wcześniej niż zespół developerski, byli w zasadzie pozbawieni dostępu do osób technicznych. Powodowało to możliwość wpadnięcia w pułapkę trudnych do wdrożenia rozwiązań. Z kolei deweloperzy nie mieli wpływu na wizję budowanego przez nich produktu, nie tworzyli jego koncepcji, nie rozumieli dlaczego zostały podjęte pewne decyzje projektowe. Podstawą zwinnego podejścia do wytwarzania oprogramowania jest brak marnotrawstwa. A ile marnotrawstwa zasobów udałoby się uniknąć, gdyby zmienić sposób pracy! Element interfejsu zaprojektowany w konkretny sposób wpływa na to, ile czasu deweloper spędzi nad jego wdrożeniem. Czasami tylko drobna modyfikacja, która nie zmieni znacząco odbioru wizualnego projektu, może sprawić, że ten czas zostanie skrócony o połowę.
Chcąc pogłębić temat współpracy projektantów z zespołami wdrożeniowymi, postanowiłam przeprowadzić szereg rozmów z Product Ownerami, Project Managerami i deweloperami, którzy mieli okazję pracować z designerami w różnych konfiguracjach. Moim celem było zebranie informacji na temat ich wrażeń z takiej współpracy. Chciałam dowiedzieć się, co im się w niej podobało, a co nie, na jakie wyzwania natrafili i w jaki sposób próbowali sobie z nimi poradzić. Wnioski z przeprowadzonych badań były bardzo ciekawe: problemy w pracy pojawiały się najczęściej w sytuacjach, gdy designer tak naprawdę nie był częścią zespołu budującego dany produkt. Gdy projektant pracował tylko w swoich kompetencjach, a z zespołem technologicznym widywał się sporadycznie i nie uczestniczył w spotkaniach, podczas których odbywało się planowanie dalszej pracy. Co więcej, brak dostępności designera (np. podczas współpracy z freelancerem) prowadził do sytuacji, w których zespół musiał sam podejmować decyzje projektowe, reagować na zmiany i wdrażać coś, co nigdy nie było nawet blisko projektanta. Ponadto zespoły deweloperskie podnosiły problem braku zaangażowania ze strony designera w testy wdrożonej części produktu. Rola projektanta kończyła się na przygotowaniu interfejsu, bo on nigdy nie widział tego, co powstało.
Biorąc pod uwagę moje osobiste doświadczenia z procesu transformacji, którą prowadziłam wraz z moim zespołem, a także spostrzeżenia innych specjalistów, stwierdzam, że włączenie projektanta w prace wdrożeniowe jest w stanie skutecznie eliminować marnotrawstwo. Taka praca wymaga zmiany sposobu myślenia i początkowo może nie być komfortowa dla wielu projektantów, którzy w takim podejściu czują na sobie presję czasu. Jednak musimy pamiętać, że proces budowy nowego produktu jest najczęściej kompromisem między trzema płaszczyznami: biznesem, użytkownikiem i technologią. Oczekiwania potencjalnych odbiorców, ich potrzeby i problemy są ważnym elementem, bez którego możemy stworzyć produkt po prostu niepotrzebny. Z drugiej strony za danym pomysłem najczęściej stoi jakaś firma, która chce na produkcie zarabiać. I ostatni element, wymuszający ścisłą współpracę projektantów i deweloperów, czyli technologia. Designer, który pominie inżynierów w swojej pracy, może stworzyć fantastyczny projekt, spełniający zarówno oczekiwania biznesu, jak i użytkowników, ale niemożliwy bądź zbyt kosztowny do wdrożenia w stosunku do przynoszonych zysków.
Projektant częścią zespołu wdrożeniowego
Wypada zatem zadać sobie fundamentalne pytanie: w jaki sposób i kiedy włączyć designera do projektu? Czy powinien on najpierw rozmawiać z osobami technicznymi, by zapoznać się z technologią stojącą za tworzonym produktem? Czy może z Product Ownerem i klientem, by zrozumieć kontekst biznesowy? A co jeśli odpowiedź brzmi: projektant powinien być częścią zespołu wdrożeniowego? Co, jeśli mogą nie istnieć „etapy”, w których designer dołącza do procesu budowania nowego produktu? Czas przyjrzeć się podejściu, które kończy erę jednorożców designu i pokazuje, że projektować mogą wszyscy!
W książce „Lean Startup” Eric Ries szerzy wizję pracy nad nowymi produktami, opierającą się na eksperymentach, szybkiej iteracji i ewaluacji pomysłu. Na styku podejścia Lean Startup i projektowania wrażeń użytkownika rodzi się Lean UX. Podejście to zakłada współpracę w ramach interdyscyplinarnych zespołów, gdzie osoby odpowiedzialne za pracę nad produktem nie pracują w izolacji od siebie. W tym sposobie pracy odchodzi się od bohaterskiej roli projektanta (jednorożca, guru), a zakłada się podejście zespołowe, gdzie każdy może uczestniczyć w tworzeniu i projektowaniu rozwiązań. Dokładnie tak, każdy może być designerem! Lean UX burzy mury, które oddzielają projektantów od zespołu technologicznego i rzeczywistych problemów biznesowych.
Podstawy ruchu Lean UX
Lean UX opiera się na kilku istotnych filarach. Pierwszym z nich jest, oczywiście, Lean Startup. Podstawą tego podejścia jest jak najszybsze zdobycie wiedzy i informacji z rynku o tym, co klienci sądzą o naszym produkcie. Praca odbywa się w pętlach „build – measure – learn”, gdzie zespół buduje minimalnie satysfakcjonujący produkt, MVP (ang. Minimum Viable Product), daje możliwość korzystania z niego potencjalnym użytkownikom i tym samym uzyskuje informację zwrotną. Warto wspomnieć, że terminem MVP wcale nie musimy określać gotowego, działającego produktu lub jego elementu. To ma być coś, co przede wszystkim pozwoli pozyskać wiedzę. Przykładem MVP może być landing page, który opisuje propozycję wartości Twojego produktu, wyposażony w wezwanie do działania w postaci newslettera lub formularza kontaktowego z zapisem na testy rozwiązania. Czasami tworzy się wygląd funkcji, której w rzeczywistości nie ma, innym razem korzysta się z metody badawczej zwanej Czarnoksiężnikiem z krainy OZ. W tym wypadku użytkownik wchodzi w interakcję z systemem, który tak naprawdę nie istnieje, a jego działanie symuluje człowiek. Śledząc historię powstawania startupów z różnych branż, możemy znaleźć inspiracje na szybkie zweryfikowanie zapotrzebowania na nasz produkt. Wystarczy tutaj przytoczyć przykład powstania Facebooka, który rozpoczynał jako założona w 2004 roku platforma społecznościowa dla studentów Harvardu. Dzisiaj Facebook cały czas wdraża, testuje i rozwija nowe funkcje. Z ciekawostek warto nadmienić, że popularna dziś funkcja „Like” została dodana do platformy jakieś 5 lat po jej uruchomieniu.
Drugim filarem Lean UX jest Design Thinking – myślenie projektowe, spopularyzowane przez firmę IDEO. To proces rozwiązywania skomplikowanych problemów, bazujący na empatii, zakładający skupienie się na użytkowaniu i wykorzystanie wiedzy o nim.
Ostatnim elementem jest zwinne wytwarzanie oprogramowania (ang. Agile Software Development). Podejście to zakłada pracę w krótkich cyklach, podczas których dostarczane jest do klienta działające oprogramowanie, a tym samym – wartość biznesowa.
Jak zatem zdefiniować Lean UX?
Jest to 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 – J. Gothelf, J. Seiden, „Lean UX dla zespołów Agile. Projektowanie doskonałych wrażeń użytkownika”.
Proces Lean UX zakłada pracę w pętli składającej się z czterech kroków. Pierwszym z nich jest deklaracja założeń, a następnie przekształcenie ich w weryfikowalne hipotezy. Następnym krokiem jest budowa MVP, którego celem będzie sprawdzenie hipotezy. Aby obalić bądź potwierdzić hipotezę, przeprowadza się eksperyment, który umożliwia zbieranie feedbacku i ponowną pracę nad założeniami, ale już w oparciu o nową wiedzę.
Kilka zasad: Praca w interdyscyplinarnych zespołach
Podstawą Lean UX jest praca zespołowa. Ta praktyka kończy z czasem, gdy tylko UX Researcher mógł przeprowadzać badania, a tylko UX Designer tworzyć makiety. Zróżnicowany zespół, który współpracuje na każdym etapie procesu projektowego, jest bardzo ważny, jeśli chcemy tworzyć udane produkty. Zespół taki powinien składać się z przedstawicieli różnych kompetencji: projektantów, osób odpowiedzialnych za zarządzanie produktem, osób technologicznych czy posiadających wiedzę domenową.
Zaproszenie programistów na warsztat z klientem oraz badania i testy z użytkownikami daje możliwość pełnego zrozumienia biznesu i odbiorców produktu. W konsekwencji pozwala też poczuć, czym jest UX, a także budować właściwą kulturę użyteczności w całej organizacji. Ponadto warto zauważyć, że w przypadku tworzenia produktów cyfrowych osoby odpowiedzialne za technologie stanowią zazwyczaj główną oś całego projektu. Ich obecność na samym początku procesu pozwala szybko uzyskać odpowiedź na pytania, co można zrobić, a czego nie można przy zastosowaniu dostępnej technologii. Dodatkowo programiści obecni w momencie tworzenia koncepcji produktu mogą sugerować nowe rozwiązania, odpowiadać na techniczne pytania, wskazywać punkty optymalizacji projektu. Każdy problem jest rozpatrywany z wielu różnych punktów widzenia. Nie jest potrzebne tworzenie i przekazywanie sobie długich dokumentacji, bo każdy członek zespołu rozumie, jaki problem biznesowy rozwiązuje, czym jest produkt i nad czym zespół będzie dalej pracował.
Wspólne zrozumienie
Co równie ważne z punktu widzenia pracy zespołowej, każda osoba zaangażowana w budowę produktu musi rozumieć, co się dzieje w projekcie, jakie decyzje zostały podjęte i dlaczego. Dlatego tak istotne jest, aby deweloperów włączać w procesy projektowe, a z projektantami rozmawiać o możliwościach technicznych.
Dopóki czegoś nie sprawdzimy, jest to tylko naszym założeniem
Gdy pracujemy nad danym rozwiązaniem, od samego początku mamy w głowie mnóstwo pomysłów. Zastanawiamy się, jakie rozwiązanie jest najlepsze, czy dana rzecz zadziała pozytywnie, czy jest przydatna. W ruchu Lean UX ważne jest, by nie marnować czasu na budowę produktów, które nie mają sensu. Zatem dopóki czegoś nie zbadamy, jest to tylko naszym założeniem.
Niepowodzenia są ok
Jaka jest szansa, że pierwszy pomysł, który wpadnie nam do głowy, będzie tym właściwym? Aby znaleźć naprawdę dobre rozwiązanie, zespół musi eksperymentować, a eksperymenty mogą dowieść, że pierwsze koncepty były błędne. Zespół musi mieć swobodę działania i przyzwolenie na ponoszenie porażek oraz obalanie kolejnych hipotez.
Ciągłe uczenie się od użytkowników
Zdobywanie wiedzy od użytkowników jest podstawą projektowania user experience.
W tradycyjnym podejściu badania są najczęściej osobną fazą, zazwyczaj na początku i końcu projektu. W podejściu Lean UX badania i testy to część procesu. Wykonuje się je często i regularnie, a zaangażowany w nie powinien być cały zespół. Nie ma nic bardziej wartościowego niż obserwowanie, jak użytkownik korzysta z naszego produktu. Jak najszybsze wyjście z naszym pomysłem poza własne podwórko sprawia, że unikniemy sytuacji, w której spędzimy czas nad rozwijaniem czegoś, co od początku nie miało sensu.
Nie musisz tworzyć finalnego designu, by rozmawiać o produkcie
Dopracowany w najmniejszym szczególe i zaakceptowany przez klienta projekt nie jest jedynym sposobem na rozmowę o rozwiązaniu. Czasami wystarczą szkice na papierze, które obrazują funkcjonowanie systemu, czasem stworzony na szybko prototyp (np. w Figmie). W Lean UX mówi się o kolektywnym projektowaniu, gdzie cały zespół jest odpowiedzialny za szkicowanie rozwiązań. Warto wdrażać takie podejście i uzmysłowić członkom zespołu, że jeśli potrafią narysować prostokąt, kółko i kreskę, to z pewnością będą w stanie wziąć udział w takiej sesji.
Koniec ery jednorożców
Włączenie projektanta w procesy zwinnego wytwarzania oprogramowania dla wielu firm może być wyzwaniem. Chyba największą modyfikacją, która może być szokiem dla projektantów i wymaga zmiany myślenia, jest fakt, że ich praca i praca deweloperów odbywa się jednocześnie. Projektant przestaje być jednorożcem, który sam prowadzi badania, projektuje i wykonuje testy użyteczności, przestaje być osobą, która ma monopol na właściwe pomysły, jedyną, która rozumie potrzeby i problemy użytkownika. Czas porzucić swoją „jaskinię kreatywności” i zaangażować się we wszystkie wydarzenia zwinnego procesu. Designer powinien stać się aktywnym członkiem zespołu.
Integracja projektowania w rytm zwinnego wytwarzania oprogramowania wymaga, aby nie tylko projektant pełnił rolę projektanta. Nie tylko on jest odpowiedzialny za tworzenie i projektowanie rozwiązań. W ten proces zaangażowany jest cały zespół. Ale czy nie na tym właśnie powinno polegać budowanie nowych produktów? To w końcu sport zespołowy, gdzie różne perspektywy skutkują tworzeniem najlepszych rozwiązań.
