Projektowanie rozwiązań idealnych, czyli oczekiwania vs rzeczywistość.

Projektant/ka UX nie jest wyrocznią czy alfą i omegą. Jest natomiast bardzo często częścią zespołu lub ściśle współpracuje z nim, na co dzień stykając się z różnymi sektorami odpowiedzialnymi za tworzenie produktu. Czasem krąży między projektami jako wolny strzelec, dokonując testów, analiz czy audytów. Czasem w zespole złożonym ze specjalistów najróżniejszych dziedzin przeprowadza procesy projektowe, mając do dyspozycji wiedzę z obszarów mniej mu/jej znanych. Czasem natomiast przychodzi mu lub jej na co dzień pracować w zespole projektantów odpowiedzialnych za podobne obszary lub dopełniać proces projektowy w opracowywaniu optymalnych rozwiązań…

Tak, jak wiele jest modeli pracy projektantów, tak samo wiele mają oni do wyboru ścieżek rozwoju – na polskim rynku projektanci UX często pracują nad pozyskiwaniem danych o użytkownikach, researchem wokół zastanych rozwiązań, analizą, projektowaniem szkieletów projektu i testowaniem rozwiązań. W przypadku projektantów UX i UI dalsza praca skupia się na designie. Projektanci, na potrzeby projektowanych rozwiązań, poszukują informacji w różnych źródłach, wiedzę czerpią z książek, artykułów, ale także – a może nawet przede wszystkim – z otoczenia i doświadczenia. Tak więc im więcej projektów wyszło spod ich ręki, tym więcej wiedzy posiadają. W pewnym momencie w ich pracy widać schemat, wyrobioną metodykę opracowywania i dostarczania oczekiwanych rezultatów. Kolejnym krokiem jest ugruntowane przeświadczenie o tym, jak dany proces lub doświadczenie powinny wyglądać. W zależności od modelu pracy ugruntowują się w nich inne wykorzystywane na co dzień umiejętności i sposoby podchodzenia do problemu. 

Balans biznesu, technologii oraz danych o użytkownikach i od użytkowników 

Projektant UX z definicji zawsze powinien dążyć do jak najlepszego zrozumienia trzech perspektyw: użytkowników, biznesu i technologii. Znany jest schemat trzech jednakowych kółek, gdzie w środku, w miejscu przenikania, plasuje się UX. W rzeczywistości proporcje kółek zmieniają się w zależności od zespołu, klienta i charakteru projektu. Wyzwaniem UX jest znalezienia balansu w tym zmieniającym się, będącym w ciągłym ruchu środowisku. Kółka zamieniają się zatem w ruchome, eliptyczne kształty o zmiennych wymiarach. Co najważniejsze: produkt nie powstanie, jeśli te trzy obszary nie będą ze sobą połączone. Więcej na ten temat pisze Marc Machenheimer w swoim artykule „Embracing imperfection in UX design” na blogu UX Collective. Co to znaczy w praktyce? Projektanci muszą słyszeć głos użytkowników, skupiać się na wykrywaniu potrzeb, jakie kierują użytkownikami w trakcie korzystania z konkretnego produktu. Biznes wytycza kierunek rozwoju projektu, ma swoje cele, które zespół musi spełnić i którymi musi się kierować dla dobra organizacji, co projektanci już na początku pracy muszą zrozumieć. Technologia pozwala na wdrożenie pewnych rozwiązań, pokazuje, co jest możliwe i niemożliwe do zrobienia i dzięki temu projektanci wiedzą na ile „szaleństwa” mogą sobie pozwolić. Projektanci muszą rozumieć zależności między tymi obszarami i odnajdywać ich punkty wspólne, dając im grunt na wartościową współpracę — tak zwaną synergię. Dla przykładu: celem biznesowym może być zwiększenie współczynnika klikalności do 85% na stronie internetowej biura podróży. Użytkownicy potrzebują łatwego sposobu na znalezienie wyjazdu, bez spędzania godzin nad wyszukiwaniem i przeglądania setek ofert. Technologia stawia projektowi wyzwanie – jeżeli celem jest personalizacja doświadczeń użytkowników serwisu, potrzebna będzie możliwość wprowadzenia jego danych (preferencje, zainteresowania, budżet i tak dalej). Zatem, aby zaproponować użytkownikom skrojone na ich potrzeby oferty, należy rozwiązać kwestię zbierania i przetwarzania danych. A jeśli ten przykład jest zbyt wydumany, pomyślmy o innym: wyobraźmy sobie, że chcemy w domu napić się dobrego czerwonego wina — producent (winnica) natomiast chce je nam sprzedać. Żeby wydobyć z wina jego głębokie walory smakowe, potrzebne jest wytworzenie dedykowanych do tego butelek, w których poczeka kilka lat na zadowolonego konsumenta — użytkownika. 

