14 listopada 2013 w Warszawie odbędzie się konferencja z okazji Światowego Dnia Użyteczności (World Usability Day) – WUD na Pradze. Wśród prelegentów znaleźli się m.in. Wiesław Bartkowski (SWPS/School of Form), Natalia Różycka (Roche) oraz Marcin Piotrowski (Play). Rejestracja na to wydarzenie powinna ruszyć już dzisiaj 🙂

Z tej okazji przeprowadziłem wywiad z Marcinem Piotrowskim, który kieruje zespołem UX w Play. Marcin poprowadzi na WUD na Pradze warsztaty ze współprojektowania z użytkownikami (participatory design).

ML: Marcin, na czym polega metoda participatory design i jakie umiejętności chciałbyś przekazać uczestnikom warsztatów? Czego mogą się spodziewać i czego mogą się nauczyć?

MP: Metoda polega na wspólnej pracy użytkowników, ekspertów i projektantów w ramach rozwiązywania konkretnego problemu. Na warsztacie będę chciał pokazać nieco teorii, zrobić serię ćwiczeń praktycznych oraz pokazać kilka case studies jak robią to inni. Być może będę w stanie pokazać przykłady zastosowania participatory design w Play, chociaż tego nie jestem pewien.

Czy współprojektowanie to bardziej rodzaj badania potrzeb klientów, czy raczej narzędzie służące do generowania nowych, odkrywczych, kreatywnych pomysłów? Wiele agencji badawczych ma w portfolio swoich produktów "sesje kreatywne" z respondentami. Takie sesje poprzedzone są screenerem, w którym testowane są zdolności kreatywne respondentów (np. "wymyśl 10 zastosowań dla cegły" 🙂 ). Wybrani respondenci nie są więc zwykłymi użytkownikami, ale osobami o ponadprzeciętnej kreatywności albo ekspertami szczególnie zaangażowanymi w dany temat. Trudno w związku z tym traktować wyniki takich badań jako "reprezentatywne", są one bardziej źródłem nowych pomysłów dla projektantów.

Nie, to zupełnie nie tak. Niby jest jakiś punkt styku z badaniami (wszak poznajemy coś nowego), ale celem procesu jest skłonienie uczestników do głębszej refleksji nad danym tematem. Bardzo istotny jest w tym udział projektanta, bo dzięki niemu możliwe jest prototypowanie nowej usługi, oferty czy wizualizacji i sprawdzenie, czy takie podejście rozwiązuje któryś z problemów zgłoszonych przez użytkowników. Nie jest więc to tylko badanie, ale sesje w trakcie których na szybko testuje się alternatywne koncepcje w oparciu o zdefiniowane problemy. Kreatywność użytkowników końcowych nie ma tutaj nic do rzeczy, dużo bardziej istotne jest ich aktywne SŁUCHANIE oraz możliwość dzielenia się doświadczeniami, najlepiej świeżymi (a nie tylko obserwacja).

Warto podkreślić też, czym projektowanie partycypacyjne nie jest. Otóż NIE JEST wrzucaniem do projektu wszystkiego tego, czego chcą (lub wydaje im się, że chcą) użytkownicy. To co finalnie zostanie zrobione zawsze obciąża projektanta i zawsze jest to jego decyzja. Tak naprawdę dokonanie syntezy znalezisk i przeniesienie wniosków w przyszłość jest kwintesencją pracy projektanta (może to zabrzmieć dziwnie, ale patrzę na to jako na brzemię), ale dokonuje się we współpracy z użytkownikiem.

W jakiego rodzaju projektach warto skorzystać ze współprojektowania? Kiedy ta metoda się sprawdza, a kiedy nie?

Dla mnie projektowanie partycypacyjne rządzi i można korzystać z niego praktycznie zawsze. Praktycznie, bo czasami zdarzają się zadania/projekty wyjątkowo eksperckie i wtedy końcowi użytkownicy niewiele wniosą, bo nie mają odpowiedniej wiedzy (na przykład: planowanie sieci telekomunikacyjnej, ustalanie sposobu przekazywania użytkownika pomiędzy stacjami bazowymi). W takich sytuacjach można wykorzystać co-creation, czyli podejście w którym pracują ze sobą bezpośrednio eksperci i projektanci. Odwołując się do naszych wspólnych doświadczeń powiedziałbym, że dość skutecznie robiliśmy to w Play pracując z K2 na tzw. warsztatach: K2 dawało architekta i projektanta, od strony Play byli eksperci i iteracyjnie pracowaliśmy nad projektami.

