Wywiad z Anią, Product Designer’em w PC

Ł: Opowiedz, jak wygląda Twoja praca?

Ania: W Pragmatic Coders pracuje się inaczej niż w typowej firmie produktowej, ponieważ opracowuje się wiele produktów, a naszym celem jest pomoc startupom w jak najszybszym wypuszczeniu ich produktów na rynek. Chcemy jak najszybciej sprawdzać założenia wypracowane w trakcie badań. Testujemy, czy założenia są dobre, czy odpowiadają potrzebom rynku.
Aby to osiągnąć, musimy się skupić na najważniejszych funkcjach w danym produkcie. Na początkowym etapie nie jest ważne ulepszanie produktu, ale określenie co jest konieczne do realizacji MVP (Minimum Viable Product).

Ł: Wydaje mi się, że trudno jest znaleźć odpowiedź na postawione przez Ciebie pytanie. W jaki sposób określasz, co ma się znaleźć w MVP?

A: To nie jest tylko moja decyzja. Podejmujemy ją razem z Product Managerem, zespołem i klientem. Najpierw musimy dobrze zdefiniować problem, jaki chcemy rozwiązać. Zastanowić się nad potencjalnymi rozwiązaniami, skonsultować te pomysły z programistami. Patrzymy, co jest najbardziej potrzebne użytkownikowi, co da się najszybciej zaprogramować, co jest najważniejsze z punktu widzenia UX. Decyzja o zawartości MVP jest sensownym kompromisem pomiędzy różnymi perspektywami.
Oprócz tego, powstaje tak zwana lista “Nice to have” (“Fajnie by to było mieć” przyp. red.). Na tej liście mogą się znaleźć fajne animacje czy komponenty, które trzeba wytworzyć od zera, na co nie ma czasu.

Ł: Z tego co słyszę, patrzycie na problem i potencjalne rozwiązania z wielu różnych perspektyw. Umawiacie się na zakres MVP i co dalej?

A: Razem z Product Ownerem (PO) wypracowujemy plan działania. Dzielimy daną funkcję produktu na pierwszy i drugi etap wdrożenia. Pierwsza wersja jest najbardziej ociosana, po prostu odpowiada na konkretny problem. Druga wersja to docelowa funkcja produktu, która ma zapewniony dobry UX.
Dzięki takiemu podejściu użytkownik końcowy szybko zaczyna pracować z produktem, co dostarcza wartość biznesowi.
Bardzo sobie cenimy kontakt z prawdziwymi użytkownikami. Sprawdzamy odzew, zainteresowanie, rozmawiamy z nimi, a to ma dużą wartość.

Ł: Jak angażujecie klienta do tworzenia produktu?

A: Kontakt z klientem mamy cały czas. Codziennie, poprzez spotkania czy rozmowę na Slacku. Raz na jakiś czas organizujemy “Design Sessions”, na których klient mówi o potrzebach biznesowych. Wtedy razem staramy się znaleźć rozwiązania, które będą użyteczne. Sprawdzamy, jak wygląda kontekst działania produktu oraz dlaczego dana funkcja jest pożądana. Zadajemy pytania, które mają pomóc zrozumieć kontekst. Później wypracowujemy, jak produkt ma działać.

Ł: Czy to klient przychodzi z gotową listą funkcjonalności, a Wy zastanawiacie się, jak je zrealizować w najlepszy możliwy sposób? Czy też klient nie ma pełnej listy i pracujecie z użytkownikami końcowymi, aby opracować funkcjonalności?

A: Odpowiem klasykiem – to zależy. Na przykład w obecnym projekcie, zanim produkt wyszedł na świat, musieliśmy dokonywać założeń, a nie mieliśmy czasu na badanie rynku i nie było kontaktu z użytkownikami końcowymi. Później, część z tych założeń została zupełnie usunięta z produktu. Okazało się, że rzeczywistość jest zupełnie inna.
Gdy produkt zaczyna żyć własnym życiem i obsługiwać użytkowników, to pojawiają się nowe potrzeby biznesowe, których nie mogliśmy przewidzieć, a które trzeba bardzo szybko zaadresować.

Ł: Co jest według Ciebie najważniejszym elementem Twojej pracy?

A: Dla mnie najważniejsze w pracy Product Designera jest dobra komunikacja z klientem, współpraca z zespołem technologicznym i informacja zwrotna od użytkowników końcowych. Dzięki temu dostarczamy produkty, które są wartościowe z punktu widzenia UX, dobrze działają, tj. dobrze wykonują pracę, którą mają wykonać (JTBD).
Zauważyłam że osoby techniczne wciągnięte w proces projektowy, mające wpływ na to, jak dana funkcja produktu ma działać, są później bardziej zaangażowane w tworzenie kodu aplikacji. Wiem, że czują się współautorami tego rozwiązania.

