Cyfrowe produkty dr Frankensteina! Jak je rozpoznać i jak powstają?

Bardzo często jednak ten proces zaczyna odbiegać od pierwotnie wyznaczonego kierunku. Czasem są integrowane z innymi produktami. Albo sprzedane, kupione i przebrandowane. I nagle użytkownik staje twarzą w twarz z wyjątkowym tworem: cyfrowym produktem „dr Frankensteina”, który (nawet jeśli działa poprawnie) wygląda dziwnie, a czasem wręcz odstrasza. Przyjrzyjmy się bliżej tym procesom i sprawdźmy, jak unikać cyfrowych „potworów”, które nie spełniają standardów dobrego doświadczenia użytkownika.

One… czają się wszędzie! 

Każdy je zna, bo są dosłownie wszędzie. Przy tempie transformacji cyfrowej i złożoności systemów oraz platform, w których nad jednym projektem współpracują liczne zespoły (czasem liczące setki specjalistów), to właściwie nieuniknione.

Pomyśl o intranecie, który składa się z wielu narzędzi dołączanych przez lata. Albo o platformie e-commerce, która w trakcie płatności przenosi cię do zewnętrznego rozwiązania. A może o dziwnym okienku RODO wyskakującym przy wejściu na stronę, zupełnie niepasującym do jej wyglądu. Albo o sekcji FAQ, która nijak nie przypomina identyfikacji wizualnej firmy.

Przykładów jest mnóstwo i najprawdopodobniej spotykasz je codziennie. Zarówno w cyfrowym środowisku pracy, jak i poza nim, przeglądając Internet czy korzystając z różnych aplikacji. Cały świat cyfrowy to ogromna, barwna mozaika.

Czasami jest to tylko drobna niedogodność, do której łatwo się przyzwyczaić i prawie jej nie zauważasz. Ale w innych sytuacjach (zwłaszcza przy pracy z nowym produktem czy platformą) potrafi to być frustrujące. Szczególnie wtedy, gdy musisz szybko zakończyć proces i oczekujesz, że wszystko zadziała płynnie i bez rozpraszania. Widząc takie „szwy”, możesz poczuć lekki dyskomfort. Uczucie, jakby coś było nie tak.

A jeśli masz większe obeznanie technologicznie, możesz nawet zacząć zastanawiać się nad bezpieczeństwem swoich danych. Bo skoro system został poskładany naprędce i w nieuporządkowany sposób, to czy na pewno jest bezpieczny i dobrze przetestowany?

W większości przypadków produkty dr Frankensteina są jednak nieszkodliwe. To po prostu rezultat procesów zachodzących w organizacji, która je stworzyła, albo efekt nieuwagi ich twórców. Mogą być skomplikowane w obsłudze i potrafią niemiło zaskoczyć, ale, w większości przypadków, nie trzeba się ich bać.

W naszej roboczej definicji musi on składać się z co najmniej dwóch modułów, które różnią się wizualnie lub strukturalnie (albo w obu aspektach), a ta niespójność musi być widoczna dla użytkownika. Często (choć nie zawsze) są one spięte wspólną sekcją nawigacyjną, aby nadać narzędziu pozory spójności i zapewnić użytkownika, że nie ma do czynienia z próbą phishingu czy awarią systemu.

Takie cyfrowe produkty są zwykle pełne drobnych, irytujących niespodzianek. Mogą przekierować Cię do dziwnie wyglądającej części systemu albo proces nagle się przerwie. Może zmienić się wygląd aplikacji, a wzorzec nawigacji zostać przekształcony. Często w pasku adresu dzieje się coś nietypowego (jeśli mówimy o aplikacjach webowych działających w przeglądarce).

Są też bardziej subtelne sygnały, które dostrzeże tylko wprawne oko. Różnice w wielkości nagłówków, kształcie przycisków czy stylu ikon mogą budzić podejrzenie, że twórcy nie byli do końca uczciwi wobec użytkowników albo wystarczająco skrupulatni.

Jeszcze gorzej, gdy ktoś nieumiejętnie „zszył” różne moduły na głębszym poziomie. W takim przypadku możesz zostać poproszony o kilkukrotne wpisanie hasła podczas realizacji jednego procesu. Oczywiście organizacja może tłumaczyć, że korzysta z kilku systemów i każdy z nich wymaga osobnej weryfikacji. Ale jako użytkownik zwykle nie interesujesz się architekturą cyfrowego ekosystemu swojego banku czy dostawcy usług medycznych. W takim kontekście ciężar zostaje przerzucony na użytkownika, a nie na zespół wdrożeniowy, co powoduje dyskomfort i negatywne doświadczenie.

