Dlaczego dostępność musi być najwyższym priorytetem w 2025 roku

Przeczytaj transkrypcję:

Próbujemy transkrybować nasze podcasty za pomocą programu komputerowego. Wybaczcie ewentualne literówki, ponieważ bot nie zawsze rozpoznaje wszystko poprawnie.

Hannah Clark: Myślę, że nadszedł czas, abyśmy przyznali, że rozmowy o dostępności często wprawiają nas w dyskomfort. W kontekście produktu zwykle nadajemy priorytet funkcjom o największym wpływie i największym odsetku użytkowników. Kiedy więc rozmawiamy o tworzeniu produktów z myślą o dostępności, temat wydaje się obciążony. Gdzie w planie rozwoju umieścić funkcje, które mają duży wpływ na stosunkowo niewielki odsetek użytkowników? Skąd mamy wiedzieć, jak dostępność powinna wyglądać w przypadku naszego produktu, skoro dla różnych osób oznacza różne rzeczy? I jak zrobić to wszystko bez opierania się na założeniach lub nieumyślnego obrażania użytkowników, którym próbujemy pomóc?

Moją dzisiejszą gościnią jest Prerna Ramachandra, główna menedżerka produktu w Yahoo. Przed dołączeniem do Yahoo Prerna była starszą menedżerką produktu w Slacku, gdzie odegrała kluczową rolę w audytowaniu i rozwijaniu dostępnych funkcji dla zróżnicowanej bazy użytkowników produktu. Za chwilę usłyszycie częściowo studium przypadku, a częściowo praktyczny przewodnik po biznesowym uzasadnieniu dostępności oraz najbardziej efektywnych i etycznych sposobach sprawiania, aby produkt był bardziej przyjazny dla każdego. Zaczynajmy.

Witamy ponownie w podcaście Klubu CPO. Dziś rozmawiamy z Prerną Ramachandrą.

Prerna, bardzo dziękuję, że znalazłaś czas w swoim napiętym harmonogramie, aby dziś do nas dołączyć.

Prerna Ramachandra: Bardzo dziękuję za zaproszenie. Miło tu być.

Hannah Clark: Czy możesz opowiedzieć nam trochę o swoim doświadczeniu i o tym, jak znalazłaś się w miejscu, w którym jesteś dzisiaj?

Prerna Ramachandra: Obecnie jestem główną menedżerką produktu w Yahoo. Pracuję tutaj od około półtora roku. Przed Yahoo pracowałam w Slacku — dołączyłam tuż przed przejęciem firmy przez Salesforce i pozostałam w niej także w trakcie tego procesu. W Slacku zajmowałam się przede wszystkim prowadzeniem zespołu ds. dostępności i systemów projektowych, a następnie przeszłam do pracy nad podstawowymi doświadczeniami użytkownika aplikacji komputerowej.

Moja praca w jednym zespole i w drugim w pewien sposób się przenikała, o czym chętnie opowiem później. Przed Slackiem pracowałam w Washington Post, gdzie prowadziłam przeprojektowanie strony głównej oraz migrację platformy odpowiedzialnej za doświadczenie strony artykułu. Mam więc doświadczenie w mediach i w dużych firmach technologicznych.

Lubię mówić, że moje zainteresowanie produktem wiąże się z przecięciem produktu, technologii i opowiadania historii — ze sposobami, w jakie ludzie wykorzystują historie do komunikowania się oraz z tym, jak technologia może być skutecznym narzędziem do tego celu.

Hannah Clark: To idealne, skoro jesteś tutaj, aby opowiedzieć swoją historię.

Obie oczywiście pasjonujemy się opowiadaniem historii, a dziś skupimy się na czymś może bardziej niszowym, ale zdecydowanie na kwestii, o której moim zdaniem nie rozmawiamy wystarczająco często: dostępności, a konkretnie przecięciu dostępności i wdrażania użytkowników.

Na początek: bazując na swoim doświadczeniu w tej dziedzinie, dlaczego dostępność często traktuje się jak coś drugorzędnego? I jakie jest biznesowe uzasadnienie uwzględniania jej od samego początku?

Prerna Ramachandra: Zdecydowanie. Zacznę od stwierdzenia, w które naprawdę, głęboko wierzę: żyjemy w czasach, w których technologia nie jest już luksusem.

Dorastałam w latach dziewięćdziesiątych — trochę się tutaj zdradzam z wiekiem — kiedy technologia i internet nadal były nowością. Nie każdy miał do nich dostęp i nie każdy go potrzebował. Żyjemy jednak w czasach, w których każda z naszych podstawowych usług jest w jakiejś formie zdigitalizowana. Oznacza to, że każda osoba na świecie powinna móc łatwo z niej korzystać.

Osoby z niepełnosprawnościami są w naszym społeczeństwie zazwyczaj traktowane jako kwestia drugorzędna. Wiele naszych usług nie jest wystarczająco dostępnych, ale technologia ma wyjątkową możliwość stosunkowo łatwego wbudowania dostępności w swoje rozwiązania. Jest też wyjątkowo dobrze przygotowana do tego, aby ułatwiać życie wszystkim, w tym osobom z niepełnosprawnościami.

Dlatego uważam, że z moralnego i etycznego punktu widzenia jest to jeden z głównych powodów, dla których dostępność należy traktować priorytetowo. Dlaczego bywa traktowana jako coś drugorzędnego? Szczerze mówiąc, nie sądzę, aby większość organizacji w pełni rozumiała biznesowe uzasadnienie dostępności. To po pierwsze. Po drugie, ludzie często uważają, że dostępność wymaga bardzo głębokiej wiedzy technicznej.

