Axure: oddech wymarłych światów

Axure pojawiło się na rynku w czasie, w którym po prostu nie miało konkurencji. Zrazu powolne i dość niechętne współpracy (Windows XP times, baby!), okazało się jednak przydatne. Wkrótce stało się to moje główne narzędzie do prototypowania; odszedłem od makiet dłubanych w Ilustratorze i na serwetkach. To jednak zmieniało się na przestrzeni lat. Dzisiaj w moim otoczeniu Axure już nikt nie używa; nie używa się go także w ogromnej większości organizacji, z którymi pracuję. Przesiedliśmy się na inne narzędzia, choć licencje wciąż pozwalają nam na używanie tego programu. Dlaczego?

Na początek

To, o czym piszę poniżej odnosi się do mojego doświadczenia, czyli:

1. Tego, że jestem pierdzielem starej daty, który rozumie, jak programuje się komputery, wie, jak (mniej więcej) działają bazy danych i robaczki kodu i, że produkt, który wygląda ładnie musi przede wszystkim działać,
2. Pracy z Axure od wersji 4 (?), czyli od roku 2005 (jeśli mnie pamięć nie myli),
3. Pracy z dużymi organizacjami (w zespołach projektowych 20+ osób i więcej),
4. Pracy z dużymi produktami o bardzo skomplikowanej funkcjonalności, ale i przy małych projektach,
5. Pracy w sprintach jednej czy drugiej metody agile, z silnym podziałem ról. W zespołach, w których są badacze UX, programiści, małpki od prototypowania, project managerowie, analitycy, spece od baz danych i cała reszta zoo,
6. Pracy, która odbywa się multistrumieniowo, czyli w zespołach, w których pracuje się nad wieloma aspektami projektu naraz,
7. Pracy poza Polską – wiem, że specyfika polskiego, rodzącego się rynku jest inna i nie ma w tym niczego złego. Po prostu działa on nieco inaczej.

Dobra, to jechane.

Dlaczego zapomniałem dawno o Axure?

Wodospad, czyli teleportacja w 1997

Kiedy myślę Axure, czuję zapach metodologii waterfall. Jedno popędza drugie. Nic nie dzieje się bez dokumentacji, bez spotkań; wszystkie działania projektowe są sekwencyjne. Kiedy Edmund prototypuje, projekt leży odłogiem do czasu, aż tenże skończy. Kiedyś była to rzeczywistość; jeśli miałbym dzisiaj powiedzieć swojemu project managerowi, że potrzebuję dwóch tygodni na sklecenie prototypu a w tym czasie programiści, graficy, klient i cała reszta mogą sobie iść na ryby, to by mnie wyśmiał.

Dzisiaj szkicujemy na bieżąco (na papierze), a potem bardzo, bardzo szybko (rączkami zdolnych front-endowców) przenosimy nasze wizje w responsywny HTML. Zanim ten zdąży jeszcze ostygnąć po testach, dodajemy do niego nową funkcjonalność i testujemy, często już w połączeniu z back-endem. A zespół grafików w międzyczasie pastwi się nad, na przykład, brand guidelines i patrzy, jak jedno z drugim (owoce naszej i ich pracy) skleić do kupy. Ja biegam między biurkami i rozlewam kawę. Taka wersja lean design na resorach.

Zanim ktoś wysika się do wodospadu, woda już dawno popłynie większą ilością strumyczków.

Kod niskiej jakości

Tak; Axure pozwala na konstruowanie makiet, które działają i umożliwiają testy. Tylko, że w przypadku pracy na projekcie, który kręci się bardzo, bardzo szybko a wiele zespołów pracuje na raz, kod o jakości zbliżonej wymaganiom produkcyjnym – czysty, semantycznie poprawny i możliwy do łatwego spięcia z funkcjonalnością back-endu sprawdza się lepiej. Niestety to, co wypluwa Axure nie jest łatwe w adaptacji (choć nastąpiła w tej sprawie duża poprawa i ostatnia wersja generuje coś, co przynajmniej przypomina HTML). Zapewne uśmiechniesz się, wspominając strony internetowe pisane w Microsoft Word lub Frontpage. To było coś… To se ne vrati.