Mniej oczywistą konsekwencją takich „kolażowych” systemów jest brak transferu danych pomiędzy nimi. Skutkiem tego użytkownik jest proszony o podawanie tych samych informacji wielokrotnie, nawet jeśli zostały już wpisane w innej części ekosystemu.

Wady i słabości 

Można by powiedzieć, że jeśli narzędzie spełnia swoją funkcję, proces da się przeprowadzić, a technologia działa, to wygląd nie ma większego znaczenia, a skrupulatność w tym obszarze to tylko akademickie rozważania. Ale to ma znaczenie, i to z kilku powodów. Przyjrzyjmy się im bliżej i zobaczmy, dlaczego warto unikać niechlujnych cyfrowych produktów.

1. Zaburzone modele mentalne– gdy brakuje spójnej struktury lub nawigacja jest niespójna, dużo trudniej zrozumieć zasady działania produktu i nauczyć się, jak się po nim poruszać.
2. Utrudniona przyswajalność– produkty trudne do zrozumienia są trudniejsze do nauki, co wymaga przygotowania dodatkowych materiałów instruktażowych i wydłuża czas wdrożenia użytkowników.
3. Brak efektywności– niespójne procesy często skutkują wydłużonymi ścieżkami i nieoptymalną strukturą (np. większą liczbą kliknięć potrzebnych do wykonania zadania), co oznacza większe obciążenie poznawcze i więcej czasu spędzanego w aplikacji.
4. Większe zapotrzebowanie na wsparcie i Q&A– zagubieni i zdezorientowani użytkownicy częściej proszą o pomoc, co pochłania dodatkową energię zespołu wsparcia.
5. Złe doświadczenie użytkownika i niezadowolenie– niespodziewane, nieintuicyjne rozwiązania często prowadzą do rozczarowania i frustracji.
6. Zagrożenia dla cyberbezpieczeństwa– niespójności w projekcie mogą być wykorzystywane przez przestępców próbujących je naśladować.
7. Podważenie wiarygodności organizacji– klienci oczekują profesjonalnych, dobrze zaprojektowanych narzędzi. Widząc „szwy”, mogą zacząć kwestionować wizerunek firmy.
8. Trudność w utrzymaniu– systemy budowane bez spójnego design systemu są bardziej wymagające w obsłudze, a koszty ich utrzymania rosną w czasie.
9. Trudność w dalszym rozwoju– złożona struktura, systemy legacy oraz dług technologiczny i projektowy generują problemy dla zespołu rozwijającego produkt, który musi zmagać się ze wszystkimi niespójnościami, bibliotekami i wyjątkami.

Jak widać, produkty dr Frankensteina przysparzają problemów użytkownikom, ale w jeszcze większym stopniu obciążają organizacje, które je tworzą. Czy jednak można dostrzec jakieś pozytywne aspekty?

Czasem „szybko i byle jak” wystarczy lub jest jedyną opcją

Takie podejście może być szczególnie cenne dla startupów we wczesnej fazie, gdy czas i kompetencje są ograniczonymi zasobami, a szybkość wejścia na rynek jest kluczowa. Strategia ta wymaga mniejszej inwestycji, ale ma drugą stronę medalu. Ryzyko rozczarowania i odrzucenia produktu przez użytkowników jest większe.

Łącząc ze sobą różne komponenty, zespół produktowy może też szybko dodać brakującą funkcjonalność. Może się wydawać, że funkcjonalność jest ważniejsza niż jakość i czasami rzeczywiście tak jest, szczególnie w przypadku systemów używanych tylko wewnętrznie.

Pracownicy są w stanie nauczyć się obsługi produktu, zaakceptować jego niedoskonałości i ignorować niespójności. Wartość biznesowa i możliwość realizacji działań operacyjnych liczą się wtedy bardziej niż jakość designu czy user experience.

Ale w przypadku produktów kierowanych do szerokiej publiczności, które często oceniane są przez pryzmat wyglądu i użyteczności, taka strategia może być krótkowzroczna. Użytkownicy zazwyczaj dają produktowi tylko jedną szansę, a zespół ma tylko jeden moment, aby zrobić dobre wrażenie. Większość z użytkowników woli estetyczne, minimalistyczne rozwiązania od bezkształtnych, niechlujnych „tworów”.

Dlaczego powstają? Jak zminimalizować ryzyko stworzenia własnego „potwora Frankensteina”?

Nieuchronne powstawanie tego typu cyfrowych produktów jest konsekwencją wielu czynników zakorzenionych w organizacjach i w samej ludzkiej naturze. Można to wyjaśnić, obserwując i rozumiejąc, jak powstają i rozwijają się duże platformy, jakie procesy zachodzą w firmach, jak wygląda ich struktura i zarządzanie produktami, a także – wreszcie – jakie słabości ludzkiej natury odgrywają tu swoją rolę.