Nie zawsze czują więc, że mają taką wiedzę, albo po prostu o tym nie myślą. Dostępność nie jest wbudowana w nasze procesy. W rezultacie ignorujemy ją do chwili, gdy ktoś zaczyna się obawiać pozwu albo utraty klienta mającego wymagania dotyczące dostępności.

Nagle zespoły próbują ustalić, co jest nie tak i jak to naprawić. Jeśli chodzi o drugą część pytania, czyli biznesowe uzasadnienie dostępności, wspomniałam już o tym w pierwszym punkcie. Aby technologia odniosła sukces, potrzebujesz większej liczby użytkowników, prawda? Większość z nas zarabia więcej, gdy więcej osób korzysta z naszego produktu.

Więcej osób będzie z niego korzystać, jeśli będą mogły uzyskać do niego dostęp. Na podstawowym poziomie dostępność jest po prostu bardzo ważna, ponieważ dzięki niej więcej osób może korzystać z twoich produktów, a gdy więcej osób z nich korzysta, zarabiasz więcej pieniędzy. Z drugiej strony nie chcesz zostać pozwana. Jeśli do tego dojdzie, możesz być zmuszona wypłacić dużą kwotę.

Z obu perspektyw istnieje więc biznesowe uzasadnienie dostępności. Chcę dodać jeszcze jedną rzecz — rozwinę ją później — która jest dla mnie osobiście bardzo ważna w dziedzinie dostępności. Zawsze ograniczamy pojęcie dostępności do zapewnienia obsługi czytników ekranu i możliwości korzystania z nawigacji za pomocą klawiatury. Sądzę jednak, że musimy wyjść poza tę definicję i naprawdę zastanowić się, jak zapewnić możliwość korzystania z produktu wszystkim osobom, w każdej sytuacji.

Często nie myślimy o dostępności jako o czymś, co może zależeć od sytuacji i warunków. Przykładem, który często podaję, są polecenia głosowe lub korzystanie z produktu za pomocą głosu. Zwykle myślimy, że jest to łatwiejsze dla osoby słabowidzącej. Mój tata jest starszy i może nie widzieć małego tekstu na ekranie, dlatego lubi używać głosu do sterowania wieloma rzeczami w telefonie.

Jeśli jednak prowadzisz samochód, również nie możesz korzystać z rąk, a z oczu nie korzystasz w taki sam sposób, więc nadal możesz używać poleceń głosowych. Kiedy myślisz o dostępności, możesz postrzegać ją jako obejmującą sytuację, a nie tylko osobę lub jej konkretny problem. To poszerza definicję i uświadamia, że pomijasz ogromny przypadek użycia i ogromną bazę użytkowników.

Prawdopodobnie nie jest to dobre dla twojego biznesu. Istnieje więc praktyczne biznesowe uzasadnienie tego, dlaczego dostępność należy traktować priorytetowo od samego początku.

Hannah Clark: To bardzo trafne. Dotyczy zarówno dostępności produktów cyfrowych, jak i produktów fizycznych oraz przestrzeni fizycznych. Bardzo podoba mi się ujęcie dostępności w odniesieniu do sytuacji, a nie konkretnego przypadku użycia. Sama doświadczyłam tego, gdy prowadziłam wózek dziecięcy i zauważyłam, jak wiele przestrzeni zaprojektowano z myślą o pojedynczym pieszym, poruszającym się w jednej linii.

Uświadamiasz sobie wtedy, że istnieje wiele różnych kontekstów, w których ktoś może potrzebować funkcji dostępności, udogodnienia albo rozwiązania zaprojektowanego z myślą o dostępności, ponieważ ma ona zastosowanie w przypadku wielu grup wiekowych i etapów życia. Bardzo podoba mi się ten sposób myślenia i chciałabym za chwilę przyjrzeć mu się dokładniej.

Wspomniałaś, że chciałabyś opowiedzieć więcej o swoim doświadczeniu w Slacku. Chciałabym zagłębić się w niektóre projekty, nad którymi wtedy pracowałaś, szczególnie w przepływy wdrażania użytkowników przez pryzmat dostępności.

Opowiedz mi, jak podeszłaś do analizy stanu obecnego, aby ocenić bieżący poziom dostępności produktu, i jak później działałaś?

Prerna Ramachandra: Kiedy zaczęłam pracę w Slacku, jednym z pierwszych projektów było ustalenie, jak dostępny jest produkt i co możemy zrobić, aby osiągnąć dokładnie to, o czym powiedziałaś.

Jakie ramy mieliśmy do przeprowadzenia analizy stanu produktu? Kiedy dołączyłam do Slacka, nie mieliśmy niczego takiego. Firma skupiała się wtedy na dużych klientach korporacyjnych, po tym jak dobrze poradziła sobie na rynku małych i średnich przedsiębiorstw. W miarę pozyskiwania dużych klientów korporacyjnych uświadamiała sobie, że wobec dostawców obowiązuje bardzo ścisły zestaw regulacji dotyczących dostępności.

Pierwszą rzeczą, którą zrobiłam, było opracowanie wewnętrznego zestawu standardów, który nazwaliśmy standardami dostępności Slacka. Wykorzystywał on istniejące standardy, takie jak WCAG, ale uwzględniał również specyfikę produktów Slacka i znaczenie dostępności w ich przypadku. Stworzyliśmy ramy pozwalające przejść przez produkt i przeanalizować, czy spełnia określone kryteria.

