Proven Product Design – jak połączyć metodyki agile i UX

Nie tak dawno temu pisaliśmy o możliwościach wdrożenia User Experience do metodyki SCRUM, a z Anną Krawiec poruszyliśmy istotę projektowania produktowego. Jacek Samsel i Anna Schneider z Symetria UX, na łamach marketingprzykawie.pl także podzielili się wiedzą odnośnie perspektywy na tworzenie produktu w agile z punktu widzenia UX, czyli o podejściu nazwanym Proven Product Design.

Zobacz także: User Experience i Product Design – ich synergia to synonim skuteczności na rynku

Jak słusznie zauważono, zwinne podejście metodyczne agile jest obecnie hegemonem, gdy spojrzymy na świat nowoczesnych technologii. Dzieje się tak nie bez powodu. Wszak jego rolą jest ustanowienie konkretnych ram postępowania, których przestrzeganie ma dostarczyć produkt gotowy do wdrożenia lub produkcji.

Oczywiście dostrzegamy w tle także startupy działające w taktyce lean, które chcą uszczuplić nakłady produkcyjne i optymalizować w ten sposób całe modele biznesowe czy też w taktyce design thinking, na bazie którego opracowuje się koncepcje i prototypuje projekty.

Ogromna ilość zespołów działa mimo wszystko na najpopularniejszej z metodyk agile, czyli SCRUM, ale rzesza osób dostrzega konieczność integracji programistów z działem UX’owym, w celu większej optymalizacji produktu pod kątem jego użyteczności dla końcowych klientów.

Różne podjeścia programistów od designerów

W obrazowej formie, moglibyśmy zgeneralizować, że programiści to umysły analityczne i twarde, trzymające się reguł projektu i zasad programistycznych, a projektanci doświadczeń to z kolei osoby przyzwyczajone do żywiołowego działania i szybkiego reagowania na bodźce zewnętrzne. Idąc za ciosem stereotypu, moglibyśmy powiedzieć, że designerzy są często mniej zdyscyplinowani, ale działają według swojego systemu. 

Co prawda więcej zależy od osobowości i charakteru danej jednostki niż od wybranego zawodu, ale co do zasady deweloperzy działają zazwyczaj w agile, a designerzy wykorzystują metodyki myślenia projektowego. Podejścia te ,owszem, mają podobną naturę, ale zupełnie inne wykonanie, z czym ciężko sobie często poradzić, przy okazji wdrażania User Experience, chociażby  do Scrum.

Po co UX w agile?

Agile jest świetnym sposobem dostarczania produktów, zwłaszcza skrojonych na miarę oczekiwań biznesowych. Często możemy natrafić jednak na problemy, z którymi zespół będzie się mierzył z wielkim trudem, a designerzy z trochę mniejszym. Samo jednak podejście mastera i ownera do tworzenia oprogramowania może być zgubne, gdy nie wezmą oni pod uwagę niuansów, o których specjaliści od użytkowników nawet nie zaczęliby projektu, gdyż w końcu są jego adwokatami. Project Manager może zapominać, że clue oprogramowania nie powinno tkwić tylko w wyobrażeniach zespołu, ale powinno spełniać określone standardy i funkcje. 

Specjaliści z Symetria UX opracowali podejście Proven Product Design, które ma załagodzić sytuację między zwaśnionymi stronami i podać im rękę na zgodę w formie kompromisu. 

Jak wygląda zwyczajowy Product Design?

Proces tworzenia produktu, jak każdy inny proces ma swoje warstwy i punkty kontrolne, bez których nie można byłoby nazwać tego procesem. Specjaliści z greenparrot.pl opisali siedem wystandaryzowanych kroków, bez znajomości których Product Designerzy mogliby mieć niemałe kłopoty z wdrożeniami rynkowymi. 

Najpierw zaczynają bowiem od analizy konkurencji i rynku, dzięki której określają kto ma jakie narzędzia, jaką pozycję, jaką opinię i ile potencjalnie zarabia. Konkurencją jest wszystko, co może odciągnąć użytkownika od naszego rozwiązania. Dla Netflixa może być to kino, ale także restauracja, w której młodzież będzie chciała spędzać czas wolny chętniej niż w kanale z czerwoną “Enką”. Po zidentyfikowaniu naszych konkurentów powinno się określić kryteria rynkowe, które są istotne dla celów i głównych założeń biznesowych z punktu widzenia firmy i powstającego produktu. Można rozszerzyć swoje badania o analizę popytu, prognozy rynkowe, SWOT, matrycę sił Portera czy też analizę biznesowego ryzyka. 

Następnym krokiem są szablony biznesowy, określane jako Business Model Canvas, które określają najważniejsze elementy związane z firmą i produktem, ale nie zajmują więcej niż kartka w formacie A4, co sprzyja jej przejrzystości i łatwiejszemu odbiorowi. Następnie, designerzy powinni skupić się na customer journey, czyli określeniu wszystkich punktów styczności z marką, z zapleczem zarówno sprzedażowym, jak i wizerunkowym dla produktu. 

Trzecim etapem jest bowiem zaprojektowanie zakładanego procesu usługowego, który ma spełniać potrzeby firmy, standardy rynku i potrzeby klientów. 

Po wstępnych analizach rynkowych, konceptualizacji pora spojrzeć na pojęcie event stormingu, którym nazywa się analizę wszystkich kluczowych elementów aplikacji, będących efektem burzy myśli projektanta lub zespołu.Jest to także etap, w którym tworzy się mapy wszystkich funkcji, które mogą znaleźć się w produkcie, dzięki czemu łatwiej będzie tworzyć łańcuchy akcji i reakcji, jednocześnie pamiętając o aktorach, integracjach oraz zdarzeniach generowanych przez aplikację.

