Cała sprawa wydarzyła się ponad dwa lata temu. Amerykański projektant interfejsów, Dustin Curtis, zmuszony do skorzystania z mało użytecznej i źle zaprojektowanej strony American Airlines poważnie się wkurzył i obiecał sobie nigdy więcej nie być klientem tej linii lotniczej. A potem zaprojektował nową wersję serwisu, tak jak powinien on według niego wyglądać, i wystosował otwarty list do American Airlines:

Jak to się stało? Gdybym prowadził firmę o takim znaczeniu i historii jak American Airlines byłoby mi głupio - a raczej wstyd - że ma ona serwis, który robi tak złe wrażenie na klientach. Jak wasz CEO, Gerard J. Arpey, usprawiedliwi traktowanie klientów w ten sposób? Czemu wasza rada nadzorcza pozwala na to? Wasza strona internetowa jest obrazą dla waszych klientów, ogranicza wasze przychody i trwale niszczy obraz waszej marki w umyśle każdego odwiedzającego użytkownika.

Tak wyglądał wtedy serwis AA.com (mocno go teraz poprawili):

A tak zaprojektował go od nowa Curtis:

Akcja wywołała w sieci małe poruszenie i doczekała się odpowiedzi ze strony anonimowego pracownika American Airlines, zajmującego stanowisko głównego architekta user experience w zespole serwisu AA.com (więc chyba nie był aż tak bardzo anonimowy 😉 ). Patrząc na stronę trudno byłoby się domyślić, że istnieje tam jakiś zespół user experience, a jego szefem jest ktoś z 10 letnim doświadczeniem i podobno wieloma niezłymi projektami na koncie. Oto co napisał ten człowiek w odpowiedzi:

Masz rację. Masz wiele racji. Ale... (...) Problem z projektem AA.com nie wynika z braku naszych kompetencji, a ma więcej wspólnego z kulturą organizacyjną i wewnętrznymi procesami American Airlines.

Pozwól mi to wytłumaczyć. Zespół zajmujący się AA.com składa się 200 osób z wielu różnych działów, np. QA, planowania produktów, analizy biznesowej, IT, zarządzania serwisem, zarządzania projektem i user experience. Bardzo wielu ludzi wywiera bezpośredni wpływ na serwis, a jeszcze więcej osób ma swoje interesy, które oddziałują na jego funkcjonalność i to w jaki sposób w serwisie prezentowany jest content. (...) Chcę powiedzieć, że AA.com to wielkie korporacyjne przedsięwzięcie z wieloma mackami, które sięgają wielu osób. Nie jest to mała rzecz, w żadnym razie.

Och, jakbym chciał, żeby tak było! Wyobrażam sobie jak fajne rzeczy moglibyśmy robić, gdybyśmy działali jak 37signals z ich filozofią Getting Real! (...) Moglibyśmy powiedzieć "nie" żądaniom o nowe funkcje. (...) Moglibyśmy przeprojektować stronę główną AA.com nie grzęznąc w niekończących się cyklach akceptacji, poprawek i akceptacji poprawek.

Ale - i to jest rzecz, którą przede wszystkim chcę przekazać - przeprojektowanie samej strony głównej to bułka z masłem. Chcesz redesignu? Mam ich sześć w moim archiwum. Wystarczy parę godzin, żeby zrobić naprawdę nieźle wyglądającą wersję, jak to pokazałeś. Ale projektowanie nie jest najtrudniejszą częścią tej pracy, czego wiele osób nie rozumie, prawdopodobnie dlatego że wiele z nich pracuje w małych firmach. Jednak ci z nas, którzy pracują dla wielkich korporacji zdają sobie sprawę z tego, jak wielkie przeciwności musi pokonać nawet najmniejszy redesign.