Na podstawie tej analizy przypisywaliśmy poszczególnym funkcjom produktu ocenę — A, B albo C — aby określić ich poziom dostępności. Była to analiza ilościowa i jakościowa. Mieliśmy listę kryteriów. Część z nich opierała się na bardzo prostych zadaniach, takich jak sprawdzenie, czy wszystko jest dostępne z poziomu klawiatury i czy wszystko współpracuje z czytnikiem ekranu.

Inne kwestie były bardziej niematerialne. Slack jest produktem komunikacyjnym, a jedną z rzeczy, które robi bardzo dobrze, są powiadomienia. Powiadomienia są potrzebne, ale działo się to w czasie pandemii, gdy wiele osób pracowało z domu i zdalnie. Klienci mówili nam, że liczba powiadomień była przytłaczająca, szczególnie dla osób neuroróżnorodnych. Czuły się one przeciążone i nie mogły prawidłowo wykonywać swoich zadań.

To było nieco bardziej niematerialne. Nie jest to coś, co często można znaleźć w wytycznych dotyczących dostępności. Uwzględniliśmy więc wszystkie te elementy w ramach, które następnie służyły do oceniania poszczególnych obszarów funkcjonalnych. Oceny opierały się wyłącznie na tym, czy użytkownik może wykonać zadanie i jak szybko może to zrobić.

Pomogło to określić pilność problemów oraz wskazać, które z nich są najważniejsze, a które mniej istotne. Tak wyglądał pierwszy etap. Wykorzystaliśmy te ramy do analizy stanu produktu, a następnie poszliśmy do kierownictwa i powiedzieliśmy: „Oto cały produkt. Tak wygląda jego zakres ocen. Oto problemy, które naszym zdaniem należy naprawić natychmiast, ponieważ dla pewnej grupy klientów produkt jest zasadniczo nieużywalny”.

Najlepsze w tych ramach było to, że można je było stosować nie tylko do istniejących produktów. Jeśli tworzyłeś nowy produkt, również mogłeś z nich skorzystać, aby ustalić, co należy sprawdzić przed premierą. Można je było wykorzystywać także przy planowaniu przyszłości i tworzeniu kolejnych produktów.

Następnie wykonaliśmy dużo pracy z poszczególnymi zespołami, aby pomóc im ustalić priorytety na podstawie tych ram. Każdy ma plan rozwoju. Nikt nie chce burzyć całego planu, aby spełnić nowe wymaganie. Każdy ma zestaw zobowiązań. Pracowałam więc z poszczególnymi zespołami, aby dokładnie wiedziały, które elementy są dla nich krytyczne. Dzięki temu, gdy wspólnie szliśmy do kierownictwa i mówiliśmy: „To należy potraktować priorytetowo i to trzeba naprawić”, mogliśmy przedstawić bardzo konkretny plan oraz wyjaśnić kompromisy.

Jaki byłby nakład pracy potrzebny do naprawienia każdego elementu? Co musiałoby zostać przesunięte w planie rozwoju, aby to uwzględnić? Jaki byłby wpływ tych zmian? Zawsze uważałam, że w przypadku dostępności — podobnie zresztą jak w wielu innych kwestiach produktowych — trzeba znaleźć równowagę między współpracą z zespołem odpowiedzialnym za dany obszar funkcjonalny a działaniem z kierownictwem, aby uzyskać zgodę na nadanie tej pracy odpowiedniego priorytetu.

Miałam szczęście, ponieważ kierownictwo Slacka było bardzo zaangażowane w traktowanie tej pracy priorytetowo i wykonanie jej właściwie. Potrzebowało od nas przede wszystkim jasnych informacji: jaki jest nakład pracy, harmonogram, kompromisy i wpływ. To mogliśmy przedstawić.

Było to więc dużo pracy związanej z zarządzaniem ludźmi, a także dużo pracy technicznej z inżynierami, aby dostarczyć im potrzebną analizę.

Hannah Clark: To niezwykle ważne. Uzyskanie poparcia jest kluczowe, aby te funkcje rzeczywiście zostały dostarczone — tak jak powiedziałaś, i aby zostały dostarczone właściwie.

Chciałabym nieco bardziej szczegółowo porozmawiać o wspomnianym kompromisie. Jak wyglądałby taki kompromis? Gdybyś miała podać anegdotę lub przykład jego przedstawienia, jak sformułowałabyś to w taki sposób, aby osadzić wszystko w kontekście, wyjaśnić zakres projektu i wskazać jego miejsce na liście elementów krytycznych?

Prerna Ramachandra: Powiedziałabym, że najbardziej dotknięty naszą pracą był zespół zajmujący się podstawową częścią komunikacyjną produktu. Miał największy obszar odpowiedzialności — od doświadczenia osoby wpisującej i wysyłającej wiadomość po odbieranie wiadomości w całym module komunikacyjnym.

W zespole były też osoby odpowiedzialne za kanały. Jeśli korzystasz ze Slacka, wiesz, że to rdzeń doświadczenia użytkownika. Nic dziwnego, że zespół miał największą liczbę elementów do rozwiązania. Nie tylko odpowiadał za największy obszar, ale był to również obszar o największym znaczeniu. Slack istnieje dlatego, że ludzie wysyłają i odbierają wiadomości.