Jakość to nie ilość, a ilość nie przekłada się na jakość 

I o dziwo, nie będzie tu o testach! Idąc tropem wspomnianego winnego przykładu, wyobraźmy sobie sytuację, w której dostajemy kieliszek czerwonego wina. Kieliszek taki powinien być pękaty i wypełniony tak, aby wino miało dużo kontaktu z powietrzem i można było nim swobodnie zakręcić. Jeżeli barman nalewa wina po same brzegi kieliszka, nie dość, że wino w pełni nie uwolni swojego aromatu, to na domiar złego możemy je wylać. W ten sposób nie nacieszymy się smakiem, za to będziemy musieli sobie poradzić z uporczywą plamą na białej bluzce. Daje nam to negatywne doświadczenie. Barman w tym przypadku myli ilość z jakością. W procesie tworzenia produktu bierze udział wiele stron i wiele aspektów. Jeśli jakiś aspekt przeskalujemy, może on mieć wpływ na resztę. Perfekcją nazywamy utrzymywanie balansu między każdym z tych aspektów, o czym przeczytać można we wspomnianym już wcześniej artykule „Embracing imperfection in UX design”. W przypadku produktów cyfrowych użytkownicy doświadczają nieraz zbyt dużej ilości (liczby) funkcjonalności i funkcji w obszarze jednego produktu. Taka maksymalizacja powoduje, że brakuje miejsca na jakość. Dlaczego tak się dzieje? Nad produktem może pracować wiele zespołów, a każdy z nich skupiać się na innych kwestiach i zapominać o utrzymywaniu spójności. To całkowicie naturalne i pojawianie się niejednorodności jest nieuniknione przy dużej liczbie osób zaangażowanych w projekt.
Ustaliliśmy, jak ważne jest utrzymanie relacji między biznesowymi celami, potrzebami użytkowników i możliwościami technologicznymi. Kolejnym ogromnie ważnym aspektem projektowania produktu jest trzymanie niejednorodności na jak najniższym poziomie — to bowiem wpływa na doświadczenie użytkowników. 

Rzeczywistość zespołu 

