Tag: ux

Reguła prostoty

„Simplicity – art of maximizing the amount of work not done – is essential”

To jedna z 12 zasad zwinnego tworzenia oprogramowania: „sztuka maksymalizacji pracy niewykonanej”. Całość w połączeniu z manifestem Agile (2001 rok) to podstawa metodyk, które zrywają z fikcją podejścia kaskadowego. Jeśli ktoś nie zna tematu, a w jakiś sposób zajmuje się rozwojem oprogramowania, powinien o tym poczytać. Materiałów jest dużo, wszystko co ważne można znaleźć zaczynając od Wikipedii.

Ta zasada definiuje prostotę i podkreśla, że jest kluczowa. Lubię ją, bo jest uniwersalna, działa nie tylko w świecie programowania. Mówi, by nie tracić czasu na rzeczy, które nie przynoszą efektu. Żeby skupiać się na istocie. To podejście spójne z Pareto – za 80 proc. efektów odpowiada 20 procent działań. Jak napisał P. Drucker „nie ma pożytku z efektywnego wykonywania pracy, która nie powinna być wykonywana”.

Kto budował ten wie, że jak niewiele funkcji w produktach ma znaczenie i jak trudno znaleźć zmianę, która przyniesie efekt, coś poprawi (zwiększy sprzedaż lub zaangażowanie użytkowników). Wie też, jak łatwo utonąć w detalach i scenariuszach, które nie mają znaczenia. W rozwoju nie jest ważna liczba wytworzonych rzeczy, tylko wynik. W działaniu nie jest ważna liczba przepracowanych godzin, tylko efekt. By go osiągnąć potrzebny jest dobry wybór środków a potem dbałość o detal. Może to dotyczyć zmian, ale też choćby poszukiwania kanałów promocji, które działają i są efektywne.

Podejście wynikające z tej zasady czasem wydaje mi się sprzeczne z wartościami powszechnie uważanymi za wartości. Np., że aby coś zrobić, należy się narobić. Jeśli nie siedzieliśmy po nocach, jeśli nie pojawiła się krew, pot i łzy, to jak możemy oczekiwać, że pokonamy konkurencję? Nie wiem czy to powszechne, czy tylko polskie, ale jeśli, to skąd po 50 latach bezproduktywnego komunizmu trwa w nas taki kult pracy? Wcale mi on nie imponuje.

W dłuższym horyzoncie zachowanie prostoty wspiera rozwój i utrzymanie – rzeczy mniej skomplikowane utrzymuje i modyfikuje się taniej i szybciej.

Często autorzy przydługich niejasnych dokumentów czy maili sięgają po cytat z B. Pascala „napisałbym krócej, gdybym miał więcej czasu”. Słusznie, prostota wymaga wysiłku. W pisaniu jest on potrzebny, by dotrzeć do sedna i osiągnąć przejrzystość. Jest takie redaktorskie porzekadło „o połowę krótszy artykuł będzie miał dwa razy więcej czytelników”. Również lepiej zapracuje krótszy, jaśniejszy i bardziej skupiony na sednie dokument. Ten wysiłek, podjęty odpowiednio wcześnie, potem owocuje – sensowniejszym działaniem, lepszymi decyzjami.

Efekty pracy adeptów sztuki UX

Mam takie zawodowe hobby: lubię w produktach oglądać efekty pracy „projektantów UX”. Bawi mnie to wielce, nawet w czasie wolnym. Pracuję z UXami, zajmuję się produktami i wszystko to jakoś ładnie się spina. Oglądam coś w sieci i wtedy kojarzę teorię albo przykłady z blogów czy „UX Magazine”, na których opierali się twórcy. (Designerzy, zwłaszcza w Google też potrafią dać czadu, ale to inna historia)

Teoria mówi, że użytkownika należy przywitać miłym słowem. Zwrócić się do niego osobiście, wtedy się lepiej poczuje i będzie miał z danym serwisem skojarzenie pozytywne. Sztuka to sensownie zaimplementować, bo ludzie są różni i różnie na komunikaty reagują – zwłaszcza jeśli interfejs wdraża się w różnych kulturach. Inkryminowany przypadek nie jest groźny lecz zabawny. Akurat na tym serwisie jestem non stop. Czekanie na mnie od 23:50 do 8:00 wygląda na patologię. Czy mam się niepokoić, czy kogoś bolało z tęsknoty? Hej, uspokójcie się tam, jestem i nigdzie się nie wybieram. Na dodatek tych dwóch albumów ostatnio słucham dość regularnie. O tej porze dałbym się skusić na kawę, zresztą już się robi…

Oczywiście to nie jest wina specjalisty UX, który chciał dobrze. Jednak działał w pewnej abstrakcji. Wszystko się wali (oczywiście nie tu), gdy rzecz się zaimplementuje i przychodzi rzeczywistość (nawet jeśli wirtualna).