Był więc najbardziej krytyczny i zawierał najwięcej problemów związanych z dostępnością o dużym wpływie. Podam bardzo konkretny przykład. Kiedy przedstawiliśmy zespołowi listę problemów — nie będę podawać prawdziwych liczb, tylko hipotetyczne — wyobraźmy sobie, że było ich 100. Powiedziałam: „To wszystko trzeba rozwiązać, aby zapewnić minimalną użyteczność produktu każdej osobie korzystającej z czytnika ekranu, nawigacji klawiaturą lub identyfikującej się jako osoba z niepełnosprawnością”.

Najpierw usiadłam z menedżerem produktu i powiedziałam: „Oto lista problemów zidentyfikowanych na podstawie naszych ram”. To był bardzo ważny etap, ponieważ menedżer produktu mógł wspólnie ze mną powiedzieć: „Rozumiem, dlaczego uznałaś te 100 elementów za krytyczne, ale uważam, że krytyczne jest tylko 80 procent z nich”.

Mieliśmy dane i informacje o tym, jak użytkownicy korzystają z produktu. Jeśli uważałam, że dany przepływ jest bardzo istotny, menedżer produktu mógł wyjaśnić, że użytkownicy wykonują go inaczej, a problem można obejść. Ta pierwsza analiza była niezwykle ważna, ponieważ pozwoliła zmniejszyć liczbę problemów ze 100 do 80.

Uważam, że każda centralna organizacja ds. dostępności powinna odbywać taką rozmowę z menedżerem produktu odpowiedzialnym za sam produkt, ponieważ to on najlepiej zna swoich użytkowników. Dzięki temu znacznie skróciliśmy listę. Następnie przeanalizowaliśmy, które problemy dotyczą obszarów produktu lub funkcji, które wkrótce zostaną przeprojektowane albo wycofane.

Jeśli dany obszar miał zostać przeprojektowany, wystarczyło dopilnować, aby nowa wersja była dostępna — nie trzeba było naprawiać obecnego problemu od razu. Jeśli funkcja miała zostać wycofana, również nie musieliśmy naprawiać jej natychmiast. W ten sposób usunęliśmy kolejne 10 problemów.

Zostało około 70 problemów do rozwiązania z zespołem. Usiedliśmy z inżynierami. W tym miejscu bardzo ważne jest posiadanie przynajmniej jednego wewnętrznego eksperta ds. dostępności. Mieliśmy szczęście, bo dysponowaliśmy świetnym inżynierem z taką wiedzą. Współpracował z zespołem inżynieryjnym, pomagając mu zrozumieć każdy problem i oszacować nakład pracy.

Następnie usiedliśmy z menedżerem produktu i zapytaliśmy: „Ile z tych 70 problemów możesz uwzględnić w bieżącym lub nadchodzącym sprincie w tym kwartale, nie martwiąc się o opóźnienia? Ile możesz po prostu włączyć do planu?”. Większość zespołów ma pewien bufor, zwłaszcza jeśli pracuje nad już wydanym produktem i musi obsługiwać napływające błędy oraz zgłoszenia.

Część pracy trafiła więc do tego procesu. Zespół stwierdził, że prawdopodobnie może rozwiązać 20 problemów bez poważnego wpływu na plan rozwoju. Nie musieliśmy nawet omawiać ich z kierownictwem. Została nam mniej więcej połowa. Następnie zapytaliśmy: „Które duże obszary produktu zaplanowane na ten kwartał mogłyby zostać przesunięte lub opóźnione, gdybyśmy potraktowali wszystkie te problemy priorytetowo?”.

W tym momencie potrzebowaliśmy zaangażowania kierownictwa, aby pomogło nam ustalić i wynegocjować priorytety. Zespół miał wydać w tym kwartale funkcję, która była bardzo ważna dla dużego klienta. Ten sam klient prosił nas jednak o naprawienie problemów z dostępnością w określonym terminie.

Mogliśmy więc powiedzieć kierownictwu: „Oto kompromis, przed którym stoimy”. Z pomocą kierownictwa współpracowaliśmy z opiekunami klienta, skontaktowaliśmy się z nim i zapytaliśmy: „Oto nasza sytuacja. Co chcielibyście zobaczyć?”.

Najważniejsze jest to, aby na swoim poziomie — jako indywidualny współpracownik, starszy menedżer produktu, główny menedżer produktu czy menedżer grupy produktów — wykonać jak najwięcej pracy. Należy kreatywnie ustalić wszystkie możliwe priorytety w ramach zespołu, a kierownictwo angażować dopiero wtedy, gdy pojawiają się duże obszary wymagające decyzji.

W tym przypadku pomocne było to, że ten sam klient odczuwał skutki obu grup problemów. Mogliśmy więc uzgodnić z nim, co powinno zostać zrealizowane najpierw, a co może poczekać. Na tej podstawie ustaliliśmy, że 10 problemów naprawimy w tym kwartale, ponieważ nie opóźni to znacznie drugiej funkcji, a kolejne 10 w następnym kwartale.

Był to pierwszy kwartał, w którym przeprowadziliśmy cały ten proces. W kolejnych kwartałach, już podczas planowania kwartalnego, zaczęliśmy wspólnie z zespołami wydzielać czas przeznaczony wyłącznie na dostępność.