Oto kilka typowych powodów:

1. Słabe zarządzanie produktem i brak strategii produktowej
2. Brak świadomości projektowej w różnych zespołach
3. Brak spójnego języka projektowego – organizacje często nie posiadają jednolitego języka projektowego ani przewodnika stylu stosowanego we wszystkich produktach cyfrowych. Skutkuje to niespójnością w projekcie i user experience.
4. Przeciętność i słaba jakość wykonania – trzeba przyznać, że w wielu firmach oczekiwania nie są wystarczająco wysokie, a juniorzy i niedoświadczeni członkowie zespołu pozostają bez wsparcia i nadzoru. To prowadzi do rezultatów o niezadowalającej jakości.
5. Fuzje i przejęcia – organizacje połączone w wyniku fuzji lub przejęć mogą mieć różne zespoły projektowe i deweloperskie, które stosują odmienne style i podejścia. To prowadzi do braku spójności w produktach cyfrowych.
6. Różni interesariusze – poszczególni interesariusze w organizacji mogą mieć odmienne preferencje projektowe i priorytety, co skutkuje niespójnościami. Na przykład marketing może kłaść nacisk na branding i atrakcyjność wizualną, a dział inżynieryjny – na funkcjonalność i efektywność.
7. Brak komunikacji – brak dobrej komunikacji między zespołami projektowymi a deweloperskimi prowadzi do niespójności. Projektanci mogą nie rozumieć w pełni ograniczeń technicznych, a deweloperzy – wymagań projektowych.
8. Zespoły pracujące nad różnymi częściami ekosystemu nie są odpowiednio koordynowane – z czasem drobne różnice w standardach wizualnych i rozbieżności w stosowaniu zasad prowadzą do dużych różnic i luk między modułami.
9. Systemy legacy – w organizacjach często istnieją systemy starszej generacji, które trudno zaktualizować lub zintegrować z nowymi rozwiązaniami, co prowadzi do niespójności. Takie systemy zwykle powstawały według odmiennych zasad projektowych i deweloperskich niż nowsze narzędzia.
10. Ograniczone zasoby – organizacje mogą mieć zbyt mało zasobów na projektowanie i rozwój, co skutkuje brakiem spójności. Często muszą przedkładać inne aspekty działalności nad konsekwencję projektową.

Cyfrowe produkty typu „dr Frankensteina” ujawniają strukturę organizacji albo historię 

To fascynujące, jak subtelne sygnały w systemach mogą zdradzać elementy historii organizacji albo sposób jej zorganizowania. O ile wiesz, na co patrzeć.

Można wyróżnić kilka powtarzających się wzorców, a każdy z nich może skutkować „połatanym” produktem:

1. Fuzja – produkt powstaje z połączenia dwóch lub więcej systemów w wyniku przejęcia lub połączenia firm (M&A). Organizacja nabywa produkt w jakiś sposób komplementarny do swojego głównego rozwiązania, ale nie inwestuje w dokładną integrację, wybierając rozwiązania ad hoc.
2. Silosowe projektowanie lub rozwój – gdy różne zespoły odpowiadają za różne części ekosystemu, mogą korzystać z odmiennych standardów wizualnych lub komponentów, które są łączone dopiero po zakończeniu prac. Bardzo często prowadzi to do niespójności strukturalnych lub wizualnych. Zespoły kreatywne, działające bez nadzoru i narzędzi, szybko wprowadzają różnice do ekosystemu produktów.
3. Regionalna struktura biznesowa – zdarza się, że organizacje są podzielone na jednostki regionalne lub krajowe. W takiej sytuacji, zwłaszcza gdy struktura jest luźna i regiony mają dużą niezależność, bardzo często każdy z nich rozwija własne narzędzie. Takie platformy są niespójne, bo tworzone są przez różne zespoły wewnętrzne albo zewnętrzne agencje, bez globalnej koordynacji czy wspólnego design systemu.
4. Pochopny i nieuważny rebranding – kiedy organizacja zmienia markę, pojawia się wiele elementów do uwzględnienia. Nierzadko jednak mniej używane systemy są rebrandowane tylko częściowo. Zmiana wizualna produktu sprowadza się wówczas jedynie do kluczowych elementów (np. logo czy wybranych części systemu, takich jak nawigacja, font czy kolor), podczas gdy reszta pozostaje po staremu. Co oczywiście skutkuje doświadczeniem typowo „frankensteinowskim”.

Dlaczego tak trudno zadbać o funkcjonalność i uniknąć błędów? 