Mierna możliwości unifikacji

Axure umożliwia wprawdzie użycie bibliotek elementów interfejsu, jednak ustandaryzowane pattern libraries i biblioteki JavaScript w połączeniu z CSS (o HTML 5 nie wspominając) pozwalają na o wiele bardziej wydajną pracę. W większości firm, z którymi współpracuję działy back i front-endu mają swoje własne zbiory, często zoptymalizowane pod konkretne wytyczne brand guidelines, które dodatkowo ewoluują w czasie. O wiele łatwiej jest utrzymywać w świeżości repozytorium git niż biblioteki instalowane poprzez zrzucanie enigmatycznych plików w strukturę katalogów na indywidualnych dyskach.

Zachowywanie historii wersji

Prototypy Axure trudno jest porządnie wersjonować. Wprawdzie staje się to coraz prostsze, jednak wciąż zespół koderów front-end pracuje o wiele wydajniej, mogąc polegać na źródłach HTML. Sprawa komplikuje się w przypadku spięcia prototypów z rozwiązaniami serwerowymi; tutaj o przewadze Axure nad innymi rozwiązaniami można w ogóle zapomnieć. Duże organizacje, w których nad jedną makietą pracuje często więcej niż jedna osoba na raz mają tym spory problem.

Mała elastyczność prototypu

Dzisiaj prototypujemy już tylko mobile-up i zawsze responsywnie. W wielu organizacjach, w tym w agencji, w której pracuję nikt nawet nie wyobraża sobie konstruowania wielu makiet, które trudno skalować pod różne rozmiary ekranów. Wprawdzie Axure pozwala (od jakiegoś czasu) na definiowanie różnych widoków, jednak jest to zdecydowanie mniej wygodne od rozłożenia elementów HTML, które po prostu re-aranżują się „same” lub z pomocą CSS.

Czasy „desktopowe” odchodzą w niepamięć; czasy skomplikowanych interfejsów i „above the fold only!” też (to zresztą zawsze była bzdura na resorach). Warto się przyzwyczaić.

Krótka „data przydatności do spożycia”

Nie raz i nie dwa pracowałem nad projektami, w których prototyp służy jako materiał wyjściowy w pracach nad przyszłościowymi wersjami. Często okazywało się, że trzeba było przekazywać go dalej, poza studio, drużynie, która Axure nie posiada. Kod HTML sprawdza się tu o wiele lepiej.

Logika programistyczna rodem z piekła

Axure umożliwia konstruowanie modeli interakcji – krótko mówiąc, pozwala używać zmiennych, instrukcji warunkowych i umożliwia manipulowanie właściwościami obiektów na wskutek zaistniałych zdarzeń. Fajnie. Szkoda tylko, że narzędzie do ustawiania tych interakcji wymaga ciągłego klikania i przeciągania elementów myszą; nie mogę nawet oszacować, ile godzin zmarnowałem tropiąc problematyczne funkcje w nieskończonej palecie otwartych okien, przycisków i drzewek. Dlaczego Axure nie pozwala po prostu wklepać kodu opisującego to wszystko, tego samego, prostego kodu, który generuje się poprzez klikanie – nie mam pojęcia. W pracy nad skomplikowanymi interfejsami był to jednak dla mnie i wielu kolegów, którzy jak zapomnieli już o tym oprogramowaniu totalny overkill. Gwóźdź do trumny.

Zatem: jak nie Axure, to co?

Papier i ołówek, a potem cokolwiek pasuje. Może dla niektórych będzie to właśnie Axure – i to jest w porządku, bo jednak dobór narzędzi zależy od kontekstu, umiejętności i przyzwyczajeń, a czasem budżetu. Krótko mówiąc: zrób tak, żeby Tobie i zespołowi było dobrze.