Bardzo ważne jest zaangażowanie całej organizacji. Organizowaliśmy tygodnie sprintów dostępności. Zwykle zbiegały się one ze Światowym Dniem Świadomości Dostępności, jeśli pasowało to do danego kwartału. Wszyscy członkowie zespołu i wszystkie zespoły inżynieryjne pracowali wtedy wspólnie nad problemami związanymi z dostępnością. Tworzyło to również przyjemną, społecznościową atmosferę.

Organizowaliśmy także warsztaty, podczas których opowiadaliśmy zespołom o dostępności. Wszystko działało bardzo dobrze, ale mogę powiedzieć, że na początku wymagało to dużo ciężkiej pracy. Zwłaszcza w przypadku dużych kompromisów między funkcjami trzeba włączyć kierownictwo, aby pomogło ustalić, co i kiedy należy potraktować priorytetowo.

Hannah Clark: To naprawdę ciekawe. Bardzo podoba mi się to, że cała organizacja wspólnie ustala priorytety i przeznacza czas na dostępność. Okazało się również, że było to pozytywne doświadczenie związane ze współpracą. Brzmi świetnie.

Skoro rozmawiamy o współpracy i pracy zespołowej pomiędzy różnymi zespołami, zastanawiam się, jak wygląda to w organizacji mającej kilka produktów w portfolio, gdzie wiele zespołów próbuje rozwiązywać problemy z dostępnością w różnych produktach i funkcjach.

Jak współpracować między zespołami produktowymi, aby działać zgodnie i minimalizować nakład pracy oraz ilość komunikacji potrzebnej do dostarczenia tych produktów?

Prerna Ramachandra: To świetne pytanie. Widzę dwa różne sposoby, a właściwie dwa filary podejścia do tego problemu.

Pierwszy filar ma charakter strukturalny. Jeśli organizacja ma centralną organizację ds. dostępności — a większość organizacji ma dziś taką strukturę w jakiejś formie — ważne jest, gdzie znajduje się ona w organizacji. Jeśli działa w ramach pojedynczego pionu, bardzo trudno będzie przełamać silosy organizacyjne i współpracować z innymi zespołami.

Trzeba więc zadbać o właściwe umiejscowienie zespołu. Jeśli nie jest ono właściwe, menedżer produktu musi samodzielnie kontaktować się z innymi zespołami, poznawać ich plany rozwoju i nawiązywać relacje, aby móc dobrze współpracować.

Druga kwestia — również dwuczęściowa — dotyczy zarówno osoby zarządzającej centralną organizacją ds. dostępności, jak i menedżerów produktu poszczególnych zespołów funkcjonalnych. Chodzi o stałą komunikację dotyczącą planów rozwoju.

Jeśli wiesz, co nadchodzi, możesz odpowiednio reagować. To było chyba jedno z największych wyzwań, a zarazem największy obszar możliwości dla naszego zespołu, gdy pracowałam nad dostępnością w Slacku. Później, gdy zaczęłam pracować nad produktem komputerowym, przeszłam z centralnego zespołu ds. dostępności do jednego z zespołów funkcjonalnych.

Najważniejsze jest to, aby już na początku planowania prac nad produktem włączać odpowiednich ekspertów ds. dostępności. Proces zaczyna się od planowania i trwa przez cały etap projektowania. Lubię mówić, że dostępność nie zaczyna się od inżynierów, mimo że wymaga wiedzy inżynieryjnej.

Czasami zaczyna się od projektanta. Jeśli korzystasz z narzędzi takich jak Figma, mają one świetne funkcje umożliwiające projektowanie z myślą o dostępności oraz prowadzenie procesu projektowego skoncentrowanego na dostępności. Nasz projektant uczestniczył więc w procesie rozwoju i projektowania produktu od samego początku. Pytał: „Jak zapewnić dostępność tworzonych projektów? Co działa, a co nie działa?”.

Jeśli chodzi o planowanie przyszłości i istniejące problemy, bardzo pomocne były wspomniane ramy. Kiedy pracowałam w centralnej organizacji, nie mogłam śledzić każdej zmiany, każdej modyfikacji planu rozwoju ani wszystkiego, co robiły zespoły.

Ponieważ mieliśmy jednak scentralizowany zestaw standardów, o których wiedziały wszystkie zespoły, menedżer produktu mógł odwołać się do nich, przekazać je projektantowi i inżynierowi albo przeanalizować je samodzielnie. Gdy pojawiał się błąd dotyczący dostępności, mógł na tej podstawie określić, czy ma on wysoki, średni czy niski priorytet, a następnie zdecydować, czy trzeba zająć się nim natychmiast, czy można zrobić to później.

Posiadanie centralnych standardów było bardzo pomocne, ponieważ osoby bez specjalistycznej wiedzy miały punkt odniesienia przy pojawianiu się błędów i mogły pomóc w ustalaniu priorytetów. Dzięki temu nie jedna osoba musiała próbować pilnować wszystkiego i nieustannie pytać zespoły, czy zajmują się danym problemem.

Kiedy pracowałam nad dostępnością, nie chciałam być jak dyrektorka szkoły mówiąca wszystkim, co mają robić. Nikt tego nie chce. Wszyscy jesteśmy dorośli. Wierzę też, że każdej osobie zaangażowanej naprawdę zależy na tej kwestii.

Nikt, z kim rozmawiałam, nie mówił: „Nie chcę tego robić”. Wszyscy twierdzili: „Naprawdę mi na tym zależy. Chcę, aby nasz produkt był dostępny. Nie wiem tylko, jak to zrobić, albo nie wiem, czy otrzymamy zgodę na nadanie temu priorytetu i czy będziemy mieli na to czas”. Właśnie ten problem próbowaliśmy rozwiązać.

