Idealny proces powstawania nowego produktu

Prawdziwa rola projektanta to rozwiązywanie problemów, chociaż przez innych może być postrzegana jako dostarczanie propozycji, jak powstające rozwiązanie powinno działać i z czego się składać. Zanim jednak zaczniesz rozwiązywać problemy, potrzebujesz wiedzy na temat wzorcowego procesu tworzenia produktów cyfrowych. W tym artykule przedstawiam największy problem, z jakim możesz się spotkać.

Informacje to nic innego, jak zbiór pewnych danych na kilku poziomach. Pierwszy poziom to wszelkie dane dotyczące projektu. Najczęściej przyjmują one postać wymogów biznesowych. Wszystko to, co pozwala Ci zrozumieć zawartość projektu, jego oczekiwaną formę i zawartość. Drugi rodzaj informacji to powody, dla których dany projekt ma zostać zrealizowany. Są to m.in. badania rynkowe, analizy biznesowe i analizy konkurencyjnych rozwiązań. Ostatni rodzaj informacji powstaje podczas realizacji projektu i może się wiązać zarówno z możliwościami i ograniczeniami technicznymi, jak i danymi z testów użyteczności. Są to informacje, które powstają w wyniku aktywności osób pracujących nad produktem.

Demotywujący brak informacji

Możemy wydzielić jeszcze jeden rodzaj informacji – dane, które pokazują, jak produkt poradził sobie na rynku i czy spełnił oczekiwania biznesowe (np. szacowane zainteresowanie użytkowników lub udział w rynku). Te informacje pojawiają się często kilka miesięcy po zakończeniu pracy nad projektem, dlatego opiszę je na końcu.

Rodzaje informacji wiążą się ściśle z największym problemem, z jakim możesz się spotkać – ich brakiem. Oto kilka przykładów:
• Pojawia się informacja o nowym projekcie, ale nie zostają wyjaśnione powody, dla których produkt ma powstać i jakie są jego szanse na osiągnięcie sukcesu.
• Pojawiają się wymagania biznesowe, ale bez informacji, czy powstały one w wyniku analizy rynku i potrzeb konsumentów.

W przypadku tych dwóch przykładów problemy z przepływem informacji mogą nieść sporo konsekwencji, które najczęściej sprowadzają się do jednego – zastanawiania się nad sensem pracy nad projektem. Dyskomfort z tym związany może destrukcyjnie wpływać na motywację i zaangażowanie, szczególnie w przypadku zespołu realizującego projekt od strony technicznej. Wszyscy chcemy robić rzeczy, które mają sens, i brak jakiejkolwiek informacji odbierany bywa jako negatywny sygnał, że informacje prawdopodobnie są ukrywane, bo mogłyby zdemaskować czyjąś niekompetencję.

Skutki braku informacji

Nie ma znaczenia, czy za brakiem informacji skrywa się niedbałość, brak szacunku czy obawa przed dyskusją. Ta sytuacja powoduje, że powoli tracimy komfort skupienia się na swojej części procesu realizacji projektu. Tracimy też zapał i mamy problem z utrzymaniem jakości pracy. Poniżej potencjalne skutki braku informacji.

1. Projekt jest realizowany, ale proces nie przewiduje badań i testowania produktu we wczesnej fazie jego istnienia, w konsekwencji nie wiadomo, w jaki sposób zareagują na niego potencjalni użytkownicy.

Brak informacji o użytkownikach najbardziej odbija się na projektantach. Bez wiedzy o użytkownikach, bez testowania konceptów rozwiązań jesteś zmuszony do zgadywania, co będzie użyteczne i intuicyjne z punktu widzenia użytkownika końcowego. To z kolei zabiera Ci podstawowe argumenty podczas określania docelowego rozwiązania i upraszcza Twoją rolę. Stajesz się wówczas twórcą makiet i prototypów, które nie mają nic z prawdziwego UX. Projektant bez danych staje się tylko specjalistą od wykorzystywania standardów. Praca w takich warunkach negatywnie wpłynie na rozwój umiejętności projektowych.