Z mojego doświadczenia wynika, że PD szczególnie dobrze sprawdza się w dwóch sytuacjach: po pierwsze, kiedy projektujemy dla użytkowników bardzo się od nas różniących (w sensie mentalnym) - współprojektowanie wpływa na głębszą empatię i zapewnia pamiętanie o ich potrzebach; po drugie, kiedy projektujemy obszar na którym "wszyscy się znają" i gdzie wydaje się, że wszystko wiemy. Najczęściej nie wiemy wszystkiego i szybko się o tym przekonujemy 🙂 Przykładem dla pierwszej grupy mogą być wszelkiego rodzaju projekty, realizowane na potrzeby osób cierpiących na choroby przewlekłe czy o ograniczonej mobilności, ale także sytuacje takie jak np. projektowanie dla dzieci czy młodych rodziców. Dla drugiej – praca na materiale stworzonym przez ekspertów w jakiejś dziedzinie, ale dostępnym dla praktycznie każdego (np. faktura czy ulotka reklamowa). Rzeczywistość oczami użytkowników często różni się dość mocno od tego, co widzą lub w co wierzą eksperci.

Nie wiem czy zgodzisz się z taką obserwacją, ale z mojego doświadczenia "spece od UX" dzielą się na dwie grupy. Z jednej strony są "projektanci", których najbardziej kręci robienie "rzeczy" i jak najszybciej starają się przejść do tworzenia czegoś konkretnego. Przy czym na użytkowników patrzą czasem trochę z góry i myślą, że sami wiedzą lepiej, co dla nich dobre. Badania ich trochę nudzą i podchodzą do nich nieufnie. Z drugiej strony mamy "badaczy", którzy przede wszystkim zainteresowani są interakcją z ludźmi: badaniami, warsztatami. Ich pasją jej wypróbowywanie coraz to nowych metod, natomiast myśl o spędzeniu kilku miesięcy nad jednym projektem i szlifowaniu detali, niekończących się poprawkach i iteracjach, problemach technologicznych, budzi u nich grozę. (Przy okazji, badacze też mają czasem tendencję do "upupiania" swoich użytkowników i traktowania ich trochę jak nierozgarnięte dzieci: raporty badawcze często ozdobione są "śmiesznymi cytatami od respondentów", które funkcjonują na zasadzie humoru z zeszytów szkolnych.) Choć szukałem, nie udało mi się znaleźć na rynku ludzi, którzy łączyliby w równym stopniu pasję i zdolności projektowe i badawcze, z jakiegoś powodu to się wyklucza. Mówię o tym dlatego, że metoda współprojektowania wydaje się bardzo ciekawa, bo w pewien sposób łączy te dwa światy: z jednej strony to jakiegoś rodzaju badania, z drugiej praca projektowa, gdzie użytkownika traktuje się jako partnera, a nie "obiekt". Co o tym myślisz?

Szczerze, to nie mam aż takich obserwacji, ale nie wykluczam że to dlatego, że nie zwracałem na to wcześniej uwagi. Niewątpliwie realizacja jakiegokolwiek projektu „dobrze” (tzn. dostarczenie dobrych wyników), zakłada spędzenie przy nim sporo czasu - nie wierzę, że da się robić projekty dobrze i szybko. Oczywiście, czasami jako specjaliści potrafimy rozwiązać dany problem od ręki, ale najczęściej jest to tylko fragment jakiegoś szerszego rozwiązania.

Kluczem do rozumienia projektowania jest dla mnie intencjonalność, a może ona zaginąć, jeśli zbyt mocno opiera się na własnej ekspertyzie i jest się zamkniętym na argumenty użytkowników (chociaż czasami bywają one pokrętne). W tym kontekście pojawiają się u nas nowe metody eksploracyjne i badawcze – obficie czerpiemy z „Gamestormingu” i „Thinkertoys”, analizujemy przypadki z innych rynków i branż. Wszystko to jest fajne, ale tylko wtedy jeśli dają one efekty (intencjonalność!). Przykładowo na jeden z warsztatów przygotowałem narzędzie o nazwie Whole Product Game. Narzędzie było świetne, ale miało jedną wadę – nie działało. Użytkownicy nie mieli odpowiedniej wiedzy, żeby z niego skorzystać. A stało się tak, bo chwilę wcześniej poszli nieco inną niż zakładana ścieżką i wygenerowali bardziej abstrakcyjne kategorie. Pewnych rzeczy nie da się przetestować „teoretycznie” – trzeba rozpoznać je bojem. Stąd dość często zdarza mi się sprawdzać jakieś metody w kontekście realizacji określonego celu. Problem pojawia się wtedy, kiedy osoba projektująca zna swoje intencje, ale nie są one jasne np. dla właściciela biznesowego. Wtedy można mieć wrażenie "odjechania" czy nieprzystawalności biznesowej danej metody. Dbamy o to włączając właścicieli biznesowych w proces badawczy, w tym także w projektowanie samego badania. Ale dopóki się czegoś nie sprawdzi - nigdy nie wiadomo.