Jeśli jesteś menedżerem produktu odpowiedzialnym za funkcję i próbujesz zwiększyć jej dostępność, sprawdź, czy możesz opracować ramy albo współpracować z kimś w organizacji nad ich stworzeniem. Dzięki temu ty i inni będziecie mogli się do nich odwoływać, zamiast za każdym razem czekać na odpowiedź, czy coś jest ważne.

Będziesz wiedzieć to samodzielnie i zyskasz większą sprawczość. Jeśli tworzysz coś nowego, projektujesz nowy produkt, dopilnuj, aby móc skontaktować się z osobami posiadającymi odpowiednią wiedzę i wbudować dostępność w proces projektowy od samego początku. Pozwala to uniknąć sytuacji, w której błędy pojawiają się w przyszłości, a zespół nagle próbuje nadać im priorytet. Wiesz wtedy, że produkt będzie dostępny już w momencie premiery.

Hannah Clark: To bardzo interesujące. Chciałabym porozmawiać jeszcze o poziomie wdrażania i iteracji, ponieważ czym innym jest analiza istniejących funkcji, ustalanie priorytetów oraz wprowadzanie zmian i ulepszeń w obecnej wersji produktu, a czym innym sytuacja, gdy z czasem pojawiają się nowe funkcje, a stare stają się przestarzałe lub są zastępowane aktualizacjami.

Jak włączyć ten proces analizy albo podejście proaktywne, aby przyszłe funkcje wprowadzane do planu rozwoju były dostępne od pierwszego dnia?

Prerna Ramachandra: To również świetne pytanie. Podam bardzo konkretny przykład. Ponieważ na początku wspomniałaś konkretnie o wdrażaniu użytkowników, pierwszą rzeczą podczas tworzenia planu rozwoju powinno być przeanalizowanie każdej funkcji i wszystkiego, nad czym pracujesz, oraz pamiętanie, że trzeba uwzględnić dostępność.

Jako menedżer produktu trzeba o tym myśleć za każdym razem. Ważne jest również rozpoznanie, kiedy i kto w bazie klientów może pomóc ustalić, czy coś jest dostępne. To częściowo intuicja menedżera produktu rozwijana z czasem, a częściowo analiza rzeczywistych danych.

Menedżerowie produktu często polegają na badaniach użytkowników, aby wiedzieć, co budować. Często zapominamy jednak, że istnieją klienci i osoby korzystające z produktu w sposób wymagający określonych udogodnień — użytkownicy z niepełnosprawnościami korzystający z funkcji dostępności. Trzeba więc od samego początku włączyć ich do procesu badań użytkowników.

Przykładem, który obiecałam podać, jest wdrażanie użytkowników. Podczas naszej początkowej analizy w Slacku zauważyliśmy, że doświadczenie wdrażania miało luki w zakresie dostępności. Chcieliśmy je naprawić, ale wiedzieliśmy również, że zespół odpowiedzialny za wdrażanie pracuje nad dużym przeprojektowaniem tego doświadczenia, ponieważ produkt rozwinął się od czasu jego pierwszego utworzenia.

Chcieli uwzględnić wszystkie elementy. Mogliśmy więc współpracować z tym zespołem od samego początku, aby zapewnić dostępność podstawowego przepływu wdrażania, który był właśnie przeprojektowywany. Byliśmy zaangażowani w planowanie jego prac od początku.

Był to duży projekt. W przypadku takich dużych projektów szczególnie ważne jest zaangażowanie właściwych ekspertów. Nasz projektant uczestniczył w całym procesie projektowym. Podczas badań użytkowników, testów i tworzenia projektów w Figmie opracowywał równolegle specyfikację dostępności, aby upewnić się, że wszystko jest dostępne od początku.

Tego samego procesu użyliśmy w Slacku podczas przeprojektowywania aplikacji komputerowej. Po drugie, zauważyliśmy dużą możliwość stworzenia doświadczenia wdrażania skoncentrowanego na dostępności dla użytkowników, którzy go potrzebują.

Najlepszym przykładem jest Apple. Produkty Apple są moim zdaniem naprawdę bardzo dobre pod względem dostępności. Po zakupie nowego Maca można przejść przez przepływ wdrażania, który pokazuje, gdzie znajdują się różne funkcje dostępności, jak z nich korzystać i tak dalej.

Nasz zespół ds. dostępności zbudował podobne podstawowe doświadczenie. Gdy użytkownik wchodzi do aplikacji i rozpoczyna standardowy przepływ wdrażania, pytamy, czy zależy mu na dostępności. Jeśli odpowie twierdząco, przeprowadzamy go przez proces krok po kroku, pokazując różne narzędzia, sposób korzystania z nawigacji klawiaturą, dostępne polecenia i inne elementy.

Wykorzystaliśmy również dane. Gdy ktoś informował nas, że interesuje go dostępność, przeprowadzaliśmy go przez ten przepływ, a następnie strategicznie wyświetlaliśmy w produkcie różne podpowiedzi, które pozwalały kontynuować tę ścieżkę.

Było to możliwe z dwóch powodów. Po pierwsze, gdy opisaliśmy problemy istniejącego przepływu, zauważyliśmy ogromną lukę: nie było żadnego doświadczenia wdrażania związanego z dostępnością.