Gdy faza event stormingu dobiegnie końca, projektant produktu może skupić się na opracowaniu wireframe, czyli szarego szkicu opisującego podstawowe działanie aplikacji oraz User Stories, które oznaczają zestaw opisów produktu, które ich użytkownik mógłby wyrazić jako opinia w momencie kontaktu z nim.

Punkt ten znacznie ułatwia skonstruowanie MVP, który jest opisem najprostszej wersji produktu, którą można poddać testowaniu pod kątem użytych w niej funkcjonalności. 

Testowanie jest ostatnim krokiem sprawdzającym prawdziwość założeń i rzetelność pracy Product Designera, który tworzy tutaj makiety interaktywne, które będzie można poddać serii testów z docelowymi użytkownikami, z których wnioski mają służyć do rozwoju produktu.

Czym jest PPD?

Proven Product Design ma to zwiększyć prawdopodobieństwo sukcesu produktu, który będzie skupiony zarówno na odbiorcach jak i biznesie. To myślenie o organizacji pracy w taki sposób, aby opierała się przede wszystkim na zwinności i badaniach. O roli badań coraz głośniej (na szczęście) słychać w korporacjach, tak i tutaj są one jednym z głównych filarów tworzenia produktu. Następną podporą dla tego systemu jest nauka, a dokładniej kognitywistyka, w towarzystwie ekonomii behawioralnej, będącej inter-dyscypliną łączącą socjologię, ekonomię, psychologię i neurobiologię. Nie mniej ważnym budulcem tej strategii jest podejście do projektowania w sposób uniwersalny, czyli w coraz częściej postulowanym modelu inkluzywnym. 

Z czego składa się Proven Product Design?

Product Design jest bardzo podobny do swojej ulepszonej wersji, ale niezbyt optymalny pod kątem zwinności oraz niezawierający od razu wszystkich odpowiedzi na bolączki produktu. Projektowanie produktu oparte o dowody czerpie je z:

• badań user experience, czyli rodzaju researchu skupionego wokół potrzeb użytkowników i cech badanych produktów. Badana jest użyteczność produktu oraz użytkowe potrzeby, co rozwija zrozumienie wobec użytkownika oraz tworzy chciane rozwiązania. Sprawnie przeprowadzone wywiady mogą także pozwolić na określenie wyróżników na tle konkurencji. 
• wiedzy o mózgu, czyli różnych potwierdzono naukowych teorii behawioralnych w obrębie psychologii i kognitywistyki, co pomaga przy opracowaniu produktu zgodnego z oczekiwaniami klientów i wręcz nakłaniającego do skorzystania z niego.
• cyfrowej dostępności, która zakłada projektowanie rozwiązań dostępnych dla osób z niepełnosprawnościami, ale też starszych. 

PPD w Scrum

Proven Product Design nie będzie mieć większych problemów ze Scrumem, o ile uczestnicy dobrze przygotują się do pierwszego sprintu, przed którym warto przeprowadzić zerówkę, czyli zgromadzenie wiedzy o rynku i produkcie, którą będzie można skonceptualizować, a koncepcję można jeszcze przetestować. Jest to konieczne, aby mieć zdefiniowany dokładny produkt w momencie tworzenia sprintu. Jako przykład podano zaprojektowanie strony systemu bankowości elektronicznej banku Santander, iBiznes24. W projekcie tym najpierw zdefiniowano kilka najważniejszych procesów, które zostały przetestowane z grupami odbiorców, a następnie wokół nich utworzono sprinty, które rozbudowywały serwis o dodatkowe funkcjonalności. 

4D, czyli proces projektowy PPD

Połaczenie scrumu z PPD dało spojrzenie na warstwę tworzenia oprogramowania pod kątem czterech kategorii, czyli odkrywania (Discover), definiowania (Define), kodowania (Develop) i dostarczania (Deliver).  

W fazie Discover chodzi o stworzenie koncepcji, która ma być efektem przekroju VoB, VoC i VoM, czyli biznesu, klientów i rynku. W skład biznesu wchodzą przedstawiciele wszystkich kluczowych dla firmy i produktu działów organizacji. Głos klienta sprawdzany jest badaniami, a głos rynku badaniami tegoż właśnie. Odkrywamy tutaj przeznaczenie i cechy produktu, czego efektem ma być pierwszy backlog – planowanie zadań do otrzymania gotowej wersji konkretnego produktu. W przeciwieństwie do zwykłego projektowania nie będziemy mieli tu do czynienia z minimalną wersją produktu, a z unikalną propozycją gotową do sprzedaży. Wszystko dzięki implementacji mierników UX, które w swoich pięciu kategoriach odzwierciedlają wszystkie rodzaje interakcji użytkownika z produktem. Miary służą jako monitoring zachowań użytkowników, co daje obiektywne miary na aspekty produktu, które mają rzeczywiste znaczenie dla końcowych użytkowników i biznesu. 

Przy definiowaniu tworzymy wizualizację osi produktu w postaci interaktywnego prototypu interfejsu. Ma on przypominać gotowy produkt, który będzie można przetestować z użytkownikami.

Gdy testy przejdą pomyślnie, można do przedsięwzięcia zaprosić deweloperów, którzy zaczynają kodować zgodnie z otrzymanymi od UX wskazówkami, a UX testują gotowe kody od programistów. 

Następnie uruchamiamy launch produktu, mierzymy jego efektywność dzięki określonym wcześniej KPI i sprawdzamy jego zgodność z założonymi wcześniej celami i pomysłami. Tutaj można uznać projekt za zakończony, chyba, że nie wpasowuje się w koncept z fazy discover, wówczas można rozpocząć optymalizację pod pożądanym przez product designera kątem.

Może Cię zainteresować: Jak włączyć UX Designera do SCRUM?