Ł: Czyli mówisz, że na motywację wpływa wczesne zaangażowanie całego zespołu?

A: Tak, ale myślę, że nie tylko wczesne zaangażowanie pomaga w sukcesie produktu. U nas w firmie programiści mają swoją własną motywację, pasję do tworzenia oprogramowania.

Ł: Załóżmy, że trafiłaś na osobę, z którą zupełnie się nie zgadzasz w sprawie danej funkcji produktu. Jak rozwiązujesz taką sytuację?

A: Mało kto lubi robić rzeczy, z którymi się nie zgadza. Praca jest wtedy trudniejsza niż nad rozwiązaniami, które były omówione z daną osobą. W takich sytuacjach jest dyskusja na argumenty. Czasami jest patowa sytuacja i trzeba zaangażować kolejną osobę, by poznać jej punkt widzenia.
Trudno jest się pozbyć takich stricte ludzkich przekonań “ja uważam że tak jest lepiej”. Wtedy warto przywołać fakt, że produkt nie jest dla osoby z zespołu, ale dla użytkownika końcowego. Staram się używać argumentów stricte merytorycznych. Czasami jest tak, że to ja się mylę

Ważne jest, aby na samym początku pracy przyjąć założenie, że iteracja jest konieczna do osiągnięcia sukcesu. W obecnym projekcie, do jednej funkcji produktu miałam trzy podejścia, ale jesteśmy przekonani, że wypracowaliśmy najlepsze możliwe rozwiązanie.

Ł: Po czym poznajesz, że produkt lub jego część jest dobra?

A: W przypadku działającego produktu funkcjonalność musi działać dobrze UX’owo i back-end’owo. Czasami trudno jest rozdzielić te dwie rzeczy. Bo jeśli jakiś mechanizm nie działa pod względem technologicznym, wtedy trudno mi jest ocenić, czy dane rozwiązanie jest dobre pod względem UX’owym. Kluczowe jest sprawdzenie, czy dana funkcja produktu jest używana. Często korzystam z narzędzia https://lookback.io/
Dodatkowo dostajemy od klienta informację zwrotną nt. produktu i tego, jak użytkownicy używają danej funkcji lub z czym mają kłopot.

Ł: Co nowego się ostatnio nauczyłaś, co pomogło Ci w pracy Product Designera?

A: Po dołączeniu do Pragmatic Coders nauczyłam się, jak “obcinać” zakres produktu i ograniczać czas zużywany na projektowanie. Wydaje się, że może to być dla projektanta uciążliwe, bo często szuka się komfortu czasu przy pracy nad jednym produktem.
W Pragmatic Coders nauczyłam się, że skupianie się na najważniejszych rzeczach, w sytuacjach, w których liczy się czas, bo chcemy jak najszybciej wyjść z produktem na rynek, powoduje szukanie najcelniejszych rozwiązań i skupianie się tylko na nich. To jest naprawdę super.
Ostatnio robiliśmy Proof of Concept (POC) dla klienta. Zrezygnowaliśmy z kilku funkcji produktu, które nie wejdą do POC, bo na tym etapie nie wnosiły wartości. Była bardzo ciekawa dyskusja. Tej nauki nie wynosi się ze szkoły.

Ł: Jaki narzędzie projektowe ostatnio zaskoczyło Cię pozytywnie?

A: Niedawno odświeżyłam sobie możliwości narzędzia https://www.protopie.io/, bo od czasu, kiedy go używałam, weszło dużo więcej funkcji. Narzędzie daje możliwość stworzenia klikalnego prototypu, który wygląda jak docelowy produkt.

Ł: Skąd bierzesz wiedzę o nowych trendach w projektowaniu produktu?

A: Bardzo cenię UX Collective i czytam https://uxdesign.cc/. Bardzo dobrze opisują w swoich artykułach różne ciekawe projektowe zagadnienia i problemy. Na przykład ostatnio czytałam artykuł o tym, jak zacząć być designerem. Chciałam wysłać ten artykuł znajomemu na Akademii Sztuk Pięknych, aby pokazał studentom, którzy zabierają się za projektowanie aplikacji. Ich wizja tego, jak to się powinno odbywać, później dość mocno zderza się z rzeczywistością.
Bardzo dużo wiedzy czerpię z N/N group https://www.nngroup.com/.” Cenię https://cadence.cc/. Bardzo polecam książkę “Start With Why” Simona Sinek. Uważam, że każdy powinien ją przeczytać. Mówiąc każdy, mam na myśli projektanta, technologa czy pomysłodawcę produktu.

Ł: Dziękuję Aniu za spotkanie.
A: Ja też dziękuję :). To chyba był mój pierwszy wywiad w życiu.