Sep 4, 2019 – 10 min read

W naszym dążeniu do szybkości uwarunkowaliśmy się do ignorowania naszych najbardziej wrażliwych użytkowników. Projektujemy dla szczęśliwej ścieżki, a społeczeństwo płaci za to cenę.

Aby stworzyć produkty cyfrowe, projektanci często zaczynają od opracowania zestawu scenariuszy lub przypadków użycia. Scenariusze te pomagają określić funkcje, interakcje i infrastrukturę technologiczną wymaganą w produkcie.

Jako przykład, pomyślmy o Facebooku. Kiedy Mark Zuckerberg początkowo tworzył sieć społecznościową, mógł mieć w głowie taki scenariusz:

„Studentka, która chce podzielić się zdjęciami z imprezy ze swoimi przyjaciółmi.”

To proste stwierdzenie, ale nawet coś tak prostego jak to może pomóc projektantowi w konceptualizacji rodzaju wymaganego rozwiązania. W przypadku produktu cyfrowego, mogą oni zacząć wyobrażać sobie ekrany, które mogą być potrzebne, elementy na tych ekranach, i tak dalej.

Scenariusze występują w dwóch podstawowych smakach: szczęśliwa ścieżka i przypadki brzegowe.

Szczęśliwa ścieżka to scenariusz, w którym wszystko jest idealnie dopasowane, aby funkcja/produkt działał dokładnie tak, jak zamierzał projektant:

„Łagodna studentka idzie na imprezę i robi kilka nieobraźliwych zdjęć. Wraca do domu do swojego komputera z doskonałym połączeniem internetowym, loguje się i przesyła swoje zdjęcia bez żadnych problemów, trafiają one do bazy danych i są rozpowszechniane wśród jej znajomych.”

To jest szczęśliwa ścieżka, tak jak myślimy o niej dzisiaj. Jak Goldilocks może powiedzieć, wszystko jest w porządku.

Wielu projektantów zaczyna od szczęśliwej ścieżki, ponieważ jest to ścieżka najmniejszego oporu. Konceptualizacja wymaga najmniejszego wysiłku, ponieważ usuwa wiele niewygodnych zawiłości, które mogą istnieć. To niekoniecznie oznacza, że jest łatwa do zaprojektowania; jest po prostu stosunkowo uproszczona.

Drugim typem scenariusza jest przypadek brzegowy. Przypadki brzegowe odbiegają od szczęśliwej ścieżki i, teoretycznie, zdarzają się rzadziej niż szczęśliwa ścieżka. Istnieją dwa rodzaje przypadków brzegowych.

Pierwszym z nich są techniczne przypadki brzegowe, w których coś idzie nie tak w technicznym przebiegu scenariusza. Może jest błąd w procesie przesyłania zdjęcia i nigdy nie przechodzi. Albo może użytkownik wprowadza nieprawidłowe dane w polu formularza. To jest właśnie ten rodzaj technicznej złożoności, który osoba odpowiedzialna za zapewnienie jakości może przetestować. Bardzo często proces projektowania uwzględnia tego typu przypadki brzegowe, lub przynajmniej uwzględnia główne z nich. Każdy przyzwoity projektant lub inżynier wie, że ważne jest, aby obsługiwać błędy i pomóc użytkownikowi odzyskać po nich równowagę.

Wtedy jest to, co nazywam kontekstowymi przypadkami brzegowymi: behawioralne odchylenia od szczęśliwej ścieżki. W naszym scenariuszu przesyłania zdjęć, kontekstowy przypadek brzegowy może obejmować użytkownika przesyłającego zdjęcie, które jest obraźliwe lub pornograficzne, lub przesyłającego zdjęcie kogoś innego, kto nie chce, aby to zdjęcie było dostępne w witrynie. Tego rodzaju przypadki brzegowe mogą mieć bardzo znaczące konsekwencje w świecie rzeczywistym. Niestety, są to również przypadki brzegowe, które rzadko są uwzględniane w procesie projektowania.

Dążenie do szybkości