Po drugie, rozmawialiśmy z wieloma klientami. Kontaktowaliśmy się z osobami, które zgłaszały nam błędy dotyczące dostępności i pomagały ustalić, jak dostępny jest produkt. Wiele z nich mówiło: „Nie było niczego, co pomogłoby mi zrozumieć, jak poruszać się po Slacku. Musiałem dowiedzieć się wszystkiego samodzielnie”.

Niestety większość tych osób jest do tego przyzwyczajona, ponieważ wiele naszych produktów nie pomaga im w ten sposób. Moim zdaniem nie jest to jednak idealny przepływ.

Kiedy myślisz o przyszłości i o produktach, które chcesz budować, polegaj w dużej mierze na badaniach użytkowników. Nie wiem, dlaczego tak mało mówi się o tym w naszej branży, ale trzeba rozmawiać z klientami. Nic tego nie zastąpi. Nie sądzę, aby sztuczna inteligencja powiedziała ci, co należy zbudować. Powiedzą ci to osoby korzystające z produktu.

Trzeba więc z nimi rozmawiać. Obecnie istnieją firmy i narzędzia, które w tym pomagają. Jeśli jesteś dużą firmą i masz klientów korporacyjnych, gwarantuję, że mają oni jakąś grupę zasobów pracowniczych skupiającą osoby z niepełnosprawnościami. Jestem przekonana, że aktywnie uczestniczą one w weryfikowaniu dostawców.

To zasób, z którego można skorzystać. Istnieje również firma Fable, z którą współpracowaliśmy. Rekrutowała ona użytkowników z niepełnosprawnościami do testów dostępności. Działa podobnie jak usertesting.com, ale koncentruje się konkretnie na dostępności. Warto współpracować z takimi podmiotami i organizacjami, aby zrozumieć, co i jak tworzysz.

Drugą rzeczą jest włączenie odpowiednich osób w proces projektowania i iteracji. Projektant może przejść szkolenie dotyczące projektowania z myślą o dostępności albo w procesie może uczestniczyć osoba posiadająca wiedzę specjalistyczną. Projekty powinny zawierać specyfikację dostępności.

To właśnie do niej będą odwoływać się inżynierowie, decydując, jak coś zbudować. Trzeba również zadbać o udział projektantów i ekspertów ds. dostępności w testach. W ten sposób można zapewnić dostępność wszystkiego, co będzie tworzone w przyszłości, zamiast ponownie gorączkowo naprawiać problemy później.

Hannah Clark: Każdy, kto od dawna słucha naszego programu, wie, że uwielbiam konkretne i szczegółowe porady. Dziękuję za te bardzo precyzyjne rekomendacje. Na zakończenie chciałabym jeszcze porozmawiać o analityce.

Niedawno wspomniałyśmy o danych i chciałabym wrócić do pytania, jak mierzyć sukces funkcji dostępności oraz rozwiązań, których stworzenie wymagało od nas tak dużego wspólnego wysiłku. Wyobrażam sobie, że gdy mierzymy współczynnik aktywacji albo inne kluczowe wskaźniki adopcji w całej populacji, proces segmentacji skuteczności funkcji dostępności może wyglądać zupełnie inaczej — niezależnie od tego, czy chodzi o wdrażanie użytkowników, czy o inną funkcję dostępności.

To pytanie składa się z kilku części. Po pierwsze, jak segmentować pomiary, aby mieć pewność, że mierzymy skuteczność zbudowanych funkcji dostępności, a nie tylko produktu jako całości? Czy korzystałabyś w tym celu z jakichś narzędzi? Czy masz inne wskazówki, które pomogłyby włączać tego rodzaju dane do przyszłych iteracji?

Prerna Ramachandra: Odpowiem w sposób, który prawdopodobnie sprawi, że wielu menedżerów produktu poczuje się nieswojo. Sama również nie czuję się z tym komfortowo: nie można polegać wyłącznie na danych ilościowych, aby zrozumieć, czy funkcje dostępności działają i czy produkt jest dostępny.

Częściowo wynika to z faktu, że z moralnego i etycznego punktu widzenia nie można po prostu segmentować użytkowników na podstawie dostępności, ponieważ oznaczałoby to założenia dotyczące tego, czy dana osoba ma niepełnosprawność.

Nawet jeśli mierzysz, ilu użytkowników korzysta z nawigacji klawiaturą albo ilu włączyło polecenia czytnika ekranu, możesz wykluczyć dużą część populacji. Wspominałam na przykład o neuroróżnorodności. Czy osoby neuroróżnorodne mogą korzystać z produktu, czy jest on dla nich zbyt przytłaczający?

Istnieją konkretne funkcje związane z tym problemem. W Slacku i każdym produkcie zawierającym jakąś formę animacji można ją wyłączyć, ponieważ u niektórych osób może wywoływać napady padaczkowe. To kolejny element trudny do zmierzenia.

Z danych ilościowych można wyciągnąć tylko określone wnioski, ponieważ bardzo trudno segmentować użytkowników w zwykły sposób. Opierasz się na założeniach dotyczących ludzi, których zazwyczaj nie powinno się tworzyć. Poza tym prawdopodobnie nie będzie to skuteczne. Istnieją niewidoczne niepełnosprawności, a takie podejście nie uwzględnia też sytuacyjnego charakteru dostępności, o którym mówiłam na początku.