Ponieważ przy wielu projektach przydaje się możliwość szybkiego zwizualizowania swoich pomysłów w postaci cyfrowego i dostępnego na wielu urządzeniach interfejsu, czasem spędzam parę chwil z Indigo Studio. To drogi produkt, ale moim zdaniem lepszy niż Axure; pracuje mi się z nim szybciej i generuje dużo lepszy kod. Wprawdzie wciąż nie jest to HTML o jakości produkcyjnej, ale unikatowe połączenie narzędzia do storyboardingu z interfejsem do projektowania interakcji doskonale daje radę, kiedy muszę zrobić coś naprawdę szybko. Kiedyś testowałem też JustInMind Prototyper i był to produkt straszliwie wadliwy, ale ponoć na przestrzeni lat poprawił się. Może warto go sprawdzić.

Do szybkiej wizualizacji używamy też Invision. Ostatnio silnie w nasze łaski wkrada się raczkujące, ale rozwijające się szybko Adobe XD. Poza wspomnianym Invision staramy się nie używać produktów bazujących w chmurze; wiele projektów jest zbyt ważne i zbyt skomplikowane, ażeby polegać na rozwiązaniach zależnych od jakości połączenia internetowego. Dlatego nie wiercimy w UXPinie i podobnych, choć wiele z nich jest całkiem w porządku.

Często wstępnie testujemy na plikach PDF, które przesuwa się palcem (spłodzonych choćby w Illustratorze czy tanim, a fajnym Affinity Designer). Szybko i bezboleśnie. Czasem naszkicowanie czegoś w komputerze działa szybciej i lepiej zamyka nas w ramach myślenia w kategoriach interfejsu (choć staramy się nie zafiksować).

Wciąż jednak faworyzujemy – i nie tylko my, gdyż doświadczenie to wynoszę z pracy z wieloma innymi organizacjami – ultra-szybkie szkicowanie na papierze i porządne, choć wciąż low-fidelity makiety budowane w responsywnym HTML. Z doświadczenia wynika, iż jest to najtańszy, najszybszy i najbardziej uniwersalny sposób.

Różnice w podejściu?

Myślę, że popularność Axure leży poniekąd w fakcie, iż – przynajmniej do niedawna – jednym z podstawowych zajęć projektanta UX było projektowanie interfejsów. To zmienia się powoli i przestawianie pikseli zlecane jest osobom lepiej do tego wykwalifikowanym, to jest projektantom interfejsów, czyli front-endowcom, czyli {wstaw-swoje-słowo-opisujące-kogoś-kto-dłubie-w-kodzie-slasz-grafika}. Dzieje się tak dlatego, że od programistów i tych właśnie speców od interfejsów wymaga się już dzisiaj większej rzetelności i rozumienia zasad UX. I dobrze. Dzięki temu badacze i ludzie zaangażowani w powijanie i sprawdzanie celności pomysłów mogą zająć się tym, co umieją najlepiej. W starym modelu, w którym projektant UX musiał zająć się wciskaniem „guzików” w przeglądarkę, pisaniem tekstu, badaniem i „kupowaniem” miłości zarządu, Axure pełniło poczytną funkcję.

Dzisiaj dla wielu odchodzi w mroki dziejów, ustępując miejsca bardziej elastycznym narzędziom. Czy warto się go uczyć i wiedzieć, jak go używać? Pięć lat temu powiedziałbym, że tak. Dzisiaj – że lepiej nauczyć się używać rozsądnie HTML. A jeszcze lepiej zrozumieć, że dobry projektant UX wcale nie musi umieć dobrze prototypować. Musi tylko umieć przekazać swoją wizję komuś, kto zrobi to szybciej i lepiej.

Pora na kawkę.

Inspiracji dla tytułu dostarczyła starsza niż Axure płyta zespołu Kat, którego nigdy nie byłem w stanie słuchać. Są tacy, co lubią. Niechaj im idzie na zdrowie.