Projektowanie produktów cyfrowych w oparciu o właściwe decyzje

Materiał Partnera
7 min

Swoboda w fazie projektowania jest pułapką, w którą łatwo wpaść, gdy przebywa się daleko od warstwy biznesowej i technicznej. Każdy produkt jest systemem naczyń połączonych, a na ich końcu znajduje się infrastruktura, która dyktuje, co jest możliwe do realizacji w ramach określonej iteracji projektu. Brak znajomości tej infrastruktury jest pierwszym krokiem do rozsynchronizowania designu i samego wdrożenia, a w konsekwencji prowadzi do wydłużenia procesu wytwarzania produktu. API (Application Programming Interface) to dyktator, który bywa nieugięty.

Lepiej czy szybciej?

Proces tworzenia produktu to nic innego, jak seria decyzji o różnej wadze i charakterze. Jedną z najczęściej występujących jest decyzja o tym, czy dane rozwiązanie chcemy zaimplementować lepiej, czy szybciej. Lepiej oznacza zazwyczaj dłuższy development i wyższą jakość produktu. Szybciej to z kolei wariant bezpieczny, często polegający na wykorzystaniu rozwiązań natywnych lub już istniejących. Decyzja o tym, który “guzik nacisnąć”, jest złożonym procesem, podczas którego analizujemy niewidzialne z bliska czynniki i warunki. Argumenty bywają zmienne w zależności od dynamiki projektu, celów, terminów realizacji, kompetencji czy zasobów finansowych.

W początkowej fazie projektu, gdzie głównym celem jest weryfikacja koncepcji, to ta tańsza i szybsza opcja będzie wiodła prym. Jakość czy użyteczność rozwiązania stanowią wówczas drugi plan i nie mają tak dużej wartości, jak błyskawiczna realizacja i gotowość produkcyjna. Wiele ulega zmianie, gdy produkt uzyskuje stabilność i to jego jakość staje się czynnikiem, który decyduje o sukcesie i wyprzedzeniu konkurencji. Wtedy to podejście lepiej okazuje się ważyć na szali więcej i podejmowane rozwiązania są bardziej złożone i jakościowe, co często implikuje zmiany w infrastrukturze produktu. Teraz jest już na nie czas, zasoby i priorytet w organizacji.

Jeśli zespół projektowy nie jest świadomy, jaki kurs panuje w danej fazie rozwoju produktu, to proponowane rozwiązania będą strzelały z dala od celu. Na przykład pojawi się potrzeba na nową funkcjonalność, do której projektant zastosuje najlepsze możliwe rozwiązanie. Chwilę potem może się okazać, że jest ono niemożliwe lub zbyt drogie, a całość wymaga uproszczenia lub przynajmniej wyraźnego sfazowania. Proces projektowy wraca wtedy do początku, a firma właśnie straciła czas i pieniądze.

- Advertisement -

Infrastruktura produktu czy organizacji to zazwyczaj zaawansowana i trudna do zrozumienia sieć. Z pozoru proste rozwiązanie na poziomie designu, może zderzyć się z niewidzialną górą lodową w momencie analizy technicznej. Chcemy, żeby kategorie produktów w naszej aplikacji miały ikony, które korzystnie wpływają na użyteczność i estetykę designu? Świetnie. Okazuje się jednak, że CMS, na którym oparty jest sklep, nie przewidział takiego pola. Czy można je dorobić? Tak, ale to potrwa, a dług technologiczny może spowodować problemy wydajnościowe. Czy można ominąć CMS i umieścić ikony bezpośrednio w produkcie? Można, ale dynamika zmian w kategoriach produktów jest na tyle duża, że będzie to wymagało zbyt częstego release’u aplikacji i w konsekwencji spowoduje to efekt odwrotny od oczekiwanego.

Jaką więc podjąć decyzję? To zależy, czy chcemy lepiej, czy szybciej.

Estetyka biznesowa