Teoretycznie wystrzeżenie się tych wszystkich gromadzonych latami błędów jest możliwe, ale w praktyce to zadanie niezwykle trudne, ponieważ istnieje wiele czynników i zjawisk, które w naturalny sposób prowadzą do powstawania cyfrowej entropii i stopniowego zaniku spójności.

Aby uniknąć tworzenia cyfrowych produktów „doktora Frankensteina”, organizacja (a w szczególności product managerowie, projektanci i lead developerzy) musi świadomie i konsekwentnie opierać się chaosowi oraz pokusie skracania drogi na każdym kroku.

Krótki czas na realizację i ograniczone budżety – ograniczenia zasobów występują w każdej organizacji. Jeśli oczekiwania są nierealistyczne, zespół będzie szukał rozwiązań, które mogą wydawać się optymalne do osiągnięcia krótkoterminowych celów, ale w dłuższej perspektywie prowadzą do problemów i chaosu.

Brak zrozumienia długoterminowych konsekwencji pochopnych działań – skracanie drogi działa dobrze w wybranych sytuacjach, jeśli jest świadomość, że szybkość jest faworyzowana kosztem dokładności i spójności. Jednak jeśli taki styl zarządzania produktem staje się standardem, nieuchronnie prowadzi do erozji i pogorszenia jakości produktu.

Niewidoczne koszty psucia cofrowego produktu – początkowo koszty szybkiego działania i realizacji projektów bez standardów są niewidoczne. Drobne niedokładności dostrzegają jedynie ci, którzy dobrze znają produkt. Jednak takie drobne pęknięcia z czasem przekształcają się w głębokie rysy, które powodują poważne problemy.

Brak zrozumienia, jak wygląda cykl życia cyfrowego produktu – tempo pracy nad produktem o ograniczonym zakresie i małym zespole z natury jest szybkie. Wraz ze wzrostem zespołu pojawia się większy opór ze strony organizacji, a podejmowanie decyzji oraz koordynowanie pracy zajmuje więcej czasu. Dodatkowo, złożoność produktu oznacza, że dodawanie nowych elementów wymaga większej uwagi i koordynacji, a także testowania i sprawdzania spójności. Jeśli te dynamiki nie są rozumiane przez zespół zarządzający, który wymaga stałego tempa rozwoju, prowadzi to do skrótów i niedokładności.

Jak uleczyć cyfrowy produkt „dr Frankensteina” (albo przynajmniej sprawić, by wyglądał przyjaźniej)?

Jeśli struktura danych systemu została poprawnie zaprojektowana, a architektura użytkownika nie jest fundamentalnie zepsuta i niespójna, istnieje szansa, że przy odpowiednim podejściu, wysiłku i odrobinie cierpliwości narzędzie da się uratować. Ogromnie pomaga w tym stworzenie i utrzymywanie spójnego design systemu.

Zazwyczaj istnieje kilka podejść do „leczenia” tak poszatkowanych cyfrowych produktów.

Jednak, jeśli problemy leżą głębiej (architektura informacji jest zepsuta) jedynym rozwiązaniem bywa całkowita przebudowa, a nawet stworzenie produktu od zera. To oczywiście wymaga znacznie większej inwestycji i czasu (każdy produkt ma swoje granice życia) i odporności na niekontrolowane projektowanie oraz rozwój. Cenę i tak się zapłaci – w kosztach utrzymania, w utracie wiarygodności, a co najważniejsze, we frustracji użytkowników.

Bądź wyrozumiały, gdy spotkasz jednego… 

Przy stale zmieniającej się technologii, rosnącej złożoności naszego świata i niedoskonałościach zarządzania w organizacjach nie da się uniknąć pośpiesznie budowanych produktów. Jak jednak pokazaliśmy, w niektórych sytuacjach ich istnienie jest uzasadnione. Dlatego jako użytkownicy powinniśmy mieć nieco pobłażliwości dla takich „zdeformowanych dusz”.

…ale nie twórz własnego

Jako projektanci i product managerowie powinniśmy jednak wykazać się większą konsekwencją w codziennej walce o spójność i właściwe metody pracy. Dzięki możliwości optymalizacji systemów typu legacy i nowoczesnym narzędziom do zarządzania produktami, design systemom, stylom w Figmie, większej świadomości i empatii możemy robić to lepiej. Jeśli będziemy bronić jakości naszej pracy, istnieje spora szansa, że cyfrowe produkty „dr Frankensteina” nie będą tak często straszyć innych ludzi.

Obecnie, dotyczy to nazbyt często integracji sztucznej inteligencji. Zamiast na siłę „doszywać” kolejne modele czy chatboty, warto świadomie planować ich rolę w ekosystemie produktu i uczyć zespoły odpowiedzialnego korzystania z każdej nowości.