2. Projektowanie odbywa się bez informacji o możliwościach i ograniczeniach technicznych, przez co nie wiadomo, czy decyzje projektowe są możliwe do zrealizowania oraz czy i jak wpłyną na czas pracy zespołu deweloperskiego.

Brak informacji o możliwościach i ograniczeniach technicznych może mieć spore konsekwencje przede wszystkim w przypadku pracy projektowej. Rozbieżność wizji i realnych możliwości może doprowadzić do wydłużenia czasu projektu lub do kompromisów, które mogą zmienić pierwotny, przemyślany i przebadany koncept, a tym samym sprawić, że poniesione wcześniej koszty w jakimś stopniu pójdą na marne.

3. Brak informacji o tym, jak produkt poradził sobie na rynku oraz czy pokładane w nim nadzieje biznesowe znalazły odzwierciedlenie w rzeczywistości.

Brak informacji o tym, jak produkt poradził sobie na rynku, może uprzedmiotowić Twoją rolę i sprawić, że poczujesz się mało znaczącym ogniwem procesu. To wszystko jest istotne, aby poprowadzić Cię w stronę bardzo ważnego wniosku. Brak przepływu informacji, niezależnie od ich rodzaju, negatywnie wpływa na ludzi, ich motywację, zaangażowanie i poczucie sensu wykonywanej pracy, a to może pośrednio odbić się na jakości produktu lub czasie jego wykonania. Po wyjaśnieniu wagi informacji, prezentuję wzorcowy proces realizacji projektu osadzonego w duchu User-Centered Design i środowisku zwinnego projektowania (agile).

Wzorcowy proces realizacji produktu

1. Etap rozpoznania i analizy
Powstanie każdego dobrze zaplanowanego produktu powinno zostać poprzedzone rozpoznaniem rynku i analizą. Efektem tego działania winien być pomysł na produkt oraz kierunek, w którym powinien ewoluować. Jako przykład (czysto hipotetyczny) weźmy mężczyzn, którzy stają przed obowiązkiem podlewania roślin w swoim mieszkaniu. Przeprowadzamy rozpoznanie rynku i okazuje się, że najczęstsze problemy, jakie im towarzyszą, to brak wiedzy na temat roślin oraz sposobu dbania o nie, a także długa lista codziennych obowiązków, które przyczyniają się do zaniedbywania dodatkowych czynności.

Tak rodzi się pomysł wykorzystania urządzenia mobilnego, które ma pomóc w rozwiązaniu tego problemu, poprzez rozpoznanie roślin oraz określenie częstotliwości ich podlewania. Koncept opiera się także na założeniu, że aplikacja ma przynosić dochód dzięki wersji podstawowej oraz wersji rozszerzonej z dodatkowymi funkcjonalnościami i bardziej zaawansowanym systemem notyfikacji. Dodatkowe badania wykazały, że wykorzystanie aplikacji mobilnej ma duże szanse na odniesienie sukcesu. Szczególnie, jeśli faktycznie będzie potrafiła rozpoznać dany kwiat i określić jego zapotrzebowanie na wodę.

2. Możliwości i ograniczenia techniczne
Mamy już istotne informacje o potencjalnych klientach oraz ogólną wizję produktu wyrażoną w postaci wymagań biznesowych. Myślę, że bez trudu przychodzą Ci do głowy różne sposoby, w jakie taka aplikacja mogłaby działać. Pokusa rozpoczęcia projektowania jest duża, ale to właśnie jest ten moment, kiedy powinieneś zderzyć wizję z możliwościami jej realizacji. W naszym przykładzie aplikacja może rozpoznać konkretną roślinę oraz oszacować jej zapotrzebowanie na wodę. To oznacza, że musisz uwzględnić nie tylko czynność wykonaną przez użytkownika (skorzystanie z danej funkcjonalności), ale przede wszystkim informacje, które musi dostarczyć aplikacja na podstawie np. zdjęcia rośliny. I to najlepiej tuż po wykonaniu akcji przez użytkownika.