Drugi filar projektowania to człowiek. Wiem że to jest mega oklepane i oczywiste, ale w ferworze walki i chęci tworzenia rozwiązań spełniających oczekiwania właścicieli biznesowych tematu, nadzwyczaj często zdarza się o tym człowieku zapominać. Są ficzery, systemy, pomysły, ale nie ma użytkownika. Participatory design jest rozwiązaniem tego problemu, bo użytkownik jest w procesie praktycznie cały czas. Przyznam, że nawet „humor zeszytów” może mieć pozytywny wydźwięk, bo przez swoją wyjątkowość przez dłuższy czas przypomina o konkretnym użytkowniku i jego problemie. Jeśli nie traktuje się go jako okazję do wyśmiania respondenta, to jest fantastycznym artefaktem projektowym i okazją do stworzenia historii.

Często powtarzany jest cytat przypisywany Henry'emu Fordowi o tym, że gdyby słuchał klientów powinien dać im szybszego konia, a nie samochód. Znana jest też niechęć Steve'a Jobsa i Apple do badań konsumenckich. Projektanci UX często zderzają się z tym konfliktem: z jednej strony wiemy, że nie projektujemy dla siebie, tylko dla naszych klientów; z drugiej strony klienci często nie są w stanie spojrzeć na problem wystarczająco szeroko, wyjść poza swoje dotychczasowe doświadczenia i przyzwyczajenia. Jak rozsądnie korzystać z researchu, nie popadając w pułapkę tego, że staramy się realizować wszystko, co tylko powiedzą nam klienci?

To, co mówił Steve Jobs to jedno, a co robił - drugie. Rozumiem niechęć Jobsa o tyle, że jeśli mam pytać swoich użytkowników wprost "co chciałby Pan dostać" to wynik będzie słaby. Dla mnie research to pogłębianie zrozumienia jakiegoś obszaru i odkrywanie tego, o czym się nie mówi wprost. Najczęściej wartościowe znaleziska pojawiają się zupełnie "przy okazji", a użytkownicy nawet nie wiedzą, że coś nam dali.

Sednem problemu jest selekcja znalezisk. To projektant ma sprawdzić co jest, co mogłoby być i na tej podstawie przedstawić rekomendację tego, jak ma być w przyszłości. Jako realny problem postrzegam sytuację, w której rozwiązuje się nie do końca znamy problem. Dużo łatwiej takie decyzje podejmować, jeśli się bezpośrednio poznało swojego użytkownika i świat, w którym funkcjonuje. Tę cechę szczególnie mocno widać w przypadku przedstawicieli biznesu – naturalną sytuacją jest dla nich od razu przejście do generowania pomysłów, bez weryfikacji stanu obecnego, czyli tak naprawdę bez dogłębnego poznania i zrozumienia istoty problemu.

Reasumując: słuchać swoich użytkowników, ale też bardzo świadomie przeglądać znaleziska.

Czy możesz opowiedzieć coś o projektach w Play, w których wykorzystaliście współprojektowanie? Jakie były efekty i jakie trudności napotkaliście?

Tutaj mam największy problem, bo z wiadomych względów nie mogę o tym mówić. Ale jest jeden projekt, o którym mogę powiedzieć 🙂 Celem było zaprojektowanie interfejsu dla systemu, mającego ułatwiać pracę osób z pierwszej linii - salonów, telesprzedaży, obsługi klienta, itp. Kiedy przyszliśmy do projektu, dostaliśmy 80 stron wymagań funkcjonalnych. Udało się nam jednak wynegocjować z IT przejęcie właścicielstwa projektu na kilka pierwszych tygodni i przeprowadzenie własnego researchu. Brali w nim udział wszyscy zaangażowani w projekt. Przede wszystkim jednak postawiliśmy na pracę bezpośrednio z użytkownikami końcowymi - zrealizowaliśmy serię obserwacji i warsztatów, które odbyły się w naszych call center. Projektowane rozwiązanie było iteracyjnie testowane przez całościowo zaangażowanych w projekt reprezentantów użytkowników, a na końcu przeprowadzony został pilot na części użytkowników. Miarą sukcesu było to, że odmówili oni deinstalacji tego softu i chcieli na nim pozostać.

Trudności? Pierwsza, to chyba sam początek procesu, kiedy musieliśmy przekonać osoby odpowiedzialne za projekt i jego realizację, do odłożenia na bok wypracowanych w trudzie "wymagań" i pójścia całkowicie dla nich nową drogą. Nie wiem, czy jest to do powtórzenia w jakiejś innej firmie niż Play. Druga trudność, to skłonienie ekspertów do jasnego komunikowania powodów przyjętych założeń czy podjętych decyzji. Często jest tak, że coś jest na tyle oczywiste, że się o tym nie mówi. Tak jest z przyjętymi założeniami technologicznymi (np. pracujemy na danej bibliotece i tylko na niej) czy funkcjonalnymi (wiemy że system będzie funkcjonować w szerszej całości i musi się do czegoś dopasować). Dopiero po głębszej inwestygacji okazywało się, że pewne rzeczy były bardzo uzasadnione, a my traciliśmy dużo czasu i energii na próby rozwiązywania niewłaściwych problemów. Ale generalnie wszystko się udało i było to naprawdę wyjątkowe doświadczenie.