Dzisiaj sukces w świecie technologii jest definiowany przez szybkość, skalę i wzrost – jak duża może być firma i jak szybko może się tam dostać. Motto Facebooka brzmi: „działaj szybko i psuj rzeczy”, a zespoły produktowe w całej branży mają obsesję na punkcie tego, jak szybko mogą „wysyłać funkcje”. VC piszą nawet książki o tym, jak prowadzić startupy z dużą prędkością, aby jak najszybciej zweryfikować (lub unieważnić) swój pomysł i zmarnować absolutnie minimalną ilość czasu ludzi (czytaj: VC). Nazywają to „blitzscaling.”

Pomysł szybkiego poruszania się stał się głęboko zakorzeniony w naszej kulturze projektowania, technologii i biznesu.

Jednym ze sposobów, w jaki osiągamy szybkość, jest skupienie się na szczęśliwej ścieżce. Często strategia zespołu polega na tym, aby najpierw wykonać szczęśliwą ścieżkę jako MVP (minimum viable product), aby móc szybko udostępnić ją użytkownikom, zanim włożą więcej wysiłku w obsługę przypadków brzegowych. Problem polega na tym, że zespoły rzadko wracają do zajmowania się przypadkami brzegowymi. Nieuchronnie, pojawiają się nowe priorytety i wszyscy idą dalej. To, co kiedyś było uważane za MVP, teraz jest uważane za produkt końcowy.

Z czasem, to ciągłe odkładanie przypadków brzegowych na później warunkuje projektantów i inżynierów, którzy po prostu zaczynają je ignorować. Przeciążeni pracą i niemożliwymi do dotrzymania terminami, łatwiej jest po prostu udawać, że przypadki brzegowe nie istnieją.

Wpływ szczęśliwej ścieżki

Kilka tygodni temu, startup o nazwie Superhuman wypuścił nową funkcję „read receipt” dla swojego produktu klienta poczty elektronicznej. Jeśli wyślę Ci wiadomość e-mail za pomocą Superhuman, a Ty otworzysz ją w dowolnym kliencie poczty (Gmail, Yahoo, itp.), funkcja „read receipt” wyśle mi powiadomienie, że ją otworzyłeś. Wystarczająco proste. Ale były dwa błędy w implementacji Superhuman. Po pierwsze, potwierdzenie przeczytania nie tylko informowało mnie, że otworzyłeś wiadomość, ale także podawało mi dane o lokalizacji, gdzie się znajdowałeś, gdy ją otwierałeś. Yikes. Po drugie, Ty, odbiorca, nie miałeś możliwości zrezygnowania z tej funkcji. Niezależnie od ustawień w twoim kliencie poczty, zawsze wysyłałeś mi potwierdzenie odbioru. Podwójne yikes.

Tego rodzaju funkcja ma ogromne implikacje dla ofiar stalkingu, nadużycia, i tak wiele innych negatywnych scenariuszy. Nic dziwnego, że było oburzenie i Superhuman zmodyfikował tę cechę. Ale ta funkcja nigdy nie powinna była opuścić bramy na pierwszym miejscu. Kiedy kontrowersje się pojawiły, Superhuman napisał wpis na blogu, a dyrektor generalny wystosował przeprosiny:

„Nie wyobrażaliśmy sobie możliwości niewłaściwego użycia.”

Jeśli wierzyć temu tweetowi, wydaje się, że pomysł, że mogą być odchylenia od szczęśliwej ścieżki, nie pojawił się nawet w procesie projektowania. To nie było nawet na ich radarze. Nasze dążenie do szybkości uwarunkowało nas do projektowania tak, jakby przypadki brzegowe nie istniały. Nie chodzi o to, że po prostu decydujemy się ich nie rozwiązywać, ale o to, że nawet sobie ich nie wyobrażamy. Takie praktyki są przekazywane przez firmy i szkoły projektowania. Wielu z nas jest w tym momencie tak dobrze wyszkolonych, że zwolnienie tempa nie gwarantuje nawet lepszego wyniku; ignorowanie przypadków brzegowych jest podświadomie wpisane w nasz proces.

Jako że firmy dążą do skali i wzrostu w karkołomnym tempie, uzbrajają technologię przeciwko grupom, które nie mieszczą się w ich zdefiniowanej szczęśliwej ścieżce.