Przedstawione sytuacje mają charakter ogólny, w którym mówimy o powstawaniu produktu z większej perspektywy. Żeby jednak lepiej zrozumieć złożoność powstawania produktu skrojonego na potrzeby i możliwości wszystkich stron, naświetlmy jedną z podstawowych składowych powstawania produktu, czyli zespół. Chciałoby się napisać zespół projektowy, ale w rzeczywistości nie zawsze mamy do czynienia z całym zespołem projektantów i projektantek. Zespoły składają się z najróżniejszych specjalistów, w większości odpowiedzialnych za inne obszary. Na warsztat weźmy zespół scrumowy. W zespole takim mamy zawsze Product Ownera, określającego wizje i cele projektu, definiującego również priorytety i zadania. Druga rola to Scrum Master, który czuwa nad rozwojem projektu, ale również procesem scrumowym, który – w zależności od potrzeb – dostosowuje do swojego zespołu, aby każdy jego członek mógł pracować jak najwydajniej. Następnie mamy… resztę zespołu: UX designera, deweloperów, testerów, analityka czy data scientist. Skład zespołu różni się w zależności od potrzeb, jednak pewne jego aspekty są niezmienne, jak rola Product Ownera, Scrum Mastera i zespołu deweloperskiego. Zespół dostarcza gotowe rozwiązania, pracuje nad utrzymaniem i ulepszaniem produktów. Więcej na temat ról w zespole scrumowym przeczytać możemy na stronie Agile Hunters w artykule „Role w Scrum”. Jednak cofnijmy się do trzech gałęzi, o których mowa była wcześniej: biznesu, użytkowników i technologii. Utrzymywanie między nimi dobrych stosunków jest kluczowe w pracy nad produktem, który ma osiągnąć sukces. Każdy z członków zespołów jest jednak najbardziej skupiony na swoim obszarze i czasem zachowanie balansu bywa ciężkie. Dlatego tak ważna jest wymiana spostrzeżeń, spotkania mające na celu przybliżenie wartości i celów, ale także zrozumienie korelacji pomiędzy poszczególnymi obszarami. Niesamowicie ważne jest między innymi zrozumienie, czym zajmują się inni członkowie naszego zespołu bądź zespołów, z którymi współpracujemy. Mając niepełną wiedzę, możemy wyciągnąć bardzo pochopne i niesłuszne wnioski. I tu właśnie pojawia się odpowiedni moment na to, aby powiedzieć, co się dzieje, gdy wyobrażenia ścierają się z rzeczywistością. Weźmy na warsztat obszar UX: projektanci doświadczeń skupiają się na swoich zadaniach, zapoznając się z wymogami i celami projektu. Starają się połączyć wątki, rozszyfrować zawiłości płynące ze spotkań z użytkownikami, aż w końcu przychodzi moment kontaktu z programistami, z którymi wypracowują wspólny język. W idealnym zbalansowanym modelu pracy tak właśnie jest. Zastanówmy się, czy taki model istnieje. Zawsze może wydarzyć się coś, co spowoduje, że projekt się opóźnia, materiały trzeba od nowa przeanalizować, a plan zrewidować. Czasem także członkowie projektu nie rozumieją się nawzajem, co jest domeną pracy w branży IT. Umiejętności poznawcze i umiejętności miękkie są u każdego inaczej rozwinięte – coś, co dla jednej osoby wydaje się oczywiste, dla drugiej może stanowić ogromną zagadkę, a zrozumienie tego wymaga więcej czasu. Członkowie zespołu uczą się siebie nawzajem i im dłużej tworzą jedność, tym bardziej wydajnie z każdym miesiącem pracują. 

Dream big vs quick wins 

