Korespondencja z czytelnikami uświadomiła mi, że początkujący projektanci UX mają często problem z “zawieszkami”. Z tego artykułu dowiesz się co zrobić, kiedy zatrzymałeś się na jakimś etapie projektowania i nie wiesz, co dalej. Krótko mówiąc, co począć, kiedy inspiracja odleciała do vzduchu, czyli w powietrze (ahoj, klucy a devcata). Powiem Ci także, dlaczego warto rozrysować nawet najbardziej oczywiste rzeczy. Na papierze.
Choć to, co napiszę poniżej wielu z Was może wydawać się oczywiste, wcale nie musi takie być dla kogoś, kto zaczyna swoją przygodę z UX i zapada się pod naporem mnogości dostępnych elektronicznych narzędzi, technik i… umizgów i warknięć klienta.
Opowieść dziadka jueksiarza
Na pewno nie raz byłeś w sytuacji, w której poniesiony entuzjazmem (swoim lub klienta) zabrnąłeś daleko w projektowaniu, ale doszedłeś do momentu niepewności: co dalej? Jak rozwiązać skomplikowaną funkcjonalność koszyka zakupowego? Jak użytkownik powinien skontaktować się z organizacją, gdy coś idzie nie po myśli i czy mamy to jakoś organizować, czy po prostu skupić się na wymianie e-maili? Jak zaimplementować funkcjonalność, o której Twój klient wcześniej nie mówił, a teraz z nagła sobie “przypomniał”? Lub też: co począć, kiedy łepetyna sucha i zabrakło inspiracji? Przypadki można mnożyć. Zdarza się to często; prawdę mówiąc, trudno przypomnieć mi sobie projekt, który byłby wyjątkiem.
W takich chwilach początkującego projektanta może dopaść desperacja. Jezuszmaria, deadline jutro, a ja nic nie wiem, niczego nie umiem. Odpaliłem Axure (a fuj) i siedzę tak, a kursor puchnie. Pamiętam, że kiedy zaczynałem pracę jako konsultant UX pod okiem paru doświadczonych kolegów, mieli oni ze mnie niezły ubaw patrząc, jak kręcę się po biurze przerażony własną twórczą niemocą. Przy którymś z pierwszych poważnych projektów mój szef, Neil, usiadł ze mną przy stole i zapytał, o co chodzi. Dłubałem wtedy w makiecie systemu sprzedaży kart kredytowych dla dużego banku. Próbowałem jakoś zaadresować skomplikowane wymagania dotyczące akceptacji kilkustopniowych warunków świadczenia usługi. Nijak mi nie wychodziły te zagnieżdżone logicznie checkboxy i inne fidrygały. Wzięło się to stąd, że rozpoczynając prototypowanie wiedziałem tylko, iż na pewnym etapie będę musiał użytkownika na terms and conditions wystawić – ale nigdy nie spodziewałem się, że będzie to coś innego niż tylko jeden “ptaszek”. Bo przecież wiedziałem lepiej. Tymczasem, bankowy spec od poprawności politycznej nalegał i nie dało się go obejść. Szybko otworzył się przede mną cały krajobraz wariackich if, then, else.
Neil zapytał, o co chodzi, po czym popatrzył na mnie i powiedział:
Zafiksowałeś się, stary. Patrzysz w ten ekran myśląc, że postawienie kolejnego checkboxa jest rozwiązaniem problemu. Tymczasem wcale tak być nie musi.
Odejdź od prototypu na jeden dzień i rozrysuj sobie ścieżkę działań – zdefiniuj początek, czyli to, gdzie zaczyna użytkownik i koniec, czy miejsce, w którym odchodzi zadowolony a bank sprzedał produkt. Zaznacz na poszczególnych etapach informacje, które chcesz pobrać od użytkownika i to, czego chce dowiedzieć się o nim organizacja. Wydaje ci się, że rozumiesz, co się dzieje? Zobacz: z powodu tego, co ci się wydawało – co wziąłeś jako pewnik – teraz się pocisz.
Odszedłem więc od komputera i przez następnych parę godzin rysowałem na papierze. Nie wiedziałem jeszcze za dobrze, jak tworzyć dobre diagramy user journeys i pewnie dlatego do dzisiaj tworzę je po swojemu. Przepisów jest wiele. Koniec końców, odejście od ekranu i zwizualizowanie swojej wiedzy na temat produktu i wątpliwości na jednym ogromnym kawałku papieru bardzo mi pomogło. Robię tak do dzisiaj. Nigdy w komputerze; znajduję przestrzeń roboczą ekranu jako ograniczającą mnie. Czasem naprawdę trzeba stanąć nad czymś na podłodze, podskoczyć, obejść temat wręcz dosłownie – przesunąć nogę za nogą – i przykleić parę karteczek. Z mojej sesji z systemem sprzedaży kart kredytowych wyniosłem wiele: zrozumiałem logikę pytania o t’c’s i zauważyłem ograniczenia związane z lokalizacją klienta, problemami z nieistniejącymi kodami pocztowymi i wymogami potwierdzenia adresu w trakcie procesu.
Nauczka, jaką wyniosłem?
Może mi się wydawać, że wiem wiele o tym, co przejść ma użytkownik, ale dopóki nie spojrzę na to całościowo i w kontekście założeń organizacji – tak naprawdę nieświadom jestem swoich wątpliwości i pytań, na które muszę odpowiedzieć.
Ta wskazówka odnosi się do produktów skomplikowanych i diabelnie prostych. Zawsze kiedy masz problem, odejdź jeden krok do tyłu, albo i dwa, jeśli tego wymaga sytuacja. Nie bój się zmiąć w kulkę i wyrzucić do kosza tego, co brałeś za jedynie słuszną drogę. Projektowanie to proces iteratywny, czyli powtórzeniowy; bierzesz się za coś po to, by zrozumieć tylko tyle, ile w danym momencie możesz, a potem pogłębiasz swoje rozumienie i uzupełniasz braki. Niejednokrotnie oznacza to zaczęcie od nowa, ale z większym zasobem wiedzy.
Zauważ, że nie polecam rzucania okiem na lewo i prawo – “jak robią to inni?” – jako pierwszej metody w walce z brakiem inspiracji. Dlaczego? Według mnie często prowadzi to do następnej zawieszki, bo inni robią to tak jak im pasuje, czyli w konteście systemu innego, niż nasz. Nie ma uniwersalnych rozwiązań, nawet prostych. Poza tym, zrozumienie motywów, które sterują decyzjami projektowymi jest ważniejsze niż projektowanie na zasadzie “jakoś to będzie” (choć to jedna z moich ulubionych metod, kiedy nie wiem niczego i też nie powinieneś się jej bać).
Jeżeli masz ochotę sprawdzić, jakie są metody na wizualizację user journeys, sprawdź stronę Service Design Tools. Ja w swojej pracy używam kombinacji tych metod; nie znam chyba nikogo, kto na ślepo implementuje je według wskazań ze strony, bo wymagania zmieniają się z każdym projektem. Ważne jest jedno: spędzenie czasu z dala od komputera w momencie, w którym napotkasz na problem na pewno uczyni z Ciebie lepszego projektanta UX.
A końcowy komentarz? Zastosuj moje wskazówki zanim natrafisz na brak inspiracji. Wtedy pójdzie łatwiej od początku do końca.
Do roboty!