W Allegro jest kawałek interfejsu, w którym podaje się adres. Tam również zaatakowali UX-owcy. Ich działanie wpływa na wrażenie, które mamy przy korzystaniu z formularza, który użytkownika atakuje dość agresywnie. Gdy zaczyna wpisywać tam np. kod pocztowy, juz po pierwszej cyfrze pojawia się ostrzeżenie i na czerwono „krzyczy”, że liczb jest za mało. Powinno to robić, niekoniecznie tak mocno (nic złego się nie stało, to jest tylko ważne) ale dopiero po wyjściu z pola, albo 2-3 sekundach bezczynności. To wydaje się oczywiste. Wiem, ze UXowcy na pewno to dobrze zaprojektowali, spieprzył „informatyk”… To tak działa już ponad rok, od zmian w serwisie. (Nie piszę o Allegro bo go nie lubię, wręcz przeciwnie – duże, ważne, używam i w wielu miejscach sensownie się zmienia).

To, że coś nie działa szczególnie sensownie, choć wymyślone zostało zgodnie z książkami i blogami, nie jest dużym problemem. Ani komunikat w Deezerze, ani nieudolny kawałek Allegro nie wygonią nikogo z serwisu. Nie powodują żadnych zysków, ani większych kosztów. Gorzej, gdy podążanie za podręcznikiem pociąga za sobą spory koszt a nie tworzy żadnej wartości. W książce Lean Startup jest opisany przykład, który to świetnie ilustruje. W Startupie Grockit designerzy zaproponowali i doprowadzili do wdrożenia „lazy registration”, zgodnie z obowiązującą w tym czasie modą. Dzięki niej użytkownicy mogli w pełni korzystać z serwisu zanim zdecydowali się w nim zarejestrować. Ta możliwośc była dość droga w implementacji i co ważne – w utrzymaniu (to zespół działań występujących w czasie, kiedy goście z UX pracują już przy innym serwisie, a Ty produkcie się martw). Autor książki zachęcił zespół Grockita do przeprowadzenia testu na dwóch grupach – korzystającej z tej formy rejestracji oraz zmuszanej w sposób tradycyjny do założenia konta. Okazało się, że to „lazy” nie miało żadnego wpływu na skuteczność pozyskiwania użytkowników i równie dobrze można było tego nie robić.

W każdym fachu mamy poziom „amator” i „specjalista”. Mistrzowie UX to nie są osoby, które przeczytały najwięcej książek. To nie są nawet ci, którzy robią najlepsze makiety i prezentacje. To ci, którzy mają też wystarczająco dużo rozumu i doświadczenia by przewidzieć w praktyce skutki swoich pomysłów. Takie „Michałki” wychodzą dziś dość często, ponieważ jesteśmy na wczesnym etapie rozwoju specjalizacji. To też kolejny dowód na to, jak bardzo praktyka odbiega od teorii. Nie daje mi spokoju zdanie z komentarza do poprzedniego wpisu: w praktyce teoria o od praktyki różni się bardziej niż w teorii…

BTW. Przyszedłem tu, żeby napisać o swojej ulubionej zasadzie Agile, ale Deezer był dziś wyjątkowo inspirujący. Poprawiliśmy znowu interefejs bloxa, dzięki pracy Justyny i ekipy, pisanie w nowej, testowej wersji jest jeszcze przyjemniejsze. Za każdym razem, gdy coś zmienią muszę to przetestować.

Jak robić duże redesigny?

Nie robić. Duże redesigny są trudne i rzadko się udają. Bardzo łatwo w nich o błędy projektowe i utratę kontroli nad zmianami. Nie jest jednak niemożliwe skuteczne przeprowadzenie takiego projektu. Co jest niezbędne by przebiegał sprawnie?

Ostatnio sporo dzieje się w temacie: zmiany na stronach Google, Allegro, Fotka.pl, Facebooka. Sporo można się nauczyć analizując projekt Google z 2011. Niedawno pisał o tym The Verge, całkiem sporo materiałów trafiło do sieci po zeszłorocznym SXSW. To ciekawy przypadek – korporacja, która natworzyła produktów, nie zawsze potrzebnych. I teraz równie bezsensownie czasem je zamyka (to już inna historia).

W styczniu 2011 Larry Page za pomocą kominikatora zapytał projektantów o pomysły na całościowy redesign. W kwietniu został szefem Googla i zdecydował, że chce mieć nowy wygląd na koniec lata. W 2007 Google podjęło już podobną próbę. Dzięki czemu tym razem się udało? Boldem zaznaczam istotne, uniwersalne czynniki, które pomogły.

