Wróciłem z Katowic. Spędziłem tam przemiły wieczór w towarzystwie kilkudziesięciu dzielnych dusz, które wysłuchały mojego wykładu na temat radzenia sobie z przeciwnościami czyhającymi na projekantów UX. Po wykładzie kilka osób zadało mi ciekawe pytania. W pamięci utkwiło mi zwłaszcza jedno, które powtarza się również na Usability.pl:
Projektuję funkcjonalność/stronę/apkę (niepotrzebne skreślić). Jak najlepiej to zrobić? Szukałem inspiracji w Google, patrzyłem na pattern libraries i dalej nie wiem. Gdzie szukać schematów, rozwiązań idealnych?
Odpowiadam zawsze w ten sam sposób, podając sprawdzony przepis na rozgryzienie podobnego problemu. Jak znaleźć optymalne rozwiązanie i rozpocząć projektowanie interfejsu?
Kartka i ołówek
Jeżeli nie mam szans zaangażować klientów i użytkowników w proces projektowy, to muszę radzić sobie sam. Kiedy nie wiem, jak coś zaprojektować, to rozrysowuję sobie drogę użytkownika. Skąd wiem, jaka ona będzie? Często sięgam do własnych doświadczeń, tych pozazawodowych. Ty też je masz. Od parunastu lat internet jest obecny w naszym życiu; każdy z nas wykonywał zakupy internetowe, pisał recenzje, uczestniczył w dyskusjach, używał VOD… Widzieliśmy rozwiązania dobre i bardzo niedobre. Możemy zawierzyć intuicji i opracować wstępny pomysł na podstawie naszych własnych przyzwyczajeń. Biorę więc kilka kartek papieru. Na pierwszej piszę “start”, a na ostatniej “koniec”, dodając do słowa pożądany rezultat interakcji z użytkownikiem. Na przykład, “książka dostarczona przez listonosza”. A potem wypełniam kartki pomiędzy rysunkami i notatkami, myśląc o tym, jak w bezbolesny sposób można dokonać zakupu książki. W ten sposób konstruuję szkielet. Staram się to zrobić bez posiłkowania się internetem. Zerkam weń dopiero, kiedy naprawdę utknę.
Ta metoda dostępna jest dla każdego — nie trzeba nawet być projektantem UX. Poradzą sobie z tym programista, project manager i grafik.
Potem, jeżeli tylko mogę, testuję bardzo szybko to, co zaprojektowałem. Z kolegami, z przygodnymi osobami, z kimkolwiek mogę. Na papierze. Lepszy test z żoną niż brak testu! Pomimo information bias.
Tabula rasa?
Często okazuje się, iż projektujemy rzeczy, o których nie mamy pojęcia. System sprzedaży ubezpieczeń czy formularze elektroniczej aplikacji o pożyczkę na zakup mieszkania. Pamiętam, że parę lat temu pracowałem w zespole pomagającym stworzyć taki właśnie produkt dla jednego z dużych szkockich banków. Nie miałem wtedy własnych czterech kątów. Spędziłem więc weekend na przechodzeniu przez strony konkurencji i wypełniając niekończące się formularze. Naturalnie, nie występowałem z prośbą o kredyt, a tylko docierałem do ostatniego momentu przed ostatecznym “Tak! Zwiąż mnie umową na resztę mojego życia”. W parę godzin dowiedziałem się na własnej skórze, jak wyglądają dobre i złe procesy. Dobranie interfejsu do doświadczenia, które projektowaliśmy było dużo prostsze, zwłaszcza biorąc pod uwagę pomoc kolegów. Jak zawsze, rozrysowaliśmy wszystko na papierze i wypełniliśmy “dziury”.
A pattern libraries i Google?
Sięgnę po analogię ze świata fotografii, gdyż ta dziedzina jest mi bardzo bliska. Kiedy byłem początkującym fotografem, robiłem zdjęcia (paskudne!), do których dorabiałem historię. Fotografując Warszawę na spacerze i potwornie wykręcając ją w Fotoszopie “wpadałem” na pomysł opisania tego, jak widzę to (podówczas) dość dołujące mnie miasto. Robiłem tak, bo kompletnie nie miałem pojęcia, co chcę powiedzieć. Ważny był trzask migawki i obiektywy, aparaty i film (to było dawno). Zwróccie uwagę, że skupienie się na narzędziach i metodach pracy poprzedzało u mnie myślenie o kontekście. Wychodziło to… źle. Patrząc na wiele rozwiązań projektowanych w oparciu o “najlepsze istniejące rozwiązanie” rozumiane tylko poprzez “zerżnięcie” istniejącego interfejsu zaprojektowanego przez kogoś innego — bez zwrócenia wstępnej uwagi na kontekst — widzę dokładnie to samo. Zachłyśnięcie się metodami pracy przesłoniło myśl. Przypadki można mnożyć; technologia decydująca o sposobie działania usługi, a nie na odwrót to coś, z czym spotykamy się często. O wiele łatwiej jest nam teraz uczyć się i opanować zasady używania narzędzi do prototypowania, rysowania i dziergania, niż pojąć, dlaczego chcemy ich użyć.
I przyjemniej jest wpaść w szał twórczy niż spowolnić i wziąć do ręki papier i ołówek. Bo to nie jest cool, a mamy przecież licencje na Axure i Sketcha i mamy Macbooka, Adobe CC mamy też, mamy także UX Pin… Tratata.
Wniosek?
Najpierw trzeba coś zrozumieć, żeby to zaprojektować
A niczego nie zrozumiemy lepiej, niż przez pryzmat własnych doświadczeń. Godzinę poświęconą na grzebanie w bibliotekach z gotowymi guzikami i hamburgerami poświęć na przechodzenie przez procesy podobne do tych, które projektujesz (czy to w głowie, jeżeli już je znasz, czy na ekranie, jeśli to coś nowego). Wpadniesz na lepsze pomysły, gwarantuję. I koniecznie wspieraj się ekspertyzą kolegów — może warto usiąść w pokoju i kartki papieru zarysować razem? Co kilka głów to nie jedna!
Czy to znaczy, że nie powinniśmy szukać zewnętrznej inspiracji?
Oczywiście, że powinniśmy. Cały czas grzebiemy w internecie i używamy podobnych rozwiązań do tych, które projektujemy. Ale robimy to świadomie, a nie tylko połykając jak pelikan. Fotografia też nie poprawia się od “naśladowania” najlepszych, tylko w momencie, w którym zrozumiemy lepiej samego siebie.
Uwaga
To wszystko ma sens jedynie po nakreśleniu wstępnych założeń i zrozumieniu, co właściwie projektujemy. Jeżeli wiemy tylko, że to “strona internetowa” i “żeby ładna była”, to trzeba dowiedzieć się więcej. A dopiero potem rwać za kartkę i ołówek, które to nawet w 2017 są bardzo wydajnym, o ile nie najlepszym, narzędziem projektanta interfejsów. Zgodnie z tym, co napisałem powyżej. Powodzenia!
Dodaj komentarz