Jakiś czas temu przeczytałem fantastyczną książkę “Sense and respond” Jeffa Gothelfa i Josha Seidena. Po raz któryś z kolei przypomniała mi ona o wyzwaniach, jakie stoją przed dużymi organizacjami i personelem próbującym wdrożyć w nich kulturę UX. Moją uwagę zwrócił opisany w książce case study Auto Tradera — jednej z większych stron brytyjskiego internetu. A niedługo potem okazało się, że na konferencji UX Scotland w Edynburgu wpadłem na Chrisa Gibbonsa i Anyę Braun, dwójkę przemiłych ludzi, którzy pracują właśnie dla Auto Tradera. Od razu pomyślałem, że warto z nimi porozmawiać. Anya i Chris poprowadzili na konferencji bardzo fajne warsztaty związane z dostępnością i tym, jak zaszczepić bakcyla tejże w organizacji. Naturalnie, po warsztatach zmęczyłem ich bułą i hamburgerem, a także wlałem w nich parę piwek. Efektem tego jest ten wywiad, który tłumaczę z dużym opóźnieniem — ale tuż przed czerwcowym wystąpieniem Chrisa na UX Scotland 2019, a więc… Mogę udawać, że na czas.
Moi drodzy, przedstawiam Anyę Braun, senior-badaczkę UX (teraz pracującą już w BookingGo, czas leci!) i Chrisa Gibbonsa, Principal UX Developera w Auto Trader.
Wojtek [W]: Wasze warsztaty o dostępności były naprawdę spoko. Jak to się stało, że tak znienacka, pewnego dnia, zainteresowaliście się właśnie dostępnością?
Chris Gibbons [CG]: Po pierwsze, dzięki za miłe słowo. Dobrze wiedzieć, że ludziom podoba się nasza historia i interesują się tym, jak staramy się uczynić Auto Tradera bardziej przyjaznym dla osób z niepełnosprawnościami i tych, którym możemy ułatwić dostęp do informacji na naszej stronie.
Dla mnie, front-end web developera, dostępność zawsze była bardzo ważna. Jestem fanem rozwiązań, które są proste i używania czystego, semantycznie poprawnego i wydajnego mark-upu. Co oznacza, że dostępność była zawsze po prostu naturalnym dodatkiem do listy wymagań, którą dla siebie tworzyłem. Poza tym, kodując z głową otrzymujesz dostępność niejako w standardzie i za darmo, bo przecież HTML został stworzony z myślą o dostępności. To tylko my, projektanci i koderzy, robimy czasem rzeczy, które ograniczają dostępność lub wręcz powodują, że jest ona zredukowana do zera.
Anya Braun [AB]: Dziękuję za komentarz na temat warsztatów, cieszę się, że ci się podobało! Ja interesuję się dostępnością od dość dawna. Zaczęło się to od tego, że zdecydowałam się napisać swoją pracę dyplomową na temat dostępności i użyteczności. W czasie gromadzenia materiałów zaczęłam przyglądać się różnym typom niepełnosprawności. Wtedy właśnie uświadomiłam sobie, że chyba mam dysleksję, co wkrótce potwierdziła oficjalna diagnoza. Co za tym idzie, moje zainteresowanie dostępnością wynika nie tylko z profesji, którą uprawiam, ale i z mojego osobistego zaangażowania w temat.
W: Jakie główne problemy związane z dostępnością czekają na użytkowników takiej strony jak Auto Trader?
AB: Jesteśmy wciąż na początku podróży, której efektem ma być usługa dostępna i wciąż mamy długą drogę do przebycia. Ale to nas stymuluje i nie pozwala nam się zatrzymać.
CG: Anya dobrze to opisała — jesteśmy na początku naszej drogi i uczymy się tak szybko, jak tylko możemy, eksplorując dostępność i inkluzywność. Użytkownicy naszej głównej platformy a także narzędzi sprzedażowych (Auto Trader umożliwia biznesom i osobom fizycznym zamieszczanie ogłoszeń o sprzedaży samochodów — Wojtek) powinni z czasem zauważyć poprawki na stronach, których używają, zarówno pod kątem dostępności jak i użyteczności. Rozpędzają się do pracy kolejne zespoły, przekazujemy sobie wiedzę. Wiemy, że obecnie strona nie jest perfekcyjna, ale jeśli ktoś ma jakieś pomysły albo problemy, to zapraszamy do ich raportowania.
W: Na jakie główne problemy napotkaliście, wprowadzając praktyki związane z dostępnością do Auto Tradera?
CG: Najtrudniej było zdecydować, gdzie zacząć i z kim porozmawiać. Kiedy udało nam się dotrzeć do właściwych ludzi, otworzyły się przed nami wszystkie potrzebne drzwi. Następnym krokiem było zwiększenie zainteresowania zagadnieniem wśród całego zespołu, wewnątrz całej organizacji.
Wciąż dużo przed nami, jak wspomnieliśmy wcześniej, ale mamy nadzieję, że po tym, jak wystartowaliśmy Gildię Dostępnego Designu, będzie nam łatwiej o uzyskanie głosu na poszczególnych etapach procesu projektowego — po to, by spróbować nowych metod czy narzędzi. Bez tej inicjatywy mogłoby być trochę ciężko.
AG: Wiedzieliśmy od początku, że jeśli chcemy uzyskać zmianę w sposobie pracy Auto Tradera, musimy pracować z wieloma zespołami. Najpierw przyjrzeliśmy się każdemu etapowi procesu, dodaliśmy solidny blok badawczy poprzedzający projektowanie i rozciągający się dalej, od implementacji po testy QA. Niezłym wyzwaniem było audytowanie procesów, które już działały — i to od dawna.
W: Wiem, że Auto Trader operuje w sposób dość proaktywny, ba; agresywny, wykorzystując DevOps. Co oznacza, że — według książki “Sense and Respond” — wypuszczacie kod bardzo często i dużo eksperymentujecie. Czy możecie o tym opowiedzieć? Jak w połączeniu z tą metodą pracy wygląda wasz cykl badawczy?
CG: Jak większość dużych organizacji działających w domenie cyfrowej, używamy metod ciągłej integracji i dostarczania (odpowiednio continuous integration i continous delivery — Wojtek). To oznacza, że mamy nawet do 300 releasów na tydzień, najczęściej nie dotykając przy tym newralgicznych systemów organizacji.
AB: Z punktu widzenia badań staramy się to zagadnienie zaatakować z wielu stron. Oczywiście prowadzimy standardowe badania z użytkownikami w naszym labie i zbieramy informacje w badaniach jakościowych. Jednocześnie prowadzimy dużo badań z użyciem zdalnej platformy User Zoom, głównie, kiedy chcemy uzyskać dostęp do większej grupy docelowej albo eksperymentujemy. Te eksperymenty często przeobrażają się w testy A/B, bo chcemy uczyć się od “żywych” użytkowników i mieć nieco większą pewność, że zmiany, które wprowadzamy odpowiedzą na potrzeby konsumentów. Pracujemy także blisko z drużyną “Voice of the Customer” (“Głos użytkownika” — Wojtek). Ci koledzy i koleżanki gromadzą bardzo dużo danych jakościowych od użytkowników indywidualnych i sprzedawców zamieszczających ogłoszenia w serwisie. Często odbywamy sesje z całą drużyną, na których identyfikujemy zachowania, grupowo przegryzamy się przez badania rynku i dane zebrane przez inne działy w firmie.
W: Wiem, że Auto Trader jest bardzo duży, ale czy możecie powiedzieć, jak bardzo?
AB: Nasza platforma notuje około 55 milionów wizyt w miesiącu. Na szczęście, możemy bardzo szybko tworzyć testy i badać ich wyniki, pomimo tego ogromnego ruchu. Nie jesteśmy blisko Amazona z ich czasem 11 sekund “learning time”, ale jesteśmy całkiem nieźli. Mamy też drugą część biznesu, nazywamy ją “Retailer”. Tam zarejestrowanych jest 13000 firm sprzedających samochody i komisów.
W: Chris, jesteś odpowiedzialny za wprowadzenie dostępności pod strzechę drużyny developerów. Jakie są główne wyzwania, przed którymi stoisz ty i twoi koledzy?
CG: Najtrudniejsze było — i, na swój sposób, wciąż jest — odbywanie i podtrzymywanie konwersacji na temat dostępności wewnątrz drużyny, tak, by odbywały się one jednocześnie z rozmowami o front-endzie. W Auto Traderze przyjęliśmy model organizacyjny Spotify, co pomogło nam stworzyć Front-End Chapter, a także wspomnianą wcześniej Gildię Dostępnego Designu, co z kolei umożliwiło nam komunikację na forum grupy i pozwoliło zbliżyć do siebie osoby zainteresowane tematem.
W: Pamiętam, że w czasie waszych warsztatów mówiłeś o frameworkach front-endowych i o tym, że nie jesteś ich fanem w sytuacji, w której developerzy nie rozumieją, co dzieje się “pod pokrywką”. Możesz rozwinąć temat?
CG: Jedną z rzeczy, której jako początkujący programista nauczyłem się wcześnie było to, że trzeba zrozumieć podstawy programowania, zanim przejdzie się dalej i zacznie używać dziwnych narzędzi. Na przykład, nie jestem ekspertem w JavaScriptcie, ale dobrze go rozumiem. Dawno temu, kiedy jQuery było właściwie jedyną sensowną biblioteką na rynku, drużyna, w której pracowałem, bardzo dobrze opanowała ES5 (wersja JavaScriptu — Wojtek). Co oznaczało, że kiedy zaczęliśmy używać jQuery do nieco większych rzeczy, wiedzieliśmy dokładnie, co dzieje się pod spodem i jak działa ta biblioteka. To było bardzo przydatne.
W niektórych sytuacjach frameworki są ok, ale czasem warto zapytać: czy naprawdę ich potrzebujemy? A jeśli już tak, to czy drużyna ma dość wiedzy, żeby zrozumieć, że praca z tymi technologiami nie będzie zbyt trudna.
Czasem jako developerzy łapiemy się na tym, że chcemy używać najnowszych rozwiązań, bo jaramy się nimi — i wtedy często okazuje się, że nie ogarnęliśmy podstaw. To jest cały problem, z którym spotykamy się w sytuacji, w której “full-stack” jest tak często przywoływany w konwersacjach, jak dzisiaj.
Miałem szczęście pracować z bardzo dobrymi programistami. Pracowałem także z potwornie kiepskimi. A różnica między nimi była taka, że ci doskonali wiedzieli dobrze, że nie mogą zrobić wszystkiego. Mógłbym na palcach jednej ręki policzyć prawdziwych developerów full-stack, których spotkałem na drodze swojej ponad piętnastoletniej kariery. A przez to rozumiem osoby, które mogą zdebugować front-end, przetestować rozwiązanie pod kątem dostępności, wyprodukować lepszy Sass lepiej niż niejeden front-end developer robiąc jednocześnie całą pracę programisty back-end. Myślę, że takie ciśnienie jest problemem dla wielu front-end/UI developerów i wpływa negatywnie na wypracowane przez ostatnich 10-15 lat standardy pracy z dostępnym kodem i rozwiązaniami.
W: Anya, jak upewniasz się, że twoje pomysły i wyniki badań znajdują drogę do interesariuszy siedzących w wieży z kości słoniowej? A może to nie jest problem, z którym musisz walczyć na co dzień?
AB: Na pewno nie ma u nas wieży z kości słoniowej, ale mimo wszystko ciągle uczymy się jako organizacja. Mamy spotkania z naszymi drużynami produktowymi i osobami podejmującymi decyzje aby upewnić się, że wszyscy pracują w tym samym rozumieniu tematu. Jeśli chodzi o dostępność i inkluzywność, to mamy szczęście, bo cała organizacja chce naprawdę pracować w otwarty i przyjazny dla wszystkich sposób. To oznacza, że wszelkie wzmianki o dostępności padają na podatny grunt. Oczywiście pomaga nam również to, że mówimy o tym, jak dostępność i jej zasady wpływają na metryki biznesowe.
W: Podejrzewam, że często pracujecie w większych grupach, czy mam rację?
CG: Oczywiście! Uważam, że praca grupowa pcha nas do przodu i jest koniecznością dla każdej organizacji. Jak wspominałem, w Auto Traderze używamy modelu Spotify, z jego drużynami, plemionami, gildiami i całym inwentarzem (polecam pogooglać! Spotify ma ciekawy model organizacyjny — Wojtek). Nasze drużyny są interdyscyplinarne, co oczywiście wspomaga grupową kreatywność.
W całej organizacji działa wiele gildii, które gromadzą w grupach osoby o naprawdę różnych specjalnościach. Na przykład, jeden z mniejszych chapters (rozdziałów? Nie mam pojęcia, jak model Spotify tłumaczy się na polski — eksperymentuję zatem! A na “chapter” nie znalazłem w głowie odpowiednika — Wojtek) to Front-End Chapter, którego zadaniem jest rozpoczynanie konwersacji na temat front-endu w całym Auto Traderze.
A jeśli mowa o praktycznych rozwiązaniach, to nasza design library, znana jako “Spark Plug”, pomaga nam osiągnąć jednolitość rozwiązań i ustandaryzować pracę. Pracujemy nad nią grupowo, wysiłkiem nie tylko developerów czy projektantów, ale także innych specjalistów w firmie.
W: A co z aspektem ewangelizacji UX? Jak to działa w Auto Traderze? Jak dzielicie się wiedzą wewnątrz organizacji?
AB: Rozmawiamy cały czas, na wiele sposobów; mamy specjalne standupy, na których dzielimy się przemyśleniami, rozmawiamy o tym, nad czym będziemy pracować, a także dyskutujemy problemy. Prezentujemy przykładowe rozwiązania i projekty na poziomie każdej drużyny — co tydzień — a dodatkowo dwa razy w miesiącu na spotkaniach, na które zapraszamy każdą osobę w firmie. Mamy też “plemienne” (to ponowna aluzja do modelu Spotify — Wojtek) śniadania, obiady i całe dnie, w czasie których poszczególne drużyny opowiadają o tym, co robią i dzielą się nowo nabytą wiedzą. A jeśli chodzi o badania, to non-stop przeszukujemy każdy z komunikacyjnych kanałów firmy! Od e-maili, przez Slacka, Yammera i nasze Trello.
W: Czego nauczyliście się w tym procesie mającym na celu wyprodukowanie w pełni dostępnej usługi?
CG: Przede wszystkim tego, żeby zawsze mieć dostępność i standardy na uwadze. Brzmi to może jak rzecz oczywista, ale bardzo łatwo jest zacząć dodawać i zmieniać funkcjonalność kiedy projekt się rozwija, zupełnie przy tym zapominając o tym, jak wpłynie to na szerszy produkt. Staram się sprawdzać kod front-endu regularnie, pomiędzy projektami i na wyrywki, chociażby z użyciem takich narzędzi jak pa11y/aXe. Testuję też strony manualnie, czasem wyłączam CSS i patrzę, co się dzieje, przebijam się przez zawartość za pomocą klawiatury, używam Wave czy SiteImprove (które bardzo dobrze działają!).
AB: Tego, żeby myśleć o dostępności od początku! W ten sposób będzie taniej — i dużo prościej, bez problemów związanych z dodawaniem odpowiedniej funkcjonalności czy późniejszej modyfikacji kodu.
W: Czy możecie podać przykład rozwiązania, które było bardzo proste do zaimplementowania a przyniosło duże korzyści użytkownikom?
CG: Link “Skip to content” (“Skacz do treści”: poczytaj o tej technice wspomagania dostępności na stronie WCAG [jęz. angielski] — Wojtek) to coś, co było naprawdę łatwo umieścić w kodzie. A zysk wynikający z tej zmiany jest oczywisty, nie tylko dla użytkowników technologii dostępu, ale dla wielu innych osób! To taka opcja, której dodanie spowodowało bardzo mało szumu. Monitorowanie wykazało, że jest to bardzo popularne, inkluzywne rozwiązanie, co w efekcie pozwoliło nam na pochwalenie się nim na forum organizacji.
W: Co chcielibyście wprowadzić pod strzechy Auto Tradera w przyszłości? Jakieś nowe, dostępne rozwiązania?
AB: Mamy wiele planów. Pokładamy nadzieję w przyzwyczajeniu organizacji do myślenia o inkluzywności na etapie całego procesu, może uda nam się też zautomatyzować pewne rzeczy nieco lepiej, np. testy…
CG: Tak, jak wspominała Anya, staramy się zautomatyzować pewne aspekty testów dostępności, ale używać też technik manualnych. Chcielibyśmy wprowadzić pa11y i aXe na stałe do palety naszych metod pracy. Te dwa narzędzia działają doskonale razem i dostarczają nam bardzo dobrych rekomendacji. Używając ich, dbamy o sprawy, które moglibyśmy przegapić.
Ale to nie wszystko, bo chcemy mówić głośno na temat dostępności, a także kontynuować edukację i trening wewnątrz organizacji. Mamy nadzieję, że wszystkie nasze produkty — te nowe i te, które już mamy — staną się bardziej dostępne na zasadzie organicznej, bez ciśnienia na siłę.
W: Wielu z czytelników i czytelniczek tego bloga walczy na co dzień z wprowadzeniem kultury UX w swoich organizacjach. Czy możecie podzielić się z nimi jakimiś przemyśleniami, tipsami?
CG: Myślę, że najlepsza wskazówka, jakiej mogę udzielić to, żeby nie bać się eksperymentować i próbować nowych rzeczy, zwłaszcza w mniejszych drużynach. Wiele lat temu, kiedy HTML5 i CSS3 nadeszły z hukiem, razem z kolegą, który też był developerem front-end po prostu zaadoptowaliśmy te standardy wg. metody JFDI (“Just Fucking Do It” — “Po prostu to, kurwa, zrób”). Mogliśmy oczywiście poczekać, aż nadejdą w pełnej odsłonie, aż dojrzeją ich specyfikacje, ale woleliśmy zobaczyć od razu, co może się przydać i, czy przez użycie tych standardów zmienimy coś w doświadczeniu użytkownika. Nie ma znaczenia, jak duża jest organizacja, w której pracujemy. Powinniśmy sprawdzać nowe metody i narzędzie cały czas. Przyjrzyjcie się metodom takim jak Google Design Sprints, Lean Coffee Retros, testom A/B, czy nawet prostym testom prototypów, jeśli ich nie robicie.
Jeśli wykorzystacie któreś z tych metod i przyniosą one wymierne rezultaty, to będziecie mogli podzielić się nimi z całą organizacją!
AB: A ja polecam robienie tzw. “dogfood sessions”, w czasie których pracownicy waszych organizacji sami używają waszych produktów. I to nie tylko szeregowi pracownicy, ale także menedżerowie. Tak, jakby byli prawdziwymi użytkownikami. To potrafi zdziałać cuda i naprawdę szeroko otwiera ludziom oczy!
W: Czy jest coś, co chcielibyście na zakończenie przekazać projektantom i projektantkom UX z Polski? Coś stymulującego?
CG: Powiem tak: stań się osobą w kształcie T; networkuj i chodź na meetupy, a jeśli nie ma takich w twoim mieście, to wystartuj jeden! I naucz się podstawowego HTML i CSS — co pozwoli ci lepiej zrozumieć pracę programistów front-end.
AB: Pracuj nad tym, by lepiej znosić krytykę, ale i pochwałę. Im szybciej zrozumiesz, że konstruktywna krytyka jest potrzebna do rozwoju i nauczysz się o nią prosić, tym szybciej staniesz się lepszą wersją samego siebie. I, żeby zakończyć fajnym sucharem: ja zawsze myślę o “Dream, Believe, Create, Succeed” (“Śnij, uwierz, stwórz, osiągnij sukces” — Wojtek). Możesz zrobić wszystko, jeśli tylko naprawdę się postarasz!
W: Dziękuję!
CG/AB: Dzięki!
Anya i Chris w sieci:
Wersja oryginalna tego wywiadu dostępna jest na LinkedIn.