Chciałoby się powiedzieć: święta prawda. Pracuję dla klientów korporacyjnych już od dobrych kilku lat. Często okazuje się, że największym wyzwaniem jakie stoi przed projektantem dużych serwisów dla dużych klientów nie jest maksymalizacja użyteczności ani poprawa skuteczności biznesowej, ale obronienie spójności i sensu jak największej części projektu przed zupełnym zniszczeniem przez korporacyjną machinę. Kto nie brał udziału w całodniowych spotkaniach projektowych, w których uczestniczy 15 osób po stronie klienta, z których połowa nie wie w ogóle o czym mowa, ale czuje że musi zaznaczyć swoją obecność zgłaszając jakieś uwagi, ten nie zrozumie. Bywa, że wiele trzeba odpuścić, żeby udało się przepchnąć rzeczy najważniejsze. Oczekiwania różnych działów korporacji są czasem zupełnie sprzeczne i nie przyświeca im żaden nadrzędny cel. Zwykle brak także myślenia o celach użytkowników i scenariuszach użycia produktu, cała para idzie za to w wymyślanie jak największej liczby funkcji. Nierzadko po tygodniach projektowania dowiadujemy się spraw, które wywracają projekt do góry nogami. Akceptacje przez kilka pionów oraz prezesa, niekończące się zgłaszanie zmian przez różne osoby i kilkanaście wersji jednego elementu to w wielu firmach standard. Brałem udział w projekcie portalu, który ciągnął się przez dwa lata i skończył się średnio mimo, że był modelowym procesem user-centered design. W niektórych projektach przygotowanie samej strony głównej, to ponad miesiąc z głowy i kilkadziesiąt wersji. Mowa o samym projekcie architektury informacji, zanim zacznie się znęcanie nad grafiką. Aby było jasne - nie mam tu na myśli ulepszania projektu przez wiele iteracji, co jest jak najbardziej OK. Chodzi o zapętlające się cykle zmian, które prowadzą donikąd, bo wynikają z nieskoordynowanych uwag zbieranych nawet od kilkudziesięciu osób, zwykle bez podstawowej wiedzy o projektowaniu.

Według moich obserwacji istnieją dwie możliwe sytuacje, w których z wielkiego korporacyjnego projektu może wyjść coś dobrego (patrząc na to z perspektywy współpracy z zewnętrzną agencji świadczącą usługi projektowe B2B).

Po pierwsze - kiedy korporacja uzna projekt za mało ważny lub innym dziwnym zbiegiem okoliczności nie będzie się wtrącać w szczegóły procesu projektowego zostawiając to w całości wykonawcy 🙂 To jednak zdarza się niezmiernie rzadko... Nie gwarantuje to oczywiście sukcesu, ale pozwala przynajmniej zachować spójność rozwiązań, co jest sprawą niebagatelną.

Druga (idealna) możliwość, to sytuacja w której po stronie klienta znajdzie się jedna osoba zarządzająca projektem i mająca ostatecznie decydujący głos w każdej sprawie, która projektu dotyczy - kompetentna, dyspozycyjna, nie unikająca odpowiedzialności i mogąca przeciwstawić się wewnętrznym naciskom. Na szczęście podczas pracy z dużymi korporacjami coraz częściej zdarza mi się spotykać z dobrymi project managerami, którzy potrafią zapewnić przepływ informacji i efektywnie pokierować przebiegiem prac szybko podejmując decyzje jeśli zachodzi sprzeczność interesów i odfiltrowując niemądre pomysły. Tylko kiedy po stronie klienta zaistnieje ktoś taki, możliwe jest że duży korporacyjny projekt zakończy się stworzeniem naprawdę udanego produktu.

Kiedy nie zachodzi żadna z tych sytuacji rzadko udaje się doprowadzić projekt do szczęśliwego zakończenia i wymaga to wielu walk. Zwykle kończy się wtedy na projektowaniu przez komitet i często najgorszym z możliwych kompromisowym rozwiązaniu - jak w przypadku opcji wylogowania z Windows Vista, która udostępniała aż 9 możliwości do wyboru.

Po artykule krytykującym ten ficzer napisanym przez Joela Spolsky'ego, jeden z byłych programistów Microsoftu, który przez rok (!) pracował nad menu wylogowania z Visty, ujawnił w jaki sposób doszło do takiego projektu. Warto poznać tę straszną historię ku przestrodze 😉