Ciekawe, a czasem naprawdę problematyczne jest, gdy projektant skupia się na jednym aspekcie i na co dzień nie współpracuje z bardziej technicznymi segmentami projektu. Weźmy na przykład specjalistę UX od przeprowadzania testów i eksperymentów w obrębie strony internetowej. Do jego zadań należy przeprowadzanie badań z użytkownikami, testów A/B, określanie ich statystycznej ważności i analizowanie wyników – zarówno zleconych przez inne zespoły, jak i zaproponowane przez niego samego w wyniku własnej analizy. Pracuje obok zespołów, nie jest częścią żadnej technicznej „drużyny”. Jego wyniki są świetnym materiałem do pracy dla innych projektantów, będących integralną częścią któregoś z zespołów, dostarczają inspiracji i pomysłów na podejście do określonych problemów, które znaleźli w obrębie swojego projektu. Sami odpowiedzialni są za większy obszar projektowania. Przy walidacji projektu jeden z nich, pracujący w zespole scrumowym, chce poznać opinię i podzielić się wynikami pracy nad projektem z osobą, której praca skupia się na prowadzeniu testów i wyciąganiu wniosków. Zaprasza naszego badacza na spotkanie prezentujące nowe rozwiązania poprawy jakości jednego z sektorów produktu organizacji, nakierowanego na ulepszenie obszaru user experience. Czego można się spodziewać? Bez wątpienia ogromnej wartości merytorycznej zaproszonego, wynikającej z wiedzy zaczerpniętej ze studiowania wyników testów. Z drugiej strony musimy pamiętać, że pan badacz nie jest wyrocznią i nie wie wszystkiego. Jeżeli założymy, że nasz zespół również przeprowadza swoje testy, nakierowane stricte na konkretne obszary, którymi się zajmuje, wyniki badacza badań mogą nie pokrywać się w stu procentach z tym, co sami odkryliśmy. Najprostszym sposobem na weryfikację „kto ma rację” jest przeprowadzenie szybkich testów A/B. Testowanie rozwiązań, najlepiej jak najszybciej, to jedyny sposób na podjęcie właściwej decyzji. Zawsze warto pozostawić miejsce na eksperymentowanie. Nie na użytkownikach, rzecz jasna – eksperymentowanie z rozwiązaniami, które użytkownicy sami wybiorą za najlepsze dla nich. Ale wróćmy do badacza. Zaprosiliśmy go na weryfikację rozwiązań odnośnie poprawy wyszukiwarki naszej strony internetowej, której oferta jest naprawdę ogromna. Przedstawiamy mu nasze wyniki badań i opowiadamy o tym, do czego dążymy. W najbliższym czasie chcemy poprawić filtry – zarówno ich działanie, jak i nazewnictwo, które obecnie jest dla użytkowników niejasne. Dążymy również do zrównania się z systemem projektowym, bo wcześniej, niestety, nie był zbytnio brany pod uwagę — w zespole brakowało projektanta. Badacz odpowiada nam, że według niego skupiamy się na złych rzeczach, bo najważniejsza jest jak najwyższa relewantność wyników dla zapytania użytkownika. Poza tym użytkownicy nie lubią filtrów i powinni od razu dostać wynik, bez konieczności filtrowania, bo tylko marnują czas. Najbardziej potrzebują takiej wyszukiwarki, która zgadnie, co chcą napisać i od razu zaproponuje odpowiednie wyniki. Odpowiadamy, że mamy świadomość zmian, które muszą nastąpić i dążymy do nich, jednak na chwilę obecną technicznie nie jesteśmy w stanie dostarczyć rozwiązań, o jakich mówi. Musimy zmienić środowisko, gdyż obecne nie pozwala nam na poprawne wykrycie słów i ich ważności. Zwłaszcza, że oferta skierowana jest do użytkowników wielu kultur i krajów. Potrzebujemy kilku miesięcy, aby te zmiany wprowadzić, dlatego teraz skupiamy się na tym, co zrobić możemy, żeby pokazać poprawę jak najszybciej, m.in. nazewnictwo filtrów. Przeprowadziliśmy w tym celu testy card sorting i sprawdzaliśmy modele mentalne naszych użytkowników. Dodajemy także możliwość wyszukiwania przez konkretne specyfikacje produktów, co pozwoli na trafniejsze określenie parametrów poszukiwanego przedmiotu. Jak wynika z naszych wywiadów i analizy ankiet z użytkownikami, poprawi to obecne doświadczenia użytkowników, którzy skarżyli się na brak takiej możliwości. Co na to badacz? Badacz na to, że to nie wystarczy, bo powinniśmy dążyć do usunięcia tego wszystkiego, zminimalizowania funkcji i stworzenia wyszukiwarki inteligentnej… I tak dalej. Zespół przedstawia projektantowi realne przeszkody, które powodują, że na chwilę obecną nie jest w stanie dostarczyć rozwiązania przez niego proponowanego. On skupiony jest na rozwiązaniu doskonałym, popartym przez testy, jakie wykonywał, i uważa za słuszne celować wyżej i dalej. Czy to dobrze? Jasne! Kierunek i wizja rozwoju projektu jest bardzo istotna, jednak musimy pamiętać o tym, z czym możemy pracować w obecnej chwili. Musimy wypracować kompromis. Olaf Kowalik w swoim artykule zatytułowanym „Dlaczego idealny dizajn nie istnieje” przytacza słowa Henry’ego Petroskiego z jego książki „Small Things Considered: Why there is no perfect design”, pisząc, że wszystko, co zostało zaprojektowane, jest wynikiem szeregu negocjacji materiałów, metod wytwarzania, czasu i pieniędzy. Ciężko jest (a czasem nie można) zadowolić każdą ze stron w stu procentach. Kompromis to jedna z najistotniejszych metod wypracowywania wspólnego języka, pozwalająca na określenie wspólnego stanowiska. Są setki decyzji projektowych, które musimy podjąć podczas procesu projektowego. Projektując nowe i bardziej precyzyjne filtry, uczymy użytkownika, że nasza strona się rozwija i dostarcza mu coraz lepszą jakość. Gdy w końcu uda się dojść do momentu dostarczenia mu rozwiązań dużo bardziej skomplikowanych technologicznie, będzie miał większe zaufanie do produktu. Dlatego czasem zamiast skupiać się na rozwiązaniu idealnym, warto dążyć do niego krok za krokiem, zdobywając tak zwane quick wins, czyli dostarczać mniejsze części w mniejszych odstępach czasu. Dzięki temu możemy na bieżąco badać wpływ zmian na zachowania użytkowników, przekładający się na korzyści biznesowe. Jeśli rozwiązanie jest bardzo pracochłonne, zastanówmy się, co możemy zrobić, aby powoli do niego dążyć, i jak podzielić proces na mniejsze kroki. 