Po pierwsze zaangażowanie osoby u szczytu rozumiejącej temat (Larry Page już na studiach czytał D. Normana). To powoduje zmianę priorytetów i wymusza współpracę. Pomaga też narzucony deadline. Zespoły musiały współpracować, inaczej nie byłby możliwy do osiągnięcia. Terminy, niekoniecznie wariackie, dobrze robią projektom.

Wygląd projektował silny zespół centralny, który nie był związany z żadnym produktem. Projektanci nie musieli rozpatrywać specyficznych problemów tych produktów. To uprościło podejmowanie decyzji. Na prezentacjach projektanci żartowali, że używali argumentu “ponieważ Larry tak chce”. Żarty żartami, ale konieczność uzyskiwania zgód potrafi paraliżować. Powinien ją przełamywać ktoś, kto naprawdę poniesie odpowiedzialność za decyzje. W sam raz zajęcie dla CEO firmy produktowej.

Zespół zadbał o to, by zmiany były wdrażalne. Ustalił, jak może wyglądać minimalny zestaw zasad, które mają zastosować wszyscy. By ułatwić wdrożenia stworzył w html/css działające prototypy produktów. Nie tworzył więc w abstrakcji od materiału. Dzięki prototypom programiści i projektanci w zespołach produktowych w 3 miesiące wprowadzili nową wersję searcha, map, gmaila i kalendarza. Nawet Google+ zdążyło przerobić swoje produkty tuż przed premierą. Zmiany były robione niezależnie, ale w tym samym kierunku.

Ciekawy jest harmonogram, który można znaleźć na jednym ze slajdów na temat projektu. Wiele prac toczy się w nim równolegle. Projektowanie rusza w kwietniu, w jego trakcie zaczynają się przygotowania do implementacji. Zespoły pracują nad nią od początku czerwca, a już od lipca zaczynają się pierwsze wdrożenia i testy. Kolejne etapy zaczynają się najwcześniej jak się da. To co powstało było niezależnie wdrażane w zespołach produktowych. Samodzielne zespoły dla każdego produktu + odpowiedni priorytet – projekt miał wystarczające zasoby.

Co jest ważne: zmiany dotyczyły jednego aspektu, wyglądu. Łączone ze zmianą sposobu działania (tak jak np. w Allegro) mogłyby się nie udać. To jeden z najcześciej popełnianych błędów. Nie powinno się robić takich rzeczy, zwłaszcza, gdy są duże. Dlaczego? Warto poznać tę prezentację Etsy.

Historia pokazuje, jak taki redesign można przeprowadzić sprawnie. To nie jest uniwersalny przepis na to, jak go zrobić dobrze. Tego, czy jest sukcesem nie wiem. Te strony ciągle są modyfikowane – nie analizuję tego dokładnie, ale mam wrażenie, że dokonania projektantów już się rozjeżdżają. Warto pamiętać, że takie projekty łatwo się nie kończą. Zmiany w Google jeszcze trwają i z pkt widzenia użytkowników nie zawsze oznaczają poprawę.

O ciężki losie korpo projektantów

Maciej na uxdesign.pl ciekawie napisał o tym, jak ciężko jest o dobre projektowanie w korporacjach. Trzy słowa o tym co z tego wynika:

1. Nie wystarczy umieć narysować. Projektant America Airlines miał świetne szkice sajtu w szufladzie, ale nie był w stanie ich wdrożyć, bo wszystko komplikowała korporacja.

2. Zwracam uwagę na fragment: „Kto nie brał udziału w całodniowych spotkaniach projektowych, w których uczestniczy 15 osób po stronie klienta…”. Takie spotkania to zło w postaci czystej. Zło dla projektu. Najgorsze jest to, że wszyscy ci ludzie chcą dobrze i każdy z nich na swoim blogu mógłby napisać to samo o swoim losie.

3. Największe znaczenie ma jednak realizacja. Ona zależy od tego jak w firmach tworzone są grupy projektowe, jak zorganizowana jest ich praca. Jaki mają rozmiar, możliwości podejmowania decyzji.

4. Nie wystarczy stworzenie małych zespołów. Kluczowe jest to, co potrafią ich członkowie – czy naprawdę rozumieją, albo wiedzą jak sprawdzić, jakie są wszystkie konsekwencje ich decyzji.

5. Wiedza co najmniej połowy tzw. branży UX jest oderwana od rzeczywistości realizacyjnej w korporacjach. Ta rzeczywistość spowodowana jest rozmiarem. Rozmiar komplikuje – o tym, że ze wzrostem trudno utrzymać szybkość wiedzą nawet w Google.

6. Z drugiej strony co najmniej połowa korporacji (ale też start-upów) nie ma pojęcia o UX i projektowaniu, więc jest co poprawiać. Jeśli ktoś potrafi to wszystko robić ma gigantyczną przewagą konkurencyjną. Bez niej nie byłoby sukcesów Apple i Amazon.