Mnogość bibliotek z gotowymi komponentami sprawiła, że często to developerzy są odpowiedzialni za projekt funkcjonalny i interfejs graficzny produktu cyfrowego. Na pewno pomaga to w wizualizacji pomysłu, ale czy takie rozwiązanie odnajdzie się na rynku i zyska sympatię użytkowników?
Czy spotkałeś się z określeniem „designed by developer”? Oznacza to, że strona, aplikacja lub sklep internetowy zostały zaprojektowane przez developera, a nie projektanta UX. Nie ma w tym nic złego, że nasz produkt zaprojektuje developer. Jednak z naszego doświadczenia wynika, że przychodzi moment, w którym musimy zmierzyć się z konsekwencjami tego, że nasz produkt powstał bez udziału projektanta UX. Jakie problemy zauważyliśmy przy pracy z takimi produktami?
Czy specjalista UX jest potrzebny w zespole produktowym?
Załóżmy, że zdecydowaliśmy się wypuścić nasz produkt zaprojektowany wyłącznie przez zespół developerski. Bez wątpienia taki produkt działa bez zarzutu, ale bądźmy szczerzy – większość projektów nie kończy się katastrofą przez błędy w kodzie, ale przez to, że są zbyt skomplikowane w użyciu, niedopasowane do grupy odbiorców lub nikomu niepotrzebne. A to wszystko dlatego, że rzeczywiste potrzeby i problemy użytkownika końcowego nie zostały dostatecznie dobrze zidentyfikowane i zaadresowane.
Software house’y, z którymi pracowaliśmy, często zwracają się do nas z następującym problemem – pomimo tego, że na back-endzie software robi cuda, to klient ocenia go pod kątem niezbyt udanego interfejsu, skarżąc się „naprawdę tyle zapłaciliśmy za coś takiego?”.
To dlatego, że nie było osoby w zespole, która od samego początku miała na uwadze użyteczność naszego produktu. Nie było analiz użytkowników, badań zachowań czy testów prototypów, które pokazałyby nam, co użytkownik stara się zrobić – a tym wszystkim zajmuje się UX designer.
Projektant UX jest zaangażowany na każdym etapie tworzenia produktu. Od początkowych etapów, kiedy ustalamy zakres naszego projektu po optymalizację wdrożonego produktu. Przeczytasz o tym więcej w naszym poprzednim artykule.
Jakie błędy w UX popełnia developer?
Najczęstszy błąd, z którym spotykaliśmy się projektach tego typu, to przedstawianie subiektywnych założeń zespołu na temat zachowań użytkowników jako obiektywnych faktów. Wymówki typu: „Znamy naszych użytkowników, wiemy, czego chcą”kończą się na tym, że nasz produkt powstaje wyłącznie w oparciu o nasze wyobrażenia (subiektywne odczucia), a nie o zebrane dane (fakty), które umożliwiłyby nam sprawdzić, czy kierunek, w którym idziemy, jest właściwy i czy nie marnujemy swojego czasu na budowanie błędnego rozwiązania, które nie ma szansy odnaleźć się na rynku.
Podobnym błędem jest generalizowanie we wnioskowaniu, jak powinna zostać zrealizowana jakaś funkcjonalność. Takie uogólnianie odbywa się zazwyczaj na podstawie zachowania wąskiej grupy użytkowników już korzystających z aplikacji, a nawet jednego klienta. Rezultatem dwóch powyższych błędów jest albo produkt, którego nikt nie chce używać, albo produkt, który jest trudny w użytkowaniu i przyprawia użytkowników o gorączkę.
Aby zaoszczędzić czas i stworzyć w miarę akceptowalny interfejs, zespoły developerskie bardzo często decydują się na wykorzystanie gotowych bibliotek i frameworków typu Bootstrap, Semantic UI, And Design czy Material-UI. Nie ma w tym nic złego tak długo, jak próbujemy stworzyć standardowe rozwiązania, na przykład stronę checkoutu.
Problem pojawia się zazwyczaj, gdy wykorzystujemy te komponenty do realizacji funkcjonalności nietypowych, wymagających unikalnego podejścia. Frameworki tego typu nakładają również pewne ograniczenia i schematy myślenia – używamy predefiniowanych rozwiązań, chociaż moglibyśmy przygotować alternatywne, bardziej efektywne i przyjazne.
Jeżeli zespół developerski zaczyna projektowanie bez korzystania z takich bibliotek, to sytuacja wygląda jeszcze gorzej – często brakuje spójności w projekcie (typografia, odstępy, kolorystyka, elementy UI). Rezultatem jest interfejs, który co prawda działa, ale wygląda zbyt profesjonalnie.
Interfejsy tworzone przez developerów dość często są również na bakier z podstawowymi zasadami użyteczności (heurystyki, zasady gestalt, psychologii poznawczej). Większość tych błędów jesteśmy w stanie wyłapać za pomocą audytu UX.
Często obserwujemy również błędy popełnione w warstwie językowej – etykiety buttonów, alerty, nazewnictwo poszczególnych sekcji (microcopy). Zazwyczaj rozbija się to o używanie żargonu lub języka „wewnętrznego” – zrozumiałego dla zespołu projektowego, ale już niekoniecznie dla docelowego odbiorcy. Zwrócenie uwagi, czy nasz komunikat jest jasny dla odbiorcy lub poproszenie o pomoc specjalisty, może zredukować ogrom błędów.
Prosty przykład – w jednym z testów użyteczności, który prowadziliśmy, okazało się, że użytkownicy nie potrafili wyłączyć powiadomień, ponieważ były one ukryte w zakładce o nazwie, którą każdy developer przyjmie za oczywistą („notyfikacje”).
Przemyślany projekt to nie tylko jedyna rzecz, którą daje nam projektowanie UX. Co jeszcze możemy zyskać?
Co możemy zyskać dzięki UX-owi?
Jeżeli zadbamy o dobry UX i zatrudnimy specjalistę, który będzie odpowiedzialny za UX, zamiast zlecać tę część pracy developerom, zyskamy dużo więcej niż schludny i nowoczesny interfejs.
Co takiego możemy zyskać?
- Rozwiązujemy prawdziwą potrzebę użytkownika, dlatego zyskujemy sobie lojalność użytkowników;
- Spełniamy wartość biznesową interesariusza i oczekiwania rynkowe;
- Łatwiej jest nam sprzedać produkt nasz produkt cyfrowy – użytkownicy rozumieją, dla kogo jest nasz produkt, czego mogą się spodziewać i jaką wartość mogą uzyskać, korzystając z naszego rozwiązania jeszcze zanim wkroczy marketing;
- Ograniczamy ilość problemów, które mogą wypłynąć w trakcie testów QA
- Jasno komunikujemy przewagę rynkową na tle konkurencji;
- Skracamy proces onboardingowy i zmniejszamy ilość ticketów na supporcie.
Dlaczego powstają produkty bez udziału specjalisty UX?
Jest wiele powodów, dla których zespołu produktowe rezygnują z inwestycji w UX.
- Brak zrozumienia, na czym polega projektowanie UX – projektant UX to dla nas nikt inny niż “pixel pusher”, który męczy nas o przesunięcie każdego elementu o dwa piksele w prawo;
- Traktowanie UX jako odrębnego etapu tworzenia produktów – uważamy, że projektowanie polega na upiększaniu funkcjonalności, a projektanci mają sprawić, że produkt jest ładny i nowoczesny, dlatego możemy z tego zrezygnować, albo zrobić to na końcu;
- Brak zasobów – nie mamy w tej chwili dostępu do projektantów UX, więc wolimy zacząć sami pracę, a użyteczność zadbamy później;
- Oszczędność czasu – chcemy szybko skończyć projekt; wolimy zainwestować w generyczny design oparty o gotowe rozwiązania, zamiast zaprojektować coś swojego, licząc, że w przyszłości zainwestujemy w projektowanie;
- Mało klarowne cele biznesowe – nie wiemy, co chcemy osiągnąć, wypuszczając produkt na rynek i dla kogo robimy ten produkt, więc nie widzimy wartości w przeprowadzaniu testów.
Najlepszym sposobem na odparcie tych argumentów jest zrozumienie, na czym polega praca projektanta UX.
Co robi UX designer?
Nie ma magicznego sposobu na UX, ba, UX-a się nie wdraża. Stosowanie 10 heurystyk Nielsena nie zapewni nam automatycznie wyśmienitego UX. Jakość zaprojektowanego rozwiązania musimy potwierdzić, przeprowadzając serię testów. Tak samo wniosków z jednych badań nie możemy zastosować dla innych produktów i oczekiwać tego samego efektu.
Projektanci UX są częścią zespołu produktowego od samego początku. Pomagają product ownerowi i interesariuszom opracować cele biznesowe. Uczestniczą w analizie potrzeb, badają rozwiązania konkurencyjne, opracowują ścieżki użytkownika, tworzą i testują prototypy. To wszystko to proces, który ma własne etapy, ale nie oznacza to, że działa odrębnie od pracy reszty zespołu. Wręcz przeciwnie. Działają komplementarnie, wspierając każdego ze współpracowników. A jeśli twój zespół preferuje metodykę zwinną lub szczupła, nie bój się, UX da się łączyć z Agile i Lean.
UX-owiec dba o to, aby produkt był odpowiedzią na potrzeby użytkownika. Te potrzeby różnią się w zależności od rodzaju naszego produktu, grupy docelowej, czy branży.
W dużym uproszczeniu UX designer jest w całym procesie adwokatem użytkownika – dba o jego interesy, starając się odpowiedzieć na dwa podstawowe pytania:
- Czy użytkownik osiąga cel?
- Jakie jest jego doświadczenie w drodze do celu?
A co jeśli nie mamy UX-owca w zespole?
Nic straconego. W zależności od tego, na jakim etapie jest Twój projekt, warto zatroszczyć się o to, w jaki sposób użytkownicy będą korzystali z Twojego rozwiązania. Jeżeli jesteś już w trakcie prac lub projekt jest opublikowany, zacznij od audytu UX i/lub testów użyteczności.
Jeżeli projekt dopiero startuje, to jesteś na wygranej pozycji – możesz znaleźć specjalistę, który ci pomoże zaprojektować UX lub skorzystać z usług agencji UX, która może pochwalić się dużym doświadczeniem i wieloma umiejętnościami.