Jeden model nie jest odpowiedzią na każdy problem 

Czy ktoś z Was zna takie środowisko, gdzie wszystko idzie zgodnie z planem? Gdzie wszystko odbywa się bez żadnych niespodzianek, nagłych zmian kierunku czy chociaż zdania osób bezpośrednio zainteresowanych? Jeśli tak, dajcie znać! Sporo z nas będzie zachwyconych możliwością współpracy! Niestety, zwykle nie jest tak kolorowo. Zdarzają się sytuacje, które wymuszają na nas wypracowywanie kompromisu. Zdarza się, że testy pokazują, iż konieczne jest przeprojektowanie rozwiązań. Przede wszystkim jednak pamiętajmy, że jedno rozwiązanie nie będzie odpowiedzią na każdy problem czy pytanie – nawet jeśli omawiane obszary wydają nam się bardzo podobne. Istnieją uniwersalne wzory i rozwiązania – takie, jak układ elementów na stronie – jednak na głębokim poziomie tworzenia produktu będą one zdecydowanie niewystarczające. Do każdego nowego zadania nastawionego na ulepszanie należy zawsze usiąść osobno i przeanalizować wszystkie aspekty. Coś, co zdało egzamin w jednym przypadku, w tym może go nie zdać. Doświadczenie użytkownika internetowego sklepu z butami, gdy jest on niezalogowany, a więc przegląda stronę incognito, jest jednym doświadczeniem. Jednak jeśli jest użytkownikiem zarejestrowanym, spodziewać będzie się większej personalizacji, wyników odpowiadających jego konkretnym potrzebom czy historii wyszukiwania. Nawet jeśli nie powie tego wprost, to domyślnie będzie tego oczekiwał. Nie ma rozwiązań idealnych. Ważne jest wzięcie pod uwagę wszystkich aspektów, jakie mogą wpływać na potrzeby i oczekiwania użytkowników oraz spojrzeć na nie z szerszej perspektywy. Nie ma drogi na skróty – każda idea (nawet zainspirowana sprawdzonym rozwiązaniem) wymaga weryfikacji z odbiorcą. Tak samo, jak każdy projekt musi być możliwy do wdrożenia. Wspominaliśmy o zespole scrumowym, w którym Scrum Master dostosowuje ów proces do wymogów zespołu. No właśnie. Dostosowywania, testowanie, usprawnianie istnieją na każdym poziomie projektowania produktu – również w strukturach organizacji. User experience czy customer experience to nie sama butelka wina, którą kupuje konsument. To cały proces wytwarzania, współpracy, wypracowywania kompromisów i rozwiązań, aż do sprzedaży. Warto zastanowić się, jak połączyć luźne myśli, a może wykorzystane już pomysły, i stworzyć coś nowego, co może być odpowiedzią na postawiony problem. Kiedy z pozoru niepowiązane ze sobą idee zostaną zebrane, ich punkty styku mogą pobudzić nowe połączenia i kombinacje – ograniczenia mogą być zatem możliwością wyjścia poza znany teren i poszukiwania odpowiedzi dalej, jak sugeruje w przytoczonym wcześniej artykule Olaf Kowalik. Projektowanie produktów – czy to cyfrowych, czy fizycznych – jest procesem. W procesie tym bierze udział wiele składowych, a umiejętność utrzymania między nimi porządku, zgody i zrozumienia, jest kluczowa w dostarczaniu wysokiej jakości produktu, na którym skorzysta każda ze stron.