Najlepszym sposobem mierzenia dostępności i sprawdzania, czy funkcje związane z dostępnością działają, jest moim zdaniem powrót do użytkowników i po prostu zapytanie ich o zdanie. Badania jakościowe są najlepszym sposobem mierzenia sukcesu dostępności.

Podam konkretny przykład. Jedną z funkcji dostępności, które stworzyliśmy w Slacku, był interfejs programistyczny, z którego mogły korzystać różne zespoły, aby łatwo dodawać nawigację klawiaturą do swoich produktów. Nawigacja klawiaturą wymaga specjalistycznej wiedzy, której wiele zespołów nie miało.

Interfejs programistyczny miał ułatwić im pracę. Sukces mierzyliśmy więc, sprawdzając, ile zespołów z niego korzystało. Nie był on obowiązkowy — zespoły mogły stworzyć własne rozwiązania. Uznaliśmy, że jeśli zespół korzysta z naszego interfejsu, oznacza to, że jako zespół ds. dostępności odnieśliśmy sukces i zbudowaliśmy coś użytecznego.

Był to mniej pomiar użytkowników, a bardziej wewnętrzny pomiar zespołów. Sukces w przypadku użytkowników mierzyliśmy przede wszystkim poprzez rozmowy. Po uruchomieniu przepływu wdrażania mieliśmy dane ilościowe dotyczące liczby osób wybierających doświadczenie wdrażania związane z dostępnością.

Pracowaliśmy jednak również nad stworzeniem grup użytkowników, z którymi rozmawialiśmy o dostępności. Przy każdym uruchomieniu produktu prowadzisz zapewne badania jakościowe, aby zrozumieć wpływ rozwiązania. Dopilnowaliśmy, aby w tych grupach znalazły się osoby, które pytały o dostępność, korzystały z funkcji dostępności i tak dalej.

Było to przede wszystkim badanie jakościowe i rozmowy. Nie chodzi tylko o to, czy ktoś korzysta z produktu, ale czy może korzystać z niego prawidłowo, aby wykonywać zadania, które chce wykonać.

Jeśli produkt dobrze radzi sobie z większością użytkowników, dane ilościowe dają pewne ogólne wskazanie. Jeśli jednak chcesz porozmawiać z konkretnymi użytkownikami o dostępności, musisz ich znaleźć i przeprowadzić celowe badania oraz analizę jakościową, aby upewnić się, że produkt działa tak, jak powinien.

Wiem, że nie jest to idealna odpowiedź, ponieważ jako menedżer produktu szukasz liczb i danych. Uważam jednak, że częścią tej pracy jest akceptowanie pewnego poziomu niepewności. I powiem jeszcze jedno: nigdy nie osiągniesz doskonałości.

Żaden produkt nie będzie w stanie idealnie odhaczyć każdego punktu dotyczącego dostępności, ponieważ wiele kwestii ma charakter sytuacyjny. Dlatego tak ważne jest ciągłe rozmawianie z użytkownikami. Osoby, którym zależy na dostępności, będą szczególnie głośne, ponieważ nie są przyzwyczajone do otrzymywania rzeczy potrzebnych im do wykonywania pracy.

Muszą wyrażać swoje potrzeby, aby po prostu przetrwać i prawidłowo wykonywać swoje zadania. To ogromny zasób. W swojej karierze menedżerki produktu najpełniej zrozumiałam znaczenie rozmów i słuchania użytkowników właśnie podczas pracy nad dostępnością. To oni mogą dostarczyć najlepszych informacji o tym, jak działa produkt.

Nie mówi się wystarczająco dużo o znaczeniu badań jakościowych i bezpośredniego kontaktu między ludźmi. Uważam jednak, że to właśnie one pokażą, czy produkt działa. W przypadku dostępności szczególnie ważne jest rozmawianie z ludźmi.

Hannah Clark: Całkowicie się z tym zgadzam. To odcinek bardzo przychylny badaniom użytkowników. Jakiś czas temu nagrałyśmy odcinek ze Steve’em Portigale’em o przeprowadzaniu wywiadów z użytkownikami. To jeden z naszych ulubionych odcinków, ponieważ chodzi w nim o rozmawianie z ludźmi, pozwalanie im na opowiedzenie o autentycznych doświadczeniach, niekierowanie rozmową i eliminowanie własnych uprzedzeń. To niezwykle ważne w procesie tworzenia produktu.

Dziękuję ci bardzo. To była naprawdę świetna rozmowa. Bardzo doceniam twoją perspektywę na ten temat oraz tak konkretne historie dotyczące dobrze znanego produktu. Dzięki temu wszyscy możemy lepiej zrozumieć, jak te funkcje powstają.

Gdzie można śledzić twoją pracę w internecie lub się z tobą skontaktować?

Prerna Ramachandra: Jestem na LinkedInie. Wystarczy wyszukać moje imię i nazwisko: Prerna Ramachandra. Można również skontaktować się ze mną przez moją stronę internetową: PrernaRamachandra.me.

Hannah Clark: Świetnie. Bardzo dziękuję za udział.

Prerna Ramachandra: Bardzo dziękuję, Hannah. To była wspaniała rozmowa.

Hannah Clark: Dziękujemy za wysłuchanie. Więcej świetnych spostrzeżeń, poradników i recenzji narzędzi znajdziesz, zapisując się do naszego newslettera na stronie theproductmanager.com/subscribe. Więcej podobnych rozmów usłyszysz, subskrybując Klub CPO w dowolnej aplikacji, w której słuchasz podcastów.