Aspekt wizualny produktu jest podrzędny wobec jego użyteczności, to prawda stara jak świat. Ambicje projektantów są jednak nieustannie obecne w procesie tworzenia produktu, co czasem sprawia, że propozycja rozwiązania może okazać się niezgodna z realizowanymi celami biznesowymi. Przykład? Nie istnieje projektant, który lubi bannery sprzedażowe. Niektórzy w swoich projektach pomijają je zupełnie, inni wybierają opcję życzeniową i próbują zdjąć z nich cały marketingowy krzyk, zmieniając ich estetykę na subtelną i nieinwazyjną. Rzeczywistość jest jednak inna. Banner, na który biznes potrzebuje miejsca na stronie głównej, jest kurą przynoszącą do budżetu firmy sto tysięcy złotych jajek w ciągu miesiąca. Argument projektanta o tym, że jest brzydki, może zostać skwitowany jedynie lekkim uśmiechem. Jak można podejść do tego inaczej? Nie zaklinając rzeczywistości.

Zdecydowana większość produktów cyfrowych, z jakimi mamy do czynienia, ma określone cele biznesowe – zazwyczaj sprzedaż usług i produktów. Aby pogodzić z nimi aspekt wizualny należy opracować reguły i wytyczne, którymi powinien kierować się zespół marketingowy tworząc kreacje. Pozwoli to na stworzenie estetycznych produktów, bez utraty na ich wartości marketingowej.

Gdzie PM-ów sześć…

Design i development to dwa etapy procesu, które powinny pracować ze sobą wyjątkowo blisko. Każdy rozdźwięk pomiędzy projektem a wdrożeniem jest spadkiem efektywności całego procesu. Szczególnie wyraźne jest to w produktach, w których w fazę designu i developmentu zaangażowane są różne firmy. Uniknięcie chaosu komunikacyjnego jest niemal niemożliwe, nawet wspomagając się takimi narzędziami jak design systemy, których rolą jest facylitacja procesu przekazywania projektu z rąk projektantów w ręce zespołu developerskiego. Czynnik ludzki i brak płynnej komunikacji sprawią, że proces tworzenia produktu będzie co rusz napotykał na progi spowalniające, a finalny efekt może być jakościowo zgoła odmienny od oczekiwanego.

Przykład – zaprojektowanie procesu rejestracji według najlepszych praktyk, z dużym prawdopodobieństwem zetknie się z ograniczeniami API, które nie pozwoli na odwzorowanie projektu. Lepszym rozwiązaniem byłaby analiza możliwości technicznych przed przystąpieniem do projektowania. Następnie dopasowanie projektu do warunków i środowiska, w jakim jest realizowany, przy jednoczesnej próbie znalezienia małych usprawnień tej infrastruktury, aby polepszyć doświadczenia użytkownika. Brzmi dobrze, ale jest niemal niemożliwe w sytuacji, w której design i development realizowane są w dwóch różnych miejscach, przez dwa różne zespoły, a dodatkowo w różnym czasie.

Jak tego uniknąć? Ograniczyć liczbę podwykonawców, ktoś powie. Oczywiście łatwiej powiedzieć niż zrobić, zwłaszcza jeśli przetarg został już rozstrzygnięty. Inne wyjście? Wszystko dokumentować. Projektanci potrzebują wiedzy technicznej, a programiści potrzebują rozumieć intencje, jakie kryją się za daną wizualizacją rozwiązania. Dokumentacja nie jest lekiem na całe zło, ale z pewnością przyczyni się do usprawnienia procesu asynchronicznej wymiany wiedzy.

Sama wiedza nie jest jednak gwarantem jakości wdrożenia. W parze z nią musi iść świadome zwiększenie kontroli nad całością procesu i złapanie perspektywy na jego rozwój z lotu ptaka. Wartościowe okazuje się wówczas utworzenie roli w zespole, która będzie odpowiedzialna za koordynację prac, kierunek rozwoju i jakość produktu, łącząc kompetencje wielu zespołów i dbając o antycypację problemów poprzez odpowiednie planowanie harmonogramu.

Autor: Łukasz Okoński, Product Design Lead w Future Mind

Udostępnij
- REKLAMA -