Codziennie obserwujemy skumulowany wpływ tego zjawiska w sieci. Masowe platformy, takie jak YouTube, Facebook i Twitter, zostały zaprojektowane z myślą o najlepszym scenariuszu i szczęśliwej ścieżce – łagodny użytkownik dzielący się tym, co jadł na lunch lub zamieszczający filmik o swoim kocie. Skrajne przypadki nadużyć, nękania i dezinformacji były ignorowane do czasu, aż osiągnęły skalę, która uniemożliwiła ich dalsze ignorowanie, ale wtedy było już za późno. Zajmowanie się przypadkami skrajnymi nie leży w DNA tych firm. Jeśli spędziłeś 15 lat na łączeniu swojego modelu biznesowego ze szczęśliwą ścieżką, twoje procesy, struktury organizacyjne i mentalność nie są przystosowane do myślenia poza nią. Więc te platformy są albo powolne w odpowiedzi lub całkowicie niezdolne do tego.

Happy path design nie jest human-centered, to jest biznes-centered. Jest to dobre dla firm, ponieważ pozwala im działać szybko. Ale szybkość nie zapewnia żadnych korzyści użytkownikowi. Ponieważ firmy dążą do skali i wzrostu w karkołomnym tempie, systematycznie wykorzystują technologię przeciwko grupom i przypadkom użycia, które nie mieszczą się w ich zdefiniowanej szczęśliwej ścieżce.

Kto jest na szczęśliwej ścieżce?

Częścią uzasadnienia dla projektowania szczęśliwej ścieżki jest to, że przypadki brzegowe są rzadkie. W niektórych przypadkach mogą one dotyczyć tylko 1% użytkowników produktu. Mike Monteiro wskazuje na błędność tego myślenia w swojej książce Ruined by Design:

Facebook twierdzi, że ma dwa miliardy użytkowników…1% z dwóch miliardów to dwadzieścia milionów. Kiedy poruszasz się szybko i łamiesz rzeczy, 1% jest w granicach akceptowalnego punktu załamania przy wprowadzaniu nowej pracy. A jednak zawiera on dwadzieścia milionów ludzi. Oni mają nazwiska. Mają twarze. Firmy technologiczne nazywają tych ludzi przypadkami brzegowymi, ponieważ żyją oni na marginesie. Z definicji są oni marginalizowani.

Na dodatek, rzeczywisty proces projektowania szczęśliwej ścieżki często wiąże się z posiadaniem domyślnej persony użytkownika, która ładnie pasuje do twoich pozbawionych komplikacji przypadków użycia. To potęguje problem szczęśliwej ścieżki, ponieważ oznacza to, że nie tylko patrzymy na wymyślony widok samego scenariusza, ale także na sztucznie mały wycinek potencjalnych użytkowników.

Po tym wszystkim, szczęśliwa ścieżka jest wolna od ryzyka i komplikacji. Z definicji, ludzie z najmniejszym ryzykiem i komplikacjami są najmniej wrażliwymi użytkownikami produktu.

Wszyscy inni, jak zauważył Monteiro, siedzą na marginesie i nie poświęca się im prawie żadnej uwagi, dopóki szkody nie zostaną wyrządzone i nie pojawi się jakieś oburzenie.

Więcej niż nie, ludzie, którzy siedzą na marginesie naszych produktów są tymi samymi ludźmi, którzy siedzą na marginesie społeczeństwa.

Kiedy Superhuman projektował swoją funkcję odczytu odbioru, nie projektował jej dla ludzi zagrożonych stalkingiem i nadużyciami (statystycznie rzecz biorąc, najprawdopodobniej dla kobiet). Projektowali ją dla swojego domyślnego użytkownika, którym, jak zakładam, jest jakiś VC (statystycznie rzecz biorąc, najprawdopodobniej mężczyzna) wysyłający pilnego maila do założyciela (statystycznie rzecz biorąc, również najprawdopodobniej mężczyzna).