Spędziłem cały rok pracując nad funkcją, która powinna zostać zaprojektowana, zaimplementowana i przetestowana w ciągu tygodnia (...).

Mój zespół miał bardzo utalentowanego projektanta interfejsów i świetnego PMa z wiedzą na temat user experience. Mieliśmy Maca (prywatną własność jednego z członków zespołu), na którego patrzyliśmy jako na wzór prostego interfejsu. (...) Mieliśmy też eksperta UX, zespół testerów, kilka poziomów managmentu i mnie piszącego kod.

Tylko w moim teamie, następujące osoby uczestniczyły w każdym spotkaniu:

• 1 program manager
• 1 developer
• 1 lider developerów
• 2 testerów
• 1 lider testerów
• 1 UI designer
• 1 ekspert user experience

Łącznie 8 osób.

Spotkania odbywały się każdego tygodnia przez cały rok, kiedy pracowałem nad Windows.

Ponadto byliśmy zależni od zespołu shella (ludzi, którzy pisali i testowali pozostałą część menu “Start”) i od teamu kernela. (...) Każda z części tych zespołów, z którymi współpracowaliśmy liczyła mniej więcej tyle samo osób, co nasz team. (...) Co więcej, każdy zespół był oddzielony przez 6 warstw managementu, co daje 24 + (6 * 3) + 1 (jeden wspólny manager) 43 osoby mające decyzję w sprawie jednej funkcji.

Zresztą “funkcja” to zbyt mocne słowo, bardziej odpowiednie byłoby “menu”. Naprawdę. Kiedy odchodziłem, cały kod, który stworzyłem liczył najwyżej kilkaset linii.

Oto jak wyglądał nasz proces projektowy: mniej więcej co 4 tygodnie na naszym cotygodniowym spotkaniu PM mówił “shell team nie zgadza się, że to ma tak wyglądać/działać/zachowywać się” i “kernel team podjął decyzję, że zrobi/nie zrobić coś, co pozwoli/nie pozwoli nam coś zrobić”. I wtedy spędzaliśmy 90 minut debatując, jak nasza funkcja - tzn. menu - powinno wyglądać opierając się na tych “nowych” informacjach. Potem na naszym następnym cotygodniowym spotkaniu spędzaliśmy następne 90 minut dyskutując o projekcie, na następnym cotygodniowym spotkaniu robiliśmy to samo, a potem na następnym cotygodniowym spotkaniu udawało nam się ustalić jedną wersję. Wtedy na naszym kolejnym cotygodniowym spotkaniu dostawaliśmy jakąś brakującą informację z zespołów shella lub kernela i zaczynaliśmy cały proces od nowa.

(...) Pomijając wszystkie problemy z podejmowaniem decyzji, żaden team nie miał pojęcia, co robi inny team, dopóki nie minęły tygodnie.

Efekt końcowy jest tym, co znalazło się w gotowym produkcie: najniższa możliwa denominacja, najłatwiejsze i najmniej kontrowersyjne rozwiązanie.

Jeśli brak dobrego procesu pracy i odpowiedniej kultury organizacyjnej na nic mogą się okazać nawet najlepsi projektanci. To jest odpowiedź na pytanie dlaczego tak wiele dużych firm, które zatrudniają przecież wielu inteligentnych i zdolnych ludzi ma tak źle zaprojektowane produkty i usługi.

PS. Bardzo pomagają też projektowi deadline-y, które ucinają zbyt długie dyskusje, ale tylko pod warunkiem że są przestrzegane przez wszystkie strony, a nie tylko wymagane od projektanta.

PS2. Projektant powinien mieć także możliwość kontrolowania późniejszych prac developerskich - integrator informatyczny puszczony samopas nawet z najlepszego projektu potrafi zrobić coś nieużywalnego.

PS3. Polecam też ten tekst: Product Management Then and Now.