Sposób, w jaki zaprojektowałbyś aplikację, mógłby wpłynąć na jego techniczną realizację. Dlatego dobrze jest poznać ograniczenia techniczne, które traktujemy jako ograniczenia projektowe. Celem zderzenia wymagań biznesowych z możliwościami i ograniczeniami technicznymi powinien być ogólny zarys, jak nasza aplikacja może działać oraz skąd czerpać niezbędne informacje. Teraz możemy przejść do projektowania.

3. Etap projektowania i testów
Masz już wystarczająco dużo informacji, aby przystąpić do projektowania. Co ważne, podejmowane przez Ciebie decyzje projektowe będą uwzględniały dwa istotne punkty widzenia: biznesowy (oczekiwania) oraz techniczny (możliwości). Każde dodatkowe informacje o użytkownikach również będą miały znaczenie, bo Twoja praca ma być podparta danymi, a nie przypuszczeniami.

Przed projektowaniem sprawdź, czy podobne rozwiązania nie zostały już wcześniej zaprojektowane. Nie ma sensu wymyślać koła na nowo, zwłaszcza że doświadczenie użytkownika względem jednej marki buduje się we wszystkich jej produktach i usługach. Sprawdzasz także rozwiązania konkurencji, aby mieć świadomość, co już można znaleźć na rynku i czy przypadkiem nie ma gotowych standardów rozwiązań. Zaczynamy wchodzić w erę poprawności budowania produktów na bazie standardów i szablonów. W tym momencie patrzymy jeszcze z góry na cały proces, w którym Twoja rola jest tylko jednym z jego etapów.

A zatem projektujemy. Każdy koncept powinien zostać zderzony z realnymi użytkownikami, których uwagi pomogą Ci poprawić niezrozumiałe elementy interfejsu oraz interakcje. To ważne, bo będziesz mógł zobaczyć, jak ma się Twoja wizja do realnego użycia przez docelowego użytkownika. Każda zmiana w prototypie, której dokonasz dzięki informacjom uzyskanym z badań, powinna również zostać przebadana, ponieważ musisz mieć pewność, że Twoje zmiany są tym, czego oczekuje użytkownik.

Celem badań jest nie tylko sprawdzenie, w jakim stopniu poprawnie rozumiemy oczekiwania i potrzeby użytkowników, ale także stworzenie interfejsu, którego czas zaadaptowania przez użytkownika będzie możliwie najkrótszy. Dlatego należy dużą uwagę poświęcić kontekstowi, w jakim nasz produkt będzie używany. O jakiej porze podlewamy rośliny? Gdzie to się odbywa? Miejsce odgrywa tutaj bardzo ważną rolę, bo z każdym miejscem powiązane są jakieś warunki, jakiś szum informacyjny, jakieś zdarzenia rozpraszające naszą uwagę (np. jeśli podlewamy rośliny w domu, to przeszkodą może być pies domagający się spaceru). Pamiętaj też, że w przypadku aplikacji mobilnych pojawiają się takie dodatkowe czynniki, jak dostęp do internetu, prędkość połączenia czy jego stabilność. Te specyficzne warunki są niemożliwe do odtworzenia w budynku, w którym pracujesz (gdzie prawdopodobnie istnieje łącze o prędkości i stabilności niespotykanej w zwykłych mieszkaniach). A warunki te mogą się okazać kluczowe w ocenie przydatności i jakości wykonania produktu, nad którym pracujesz.