Przyjęłam tutaj założenie – być może uwzględniają oni w swoim procesie projektowym personę kobiet – ale tu jest prawdziwy szkopuł: ich personas są nieistotne. Pomimo tego, co mówimy o empatii w projektowaniu, domyślnym użytkownikiem zawsze jesteśmy my sami. Idea empatii projektanta jest największą sztuczką, jaką kiedykolwiek na sobie wywinęliśmy. Jeśli osoba, dla której projektujesz, nie podziela twoich doświadczeń życiowych, nie możesz w żaden znaczący sposób postawić się w jej sytuacji. Odkrywanie insightów konsumenckich to nie to samo co empatia, a projektowanie skoncentrowane na człowieku nie jest magiczną tarczą przeciwko uprzedzeniom.

Ludzie, którzy siedzą na marginesie naszych produktów, są tymi samymi ludźmi, którzy siedzą na marginesie społeczeństwa.

Szybkie przejrzenie strony internetowej Superhuman pokazuje, że ich zespół produktowy i inżynieryjny to w 83% faceci. Może ktoś naciskał na funkcję odczytu paragonów, może nie. Ale jest prawie gwarantowane, że koleś podjął ostateczną decyzję. W większości przypadków kolesie nie obawiają się nadużyć czy prześladowań. To, ogólnie rzecz biorąc, nie jest nasze doświadczenie życiowe.

„Nie wyobrażaliśmy sobie możliwości niewłaściwego użycia.”

Projektowanie z myślą o szybkości wyszkoliło nas do ignorowania przypadków brzegowych, a przytłaczająca przewaga jednorodnych zespołów złożonych z najmniej wrażliwych wśród nas (czytaj: kolesi) uwarunkowała nas do skupienia się na ich doświadczeniu życiowym w naszym procesie projektowania.

Kanarek w kopalni węgla

Górnicy zwykli zabierać ze sobą kanarki do kopalni węgla. Pomysł polegał na tym, że kanarki były bardziej podatne na szkodliwe gazy, które mogą się gromadzić w kopalni. Jeśli kanarek miał się dobrze, wszyscy wiedzieli, że wszystko jest bezpieczne. Jeśli coś się stało z kanarkiem, był to znak dla wszystkich, aby się wydostać.

To jest solidny system. Jeśli projektujesz dla dobrego samopoczucia najbardziej wrażliwych, projektujesz dla dobrego samopoczucia wszystkich. Dziś nie projektujemy w ten sposób. Dzisiaj projektujemy dla najmniej wrażliwych, a następnie udajemy, że nic złego nigdy nie dzieje się w kopalni węgla.

Szeroki zakres scenariuszy, które rozważamy, określa, jak odporne są nasze produkty na odchylenia w zamierzonym zachowaniu. Dziś budujemy masywne platformy, o ogromnym zasięgu i wpływie, ale są one masowo kruche. Jeśli mamy być ze sobą szczerzy, platformy te stanowią porażkę projektową. Ich sukces opiera się na celowym lekceważeniu ludzkiej złożoności, a społeczeństwo płaci za to cenę.

Prawdziwie szczęśliwa ścieżka nie jest ścieżką najmniejszego oporu; to ścieżka największej odporności.

Musimy na nowo zdefiniować, czym jest szczęśliwa ścieżka i na nowo nauczyć się, jak ogarnąć złożoność. W naszym przykładzie z dzieleniem się zdjęciami na Facebooku, co by było, gdyby nasz początkowy scenariusz wyglądał zamiast tego tak:

„Facet dzieli się kompromitującym zdjęciem kobiety ze swoimi przyjaciółmi, a kobieta jest w stanie usunąć je ze strony.”

To jest to, czym powinna być szczęśliwa ścieżka. Prowadzi nas do tego samego miejsca, co oryginalne oświadczenie, i nadal musimy zaprojektować i zbudować interakcje wymagane, aby pozwolić temu facetowi podzielić się swoim zdjęciem. Ale to również robi coś kluczowego: skupia najbardziej wrażliwego użytkownika nad najmniej wrażliwym. Wpieka ideę niewłaściwego użycia i negatywnych rezultatów w sedno naszego procesu myślowego i włącza ją do DNA organizacji.