4. Wdrożenie
Prawdopodobnie Twój projekt będzie zatwierdzany przez Product Ownera. Zdarza się, że może również wymagać akceptacji wewnątrz Twojego zespołu projektantów, którym będzie zależało na spójnych rozwiązaniach, które użytkownik już poznał i których nie będzie musiał się uczyć. Zaakceptowany projekt przechodzi do kolejnego etapu i zaczyna być wdrażany. To niezwykle istotne, abyś był przy projekcie również w momencie, kiedy prawdziwy użytkownik zacznie z niego korzystać. Żebyś nie zapominał o odpowiedzialności za cały proces, a nie tylko za makietę, prototyp czy badania. Jeśli nie dopilnujesz projektu, wówczas przy jakimikolwiek problemie technicznym podczas wdrożenia perspektywa użytkownika może zejść na dalszy plan (nie będzie miał kto jej bronić), a wtedy finalna wersja produktu może się ostatecznie różnić od tego, co zaprojektowałeś.

Po każdym wdrożeniu pozostaje pytanie: czy nam się udało? Czy ten projekt spełnił pokładane w nim oczekiwania? Odpowiedź na to pytanie daje KPI (Key Performance Indicator). Przykładowo, czy nasza aplikacja przypominająca o podlewaniu kwiatków została w danym okresie po jej publikacji ściągnięta X razy oraz czy X% użytkowników wykupił wersję pro? Takie szacunki są określane na początku projektu i na nich opiera się odpowiedź, czy udało się osiągnąć zamierzony cel.

W przypadku projektów, które ulepszają istniejące funkcjonalności, porównuje się dane przed rozpoczęciem prac (które często są też powodem realizacji projektu) z danymi po wdrożeniu rozwiązania. Przykładowo możemy pracować nad formularzem rejestracji, który charakteryzuje się dużym stopniem porzucenia (bouncerate). Celem projektu może być obniżenie tego wskaźnika poprzez wyeliminowanie problemów, które napotykają użytkownicy. Powodem może być np. konieczność podawania zbyt dużej ilości danych, nieintuicyjny formularz czy walidacja pól formularza, która nie wyjaśnia przyczyny błędu.

Kilka rad na koniec

Opisałem w skrócie właściwie skonstruowany proces, w którym wszystkie istotne informacje (biznesowe, techniczne i dotyczące użytkowników) pojawiają się w określonych momentach, przyczyniając się do podejmowania bardziej świadomych decyzji. Pamiętaj, że jedną z podstawowych przeszkód w Twojej pracy jest brak zrozumienia, na czym ona rzeczywiście polega i jaką wartość możesz wnieść do procesu. Dlatego działaj otwarcie, nie ukrywaj swoich przemyśleń i prezentuj sposób realizowania zadań. Im mniejsza świadomość UX w firmie, tym bardziej wsparte badaniami projektowanie zorientowane na użytkownika będzie postrzegane jako zwiększanie kosztów oraz wydłużanie czasu realizacji projektu.

Pamiętaj również o informacji, która w organizacjach jest niezwykle cenna, a przez to często blokowana w niektórych jej obszarach. Przepływ wiedzy to nie tylko podstawa pracy z oczywistym celem i zrozumieniem, lecz także podstawa dobrze zaprojektowanych produktów. Dlatego też staraj się być punktem styku między różnymi działami w firmie. Ułatwiaj przepływ informacji i minimalizuj problemy, które wynikają z ich braku. Deweloperzy powinni rozumieć, dlaczego mają coś wykonać, a ludzie z biznesu powinni znać możliwości i ograniczenia techniczne. Jesteś szczególnym elementem tego procesu, który zderza ze sobą trzy różne punkty widzenia: biznesowy, techniczny oraz użytkownika, którego wygodę i zadowolenie reprezentujesz w tym procesie.

Michał Aleksander
Z wykształcenia dziennikarz, który w pewnym momencie skręcił w stronę technologii i projektowania. Przez 5 lat projektował dla dużego serwisu e-commerce w Europie Środkowo-Wschodniej, mocno skupiając się na mobilności, rozpoznaniu potrzeb użytkownika oraz naturalnym kontekście użycia projektowanych produktów. Obecnie projektant i UX manager w największej na świecie firmie edukacyjnej, w której koncentruje się na porządkowaniu procesów, wypracowywaniu najlepszych podejść projektowych oraz metodach warsztatowych. Autor książki „Jak stać się